Google Meridian: How to Set Up a Bayesian Marketing Mix Model

Marketing mix modelling (MMM) estimates what your marketing actually caused, using aggregate data and statistics rather than tracking individuals. It went out of fashion when click attribution felt precise, and came back the moment that precision evaporated. If your iOS attribution is mostly modelled, your cookies are consent-gated and half your spend sits in channels that never produced a click, MMM is the only method left that answers “did this spend work”.

Meridian is Google’s open-source MMM library, announced in 2024 and Bayesian by design. This is a technical walkthrough: what data it needs, how to install and configure it, what the model specification actually controls, and where teams go wrong. It assumes Python literacy and no prior Bayesian statistics.

Why Bayesian, and why it matters practically

A classical regression MMM gives you point estimates and a shrug. A Bayesian MMM gives you full posterior distributions, which in plain terms means you get an honest range rather than a single confident-looking number. When the model says a channel’s ROI is 2.4, the useful part is whether the credible interval is 2.2 to 2.6 or 0.4 to 6.1. The second is a model telling you it does not know, which is information you want before reallocating a budget.

The other practical consequence is priors. You can tell the model what you already believe about a channel’s ROI, from a previous study or a geo experiment, and let the data update that belief. This is the mechanism that keeps MMM from producing nonsense on channels with thin data, and it is Meridian’s central feature.

Get the data right first, because the model cannot save you

This is where MMM projects succeed or fail, and it is unglamorous. Meridian’s data requirements are specific.

• The KPI, your response variable: revenue, conversions, installs. It must be summable across geography and time.
• Media spend per channel. Required, because it is the denominator of every ROI figure the model produces.
• One exposure metric per channel: impressions, clicks, spend, or reach and frequency. Spend and exposure data must share identical dimensions.
• Control variables: time series for things that confound the relationship, such as seasonality drivers, competitor activity, pricing or Google query volume. The bar for a good control is that it plausibly affects both your KPI and your media execution.

Optionally you can add revenue per KPI (to convert a non-revenue KPI into money), geo population, organic media such as email or owned social, and non-media treatments like promotions and price changes.

Granularity and volume

Weekly data is best practice. Geo level beats national, because a geo model treats each region as a quasi-experiment and gets far more signal from the same calendar period. National data works but needs more history.

• Geo-level models: a minimum of two years of weekly data, which is 104 or more weeks per geo.
• National-level models: a minimum of three years of weekly data.
• Monthly data: three years minimum, and expect to learn less.

If you cannot meet those minimums, the honest answer is that you are not ready for MMM yet, and no amount of model tuning fixes it. Start the data collection now and revisit in a year.

Two rules people break

Only summable metrics. Feed the model raw volumes, never rates. CTR, CPC and ROAS are ratios; aggregating them across geos and weeks is arithmetically meaningless. Give it impressions and spend and let it compute the ratios itself.

No missing values. Meridian requires a complete dataset. The imputation rules are asymmetric and sensible: missing media should be filled with zero, because no spend means no exposure, while missing KPI or control values should be interpolated or filled with historical means. Silently zero-filling a missing KPI week teaches the model that your marketing sometimes produces nothing.

Installation

Meridian requires Python 3.11 to 3.13. Sampling is GPU-accelerated and the difference is not marginal; Google recommends a minimum of one GPU and has tested on a T4 with 16 GB of RAM. A national model on CPU is tolerable, a geo model on CPU will test your patience.

# GPU (Linux, CUDA)
pip install --upgrade google-meridian[and-cuda]

# CPU only
pip install --upgrade google-meridian

In practice most teams run this in Colab with a GPU runtime for the first model, then move to a Vertex AI workbench or a GPU VM once it is a recurring process.

Configuring the model

Meridian’s configuration lives in a ModelSpec object. The full specification is long; these are the parameters that change your answer.

model_spec = spec.ModelSpec(
    prior=prior_distribution.PriorDistribution(),
    media_effects_dist='log_normal',
    hill_before_adstock=False,
    max_lag=8,
    unique_sigma_for_each_geo=False,
    media_prior_type='roi',
    roi_calibration_period=None,
    rf_prior_type='coefficient',
    knots=None,
    baseline_geo=None,
    holdout_id=None,
    adstock_decay_spec='geometric',
    enable_aks=False,
)

mmm = model.Meridian(input_data=data, model_spec=model_spec)

• max_lag (default 8) is the adstock window: how many periods an impression can keep influencing the KPI. Eight weeks is a reasonable default for brand-ish media and too long for pure performance channels.
• media_prior_type='roi' means you express your priors as ROI, which is the natural unit for a marketing conversation and the reason to prefer Meridian over rolling your own.
• knots controls the flexibility of the time-varying baseline. More knots absorb more unexplained variation into the baseline, which flatters your model fit and starves your media coefficients. This is the most dangerous dial in the file.
• holdout_id lets you hold out periods for genuine out-of-sample validation. Use it.
• enable_aks turns on automatic knot selection if you would rather not tune knots by hand.

Setting ROI priors

This is the step that converts your existing knowledge into model structure. Priors are LogNormal distributions over each channel’s ROI:

roi_m = tfp.distributions.LogNormal(roi_m_mu, roi_m_sigma, name=constants.ROI_M)

The pair of parameters is a mean and a standard deviation on the log scale. A tight sigma says “I am confident this channel returns about this much”; a wide sigma says “I genuinely do not know, data, you decide”. Reach-and-frequency channels use the equivalent roi_rf parameter, and Meridian provides argument builders so the ordering of channels cannot silently drift.

The single best source for a prior is a geo holdout experiment you already ran. That is the virtuous loop worth building: experiments inform priors, the model generalises them across channels and time, and the model’s uncertainty tells you which experiment to run next.

Fitting

mmm.sample_prior(500)
mmm.sample_posterior(n_chains=7, n_adapt=1000, n_burnin=500, n_keep=1000)

Sampling the prior first is not a formality. It shows what your model believes before seeing data, and if those prior predictions are already absurd, fix that before spending an hour on MCMC.

The posterior call runs multiple independent chains: n_adapt tunes the sampler, n_burnin is discarded warm-up, and n_keep is what you analyse. Multiple chains exist so you can check they agree. Before you look at a single ROI number, check convergence with R-hat. Values near 1.0 mean the chains agree; anything meaningfully above that means the sampler has not converged and your results are decoration.

Reading the output without fooling yourself

• Check convergence first. R-hat, then trace plots. A beautiful ROI chart from an unconverged model is worse than no chart.
• Read intervals, not points. The headline number is the least informative part of the posterior.
• Validate out of sample. Use holdout_id. In-sample fit is trivially improvable and proves nothing.
• Sanity-check the baseline. If the model attributes almost everything to baseline, your knots are too flexible or your controls are absorbing media effects.
• Treat budget optimisation as a scenario tool. Meridian will propose a reallocation. It is an extrapolation from historical ranges, not a promise, and it degrades badly outside the spend levels it has seen.

How it compares

The realistic alternatives are Meta’s Robyn (R, ridge regression, fast, frequentist) and PyMC-Marketing (Python, fully Bayesian, more flexible and more assembly required). Meridian sits between them: Bayesian like PyMC, opinionated like Robyn, and built to accept Google ecosystem inputs such as Search query volume and YouTube reach and frequency.

The obvious caveat is that a modelling library from an advertising platform, with priors you set, can be steered towards a conclusion. That is not a flaw unique to Meridian; it is why priors should come from experiments rather than from what you hope is true.

What actually goes wrong

1. Not enough history. Two years weekly at geo level, three at national. This eliminates most first attempts.
2. Feeding it ratios. Aggregating CTR or ROAS across geos produces numbers with no meaning.
3. Collinear channels. If two channels always move together, no model can separate them. That is a media planning fact, not a modelling failure.
4. Priors chosen to produce a desired answer. If the posterior always confirms the prior, you built a very expensive opinion.
5. Treating it as a reporting tool. MMM answers strategic allocation questions quarterly. It does not tell you which creative won last Tuesday.
6. Running it once. Value compounds when it is a recurring process whose priors improve with each experiment.

Where it fits

The measurement stack that works in 2026 is triangulated: MMM for strategic allocation across channels, incrementality experiments for causal ground truth on specific questions, and attribution for day-to-day operational optimisation, understood as directional. Meridian is a strong, free implementation of the first pillar, and it becomes considerably more valuable when the third pillar feeds it clean, consent-compliant, well-modelled data.

If you want help judging whether your data can support MMM, or building the pipeline that keeps it fed, our fixed-fee Agentic Readiness Audit starts with exactly that question. The modelling is the fun part; the data engineering underneath is the part that decides whether it works.