Google Meridian MMM: the operator's implementation guide

What Google Meridian is, and what it is not

Google Meridian is Google's free, open-source Bayesian marketing mix modeling (MMM) framework. In Google's own words, it "enables advertisers to set up and run their own in-house models." You install it, feed it aggregated spend and outcome data, and it estimates how much each channel drove your key performance indicator (KPI), computes return on investment (ROI) per channel, and optimises future budget allocation. No user-level tracking is involved.

This is the implementation guide, not the announcement. Our earlier piece on why MMM came back and what Meridian changes covers the strategic case. This post assumes you have already decided MMM is worth doing and now need to scope an actual Google Meridian build. A reader with a data team should be able to plan one from this page.

First, the facts that age fastest, stated so the post ages well. Meridian launched openly to everyone on 29 January 2025, after private testing "with hundreds of brands," alongside a program of 20+ certified measurement partners. As of July 2026 the current version is 1.7.1 on PyPI, released 22 July 2026 (the prior release, 1.7.0, shipped on 18 June 2026). It never went to a 2.x line. It is licensed Apache-2.0, which permits commercial use.

What Meridian is not: it is not an attribution tool, not a real-time optimiser, and not a replacement for Google Analytics 4 (GA4). It answers three questions Google frames explicitly. What was each channel's historical contribution and ROI? What does the response curve for each channel look like? How should you allocate future budget to maximise the business outcome? Those are planning questions, measured over quarters, not the tactical questions attribution answers this week.

One more thing it is not: plug-and-play. There is a system-requirements bar. Meridian needs Python 3.11 to 3.13 and at least one graphics processing unit (GPU) is strongly recommended (Google reports testing on a T4 with 16 GB of RAM). Install is pip install --upgrade google-meridian for the CPU build, or google-meridian[and-cuda] for GPU. The library is on the Python Package Index and the source lives on GitHub at github.com/google/meridian.

How the model works in plain English

Meridian looks at your aggregate history, weekly KPI and weekly media by region, and estimates how much each channel contributed. It does this while respecting two realities that naive regressions ignore. Ads have a delayed effect, since people rarely convert the instant they see one. And ads have diminishing returns, so the hundredth impression is worth less than the first.

Because the model is Bayesian, every answer arrives as a probability distribution, a range with quantified uncertainty, rather than a single point number. That is a feature, not a hedge. "Search most likely drove between 28 and 41 percent of revenue" is more honest, and more auditable, than "search drove 34 percent." And because it is Bayesian, you can inject prior business knowledge directly, such as the result of a lift test, and the model will weigh it against the data.

Under the surface, Meridian is a geo-level hierarchical model. Its own documentation describes it as "a geo-level hierarchical model with non-linear parametric transformations on the media variables." It extends the academic work of Jin et al. 2017 and Sun et al. 2017, adding reach and frequency handling from Zhang et al. 2023. The pipeline runs in a fixed order.

The hierarchy is what makes the geo design pay off. Each region gets its own coefficients, but those coefficients are partially pooled toward a national mean, so regions borrow statistical strength from each other. A single-geo run is just the national special case, with far fewer effective observations. That is why national models need more history than geo models: they have thrown away the cross-regional variation that geo models exploit.

The media transforms are specific. Adstock uses geometric decay with a parameter alpha in the range zero to one, default prior Uniform(0,1); a binomial decay option also exists. Saturation uses a Hill function. For regular media the default order is adstock then Hill; for reach and frequency it flips to Hill then adstock. Inference uses a "holistic MCMC sampling approach called No U Turn Sampler (NUTS)," implemented on TensorFlow Probability, which is why the GPU recommendation is not decorative. The terms below recur through the rest of this guide.

The data Google Meridian actually needs

This is where most Meridian projects stall, well before the model runs. The inputs are specific, and the granularity rules are firm. The table below is the assembly checklist. Every row is required unless the notes say otherwise, and every field is indexed by geo and by time period.

The history rule is the one to memorise. Google's documentation is blunt: "As a general rule of thumb, historical data should be a minimum of two years' worth of weekly data for geo-level models and three years' of data for national-level models." Monthly-only data pushes the minimum to three years. Weekly is preferred because it "presents an advantageous equilibrium between the degree of variation and the extent of noise."

On the number of geos, Google deliberately declines to prescribe a floor: "we avoid prescribing a single 'correct' minimum ratio." For the US it does offer a benchmark, model the top 50 to 100 designated market areas by population. The real test is running the model and checking the observations-per-parameter ratio and the width of the credible intervals. A worked example from the docs: 105 geos times three years of weekly data gives 16,380 data points. That is the kind of density the geo design is built to exploit.

Paid search gets special handling, and it is easy to get wrong. Include Google Query Volume as a control variable, so the model does not credit paid search with demand that already existed and was going to convert anyway. And model brand search and generic search as separate channels, because brand search often harvests existing intent while generic search can create incremental demand. Collapsing them into one channel muddies the ROI estimate for both.

The implementation workflow, step by step

Here is the end-to-end build, in the order you run it. Each step names the object or method involved so a data team can map it to the docs. This is the centrepiece of the guide.

1. Install

   Run pip install --upgrade google-meridian[and-cuda] for the GPU build (Python 3.11 to 3.13). CPU works but is slow for geo models. Confirm the GPU is visible to TensorFlow before you go further.

2. Collect and shape the data

   Assemble weekly, per-geo, per-channel data: KPI, revenue-per-KPI, spend, exposure (impressions and clicks or reach and frequency), controls including GQV, and population. Two years plus for geo models, three years plus for national. This step usually takes longer than everything after it combined.

3. Load into the schema

   Map your columns through Meridian's data loader into its input schema: arrays indexed by geo, time, and channel. Getting the index alignment right here saves hours of debugging later.

4. Specify the model (ModelSpec)

   Choose the media-effects distribution, set priors (the default paid-media prior is a lognormal on ROI, LogNormal(0.2, 0.9)), set adstock max lag and knots, and decide whether Hill runs before or after adstock. This is where you set custom ROI priors from experiments for any calibrated channel.

5. Fit with MCMC

   Run sample_prior then sample_posterior to fit with NUTS MCMC across multiple chains. A GPU is strongly recommended. National models with many channels can run for a while, so plan compute accordingly.

6. Run diagnostics

   Check R-hat near 1.0 (roughly under 1.1 as a rule of thumb) for convergence, review effective sample size, and inspect divergences. Wide credible intervals are a signal of insufficient data or variation, not a bug to resample away.

7. Analyse the results

   Pull ROI, marginal ROI, incremental outcome, cost per incremental KPI, channel contribution, and response curves, all from the posterior draws. Read them as ranges, because that is what they are.

8. Optimise the budget

   Call BudgetOptimizer.optimize() for a fixed budget (the default) or a flexible budget, adding channel-level spend constraints. The section below on the optimizer covers the modes in detail.

9. Report

   Generate the HTML summary outputs, or push an already-trained model into the no-code Scenario Planner (launched February 2026) so stakeholders can run their own budget scenarios without touching Python.

Interactive: the data-feasibility planner

Before you scope a Google Meridian build, the first question is whether your data can carry one at all. This planner turns the data rules above into a directional read. Enter your geos, weeks of history, channels, and cadence, and it returns a verdict band plus the specific gap. Every threshold here is a method-level rule of thumb, not a guarantee, and the output is a planning signal, not a model result.

Calibrating Meridian with incrementality experiments

An uncalibrated MMM is an observational regression. It can tell you that search spend and revenue moved together, but it cannot tell you whether search caused the revenue or simply rose because demand was rising anyway. Calibration is the fix, and Meridian's Bayesian design makes it clean.

The mechanism is priors, not post-hoc adjustment. You fold ground-truth experiments, such as geo lift tests, conversion-lift studies, or randomised controlled trials, into the model as priors on that channel's ROI. Meridian's documentation exposes exactly this: set custom ROI priors using past experiments. A lift study that returns an ROI of roughly 2.5 with a standard error becomes a lognormal ROI prior on that channel. The MCMC then weighs that experimental prior against the observational likelihood, and the posterior respects both.

Contrast that with the default. Meridian's out-of-the-box paid-media prior is deliberately moderate: LogNormal(0.2, 0.9), which the docs describe as "a priori the mean ROI of each channel is 1.83 ... 80% are between 0.5 and 6.0." That default is a sensible, weakly-informative guardrail for a channel you have not tested. A channel you have tested deserves a tighter, experiment-anchored prior, and the difference in the resulting posterior can be large.

Helper utilities exist to construct these priors from an experiment's mean and standard deviation, or from a confidence interval. Design the experiments to feed this step, our incrementality testing guide covers how to run geo holdouts and lift tests that produce a usable lift estimate. For the cross-border privacy context that increasingly forces teams toward this aggregated, consented approach, the cookieless MMM and Bayesian incrementality piece goes deeper on APAC specifics.

The budget optimizer, honest limits, and when not to use it

Once the model is fit, the BudgetOptimizer is what turns posteriors into a recommendation. It builds response curves from the posterior adstock-and-Hill draws, marks your current spend and the optimal spend on each curve, and reallocates. There are two modes.

The decision metric that matters here is marginal ROI, the return on the next dollar at current spend levels. A channel with a high average ROI but a saturated response curve may have a low marginal ROI, which means the next dollar is better spent elsewhere. The optimizer equalises marginal ROI across channels subject to your constraints. You can bound how far it moves any single channel with per-channel spend-shift ratios, which matters when a purely mathematical optimum would swing spend more violently than an organisation can execute.

Now the honest limits, stated plainly, because the hype version skips them.

• Compute is real. NUTS MCMC is expensive. A well-specified geo model with many channels can run for hours, and a GPU is effectively required for a working cadence.
• Statistical literacy is required. Reading R-hat, divergences, and credible intervals, and setting priors well, needs genuine Bayesian skill. The no-code Scenario Planner sits on top of an already-trained model; it does not remove this need for the modelling step.
• It is data-hungry. The geo hierarchy is the strength, but it needs clean, aligned geo-level data over two to three years that many smaller advertisers simply cannot assemble. Low spend variation means weak identification, whatever the sample size.
• It has a Google-centric edge. Meridian is richest with Google data: GQV, and reach and frequency via the MMM Data Platform. Non-Google channels are harder to feed at the same fidelity.
• It is channel-level, not campaign-level. The granularity is deliberate. Meridian is not user-level attribution and will not tell you which creative won.

Google, citing Harvard Business Review Analytic Services research, puts a number on the adoption gap: nearly 40 percent of marketers struggle to connect MMM insights to decisions, which is the stated reason the Scenario Planner exists. That is the honest backdrop. Meridian is a strong tool for teams with the data and the skill. It is the wrong tool for thin-data setups, real-time optimisation needs, and teams without any Bayesian capacity. Reach for it where those conditions hold, and reach for something lighter where they do not.

Google Meridian versus Meta Robyn in brief

The two open-source MMM frameworks that matter in 2026 are Meridian and Meta Robyn. They solve the same problem with different mathematics, and the choice is less about which is better and more about which fits your team. The short version is below; our Meta Robyn implementation guide covers the Robyn side in the same depth this post covers Meridian.

The decision heuristic. If you are Google-heavy, have clean geo-level data, and want quantified uncertainty and the ability to encode experiment results as priors, Meridian is the natural pick. If your team lives in R, your data is Meta-heavy or lighter, and you value speed and automation over posterior uncertainty, Robyn fits better. Neither is correct in the abstract. The Robyn guide walks the full frequentist workflow, the Pareto model selection, and the methodological criticisms, so if you are genuinely undecided, read both and match the tool to the team.

Commercial MMM software is the third option, and the trade-off there is transparency for convenience. Meridian is free and self-hosted, and you own the model, the data, and the results. Managed MMM software trades that transparency for maintained pipelines, support, and a lower in-house statistical burden. For teams building a measurement layer a board can interrogate, that ownership matters. For a fuller treatment of building measurement your CFO will trust, see our incrementality testing guide and the MMM revival piece. If measurement architecture is what you are actually scoping, our analytics and insights service is where that work lives.