Here’s something nobody talks about. Everyone obsesses over building the first MMM. Priors, adstock, saturation curves, channel hierarchies, the works. Teams will spend weeks arguing about whether a half-life is four days or six. But almost nobody asks the obvious follow-up question, the one that actually decides whether your model survives contact with reality:
How do you refresh it?
Because a model you built in January is stale by April. Spend patterns drift. New channels come online. A competitor changes their pricing. The world moves, and your MMM has to move with it. Yet for all the energy poured into the first build, the refresh gets treated as an afterthought. Run it again, swap the numbers, move on.
The literature is thin too. Even Google’s Meridian, which is about as serious as open-source MMM gets, only offers you two options:
- Incorporate new data. Bolt the new weeks onto the old data and re-run the whole thing.
- Model the new data on its own. Fit the fresh window separately and carry the old posteriors over as priors.
Most teams reach for the first one. It feels natural. You already have a pipeline, you already have the historical data, so you append the latest weeks, hit run, and call it a refresh.
This is wrong. And it’s worth understanding exactly why, because the mistake is subtle.
A refresh is supposed to carry information, not just data
When you re-run an MMM by stacking new data on old data, you are treating the refresh as a bigger dataset problem. More rows, same machinery. But a refresh isn’t just more data. It’s supposed to carry information, and the most valuable information in your business doesn’t live in the dataset at all.
Let me make this concrete.
You run your first MMM. It looks at everything and tells you something specific: move €100k out of Facebook and into Google. You trust the model, so you do it. That reallocation was a deliberate decision, made because of the model. It is now part of your reality. Your spend mix changed, your results changed, and the reason it changed was the intelligence the model gave you.
Now fast forward three months. You run a refresher. The new data already has the consequence of that decision baked into it. Google spend is higher, Facebook spend is lower, and the outcomes reflect that new shape. But the data has no idea why any of it happened. The qualitative information, the part that says “we moved this budget on purpose because the last model told us to,” is nowhere in those columns.
So the refresh re-derives everything from a blank slate. It sees the new spend mix as if it fell from the sky. It doesn’t know that you already learned this lesson, already acted on it, already paid for that knowledge. You spent weeks building a model precisely to generate that insight, and then you throw the insight away the moment you refresh. You keep the footprints and lose the map.
That’s the paradox. The refresh is the one moment where you have more knowledge than you did the first time, and the standard approach is built to ignore it.
The priors approach has the same hole
At this point you might say: fine, that’s why the second Meridian option exists. Don’t append the data, fit the new window separately and use the old posteriors as priors. Carry the past forward properly.
And yes, this is better. It’s the more sophisticated choice, and if those are your only two options it’s the one to pick. Seeding the new model with what the old model believed is genuinely more honest than pretending the old model never existed.
But it still has a hole in it.
Posteriors are only the statistical shadow of the previous model. They are a compressed numerical summary of what came out the other end. They are not the model itself. The structure that made your last model yours, the hyper-parameters you tuned, the configuration choices you committed to, the shape of the assumptions you decided to trust, none of that travels with a handful of priors. You’re handing the new model some numbers and hoping they stand in for an entire prior reality. They don’t.
So whichever of the two roads you take, you end up in the same place. You start each refresh half-blind, having quietly discarded the most expensive thing you own: the accumulated, model-encoded understanding of how your own marketing actually works.
What a real refresh should do
A refresh should inherit the whole previous model, not a summary of it. The hyper-parameters. The original training data. The embedded knowledge of your business that the model has already absorbed. All of it, carried forward, with the new data folded in on top of what you already established, instead of restarting from scratch every quarter and re-learning lessons you paid for months ago.
Think of it the way a good analyst works. They don’t wipe their memory every time fresh numbers land. They bring everything they learned last quarter into how they read this quarter. Your model should do the same. A refresh should be your model remembering, not your model forgetting and rebuilding.
That is exactly what we built into MarSci.
Our Refresh MMM takes your previous model bundle, which already carries its original training data and its hyper-parameters, and lets you drop in your new dataset on top of it. It refreshes on the foundation of everything the old model already knew. No re-tuning from zero. No throwing away the decisions you already made and acted on. The reality your last model represented becomes the starting point for the next one, the way it always should have been.
And you do it yourself. You don’t commission a brand-new model and wait around for it every time your data shifts. You drop in your old model file, drop in your new data, and refresh. The whole point of a refresher is that it should be fast, repeatable, and informed by your history. Now it is.
Try the refresher
If you’ve been struggling with exactly this problem, refreshing a model that keeps forgetting what it already taught you, we’d genuinely like to show you a better way.
Reach out to us at info@mar-sci.com and we’ll get you set up to try MMM refresher on your own model. Bring your last model bundle and your latest data, and see what a refresh looks like when it actually remembers.
