google/meridian: an in-house MMM framework for budget and ROI questions

What Meridian answers that a dashboard cannot

Meridian is a marketing mix modeling framework, and the README frames the questions it exists to answer: how marketing channels drove revenue or another KPI, what the marketing return on investment was, and how to allocate budget for the future. Those are causal questions asked of aggregated data, not attribution questions asked of individual sessions. The README states plainly that MMM is privacy-safe and does not use cookie or user-level information, which is the structural difference from multi-touch attribution. The audience is advertisers who want to set up and run their own in-house models, which is a narrower group than "anyone with ad spend." Running the model in-house means owning the data pipeline, the priors and the interpretation. Meridian supplies the modeling layer and the documentation around it; it does not supply the data preparation or the organizational willingness to act on a posterior distribution.

Bayesian causal inference and the NUTS sampler behind the model

The README describes Meridian as based on Bayesian causal inference and as using a holistic MCMC sampling approach called No U Turn Sampler (NUTS), linked to the TensorFlow Probability implementation. That choice explains most of the project's operational character. NUTS explores a posterior distribution rather than fitting point estimates, so the output is a distribution over parameters such as channel coefficients and ROI, not a single number. The README explicitly calls this compute intensive and says GPU support has been developed across the library out of the box using tensors. The repository layout backs that up: there is a meridian/ package, a proto/ directory, a scenarioplanner/ directory and a schema.py at the top level, alongside a demo/ folder of notebooks. The dependencies in pyproject.toml show what the sampling actually runs on: jax and jaxlib in the 0.7.x range, tensorflow 2.21.x, tf-keras, and tfp-nightly with the substrates-jax extra pinned to a specific dev build. A pinned nightly is a real maintenance signal. It means the sampling stack is tied to an unreleased TensorFlow Probability build, and upgrading it is not a matter of bumping a caret range.

Installing Meridian and running the getting started notebook

The README requires Python 3.11-3.13 and recommends a minimum of one GPU, noting the project was tested on a T4 GPU with 16 GB of RAM. Installation is from PyPI. On Linux with a GPU, the and-cuda extra is the documented path, and the README warns that a CUDA toolchain and a compatible GPU device are necessary for that extra to activate.

$ pip install --upgrade google-meridian[and-cuda]

On macOS and general CPU machines, the plain package is the documented path, and the README notes there is no official GPU support for macOS.

$ pip install --upgrade google-meridian

To track the unreleased version from GitHub instead, the README gives a direct git install, with the same extra applied for GPU users.

$ pip install --upgrade "google-meridian[and-cuda] @ git+https://github.com/google/meridian.git"

The README recommends a fresh virtual environment so the dependency versions pinned in pyproject.toml resolve correctly. For a first real use, the documented entry point is the Getting Started Colab at developers.google.com/meridian/notebook/meridian-getting-started, which runs the library against sample data. The demo/ directory in the repository holds the same material as notebooks: Meridian_Getting_Started.ipynb, Meridian_Full_Funnel.ipynb, Meridian_RF_Demo.ipynb and others. Expect the first sampling run to be the slowest thing you do that day; that is the NUTS sampler doing its job, not a misconfiguration.

The GPU requirement is a real gate, not a suggestion

The README says a minimum of one GPU is recommended and that GPU support has been developed across the library out of the box. It does not present CPU-only execution as a supported production path. If your team's default environment is a shared CPU notebook server, the first honest question is whether you can get a GPU attached before you get a model out. The second limitation is data shape. Meridian is described as capable of handling large scale geo-level data, which the README encourages if available, but it can also be used for national-level modeling. Geo-level data is not a free upgrade: it multiplies rows, and with NUTS sampling, more rows generally means more compute. The third issue is support latency. The README says the Meridian team responds to Discussions and Issues weekly in batches and asks users to be patient, and to not reach out directly to their Google Account teams. If your budget cycle closes on a date and your model has not converged, a weekly batch response is your support channel. That is a legitimate trade-off for an open source project, but it should shape how much slack you build into the schedule.

Meridian against LightweightMMM, and why the migration guide exists

The README points LightweightMMM users to a migration guide and says it will help them understand the differences between the two MMM projects. Both are Google MMM libraries, so the difference is not one of category. The distinguishing traits visible here are scale and calibration. Meridian is documented as handling large scale geo-level data, as supporting calibration of MMM with experiments and other prior information, and as optimizing target ad frequency using reach and frequency data. Those are the capabilities that justify a migration for teams that have outgrown a simpler model. The cost is the stack: Meridian pulls in TensorFlow, JAX, tf-keras and a pinned tfp-nightly build, and it wants a GPU. A team running a small national-level model on a CPU may find that LightweightMMM remains the better fit, and the existence of a migration guide rather than a replacement notice suggests Google expects both to coexist. Read the guide before you port anything; the modeling differences it describes are the part you cannot discover from the install command.

Licence, releases and what upgrading costs

Meridian ships under Apache-2.0, with the LICENSE file at the repository root and license-files declared in pyproject.toml. Apache-2.0 is a permissive licence with an explicit patent grant, which matters for a modeling library you may embed in internal tooling. That is a description of the licence text, not legal advice; if you redistribute Meridian or a derivative, read the terms yourself. On upgrades, the repository has a CHANGELOG.md and the project URLs in pyproject.toml point to it, so version history is published. The friction is in the dependency pins. numpy is constrained to >= 2.0.2, < 2.4.0, tensorflow to >= 2.21.0, < 2.22, matplotlib to < 3.11.0, and tfp-nightly is pinned to an exact dev build, 0.26.0.dev20260130. Those upper bounds mean Meridian cannot simply follow the rest of your environment forward. Any upgrade of numpy or TensorFlow elsewhere in the stack has to be reconciled with these ranges, and the tfp-nightly pin is the one most likely to force a coordinated change. Budget for a dependency review on each Meridian upgrade, not just a pip install.

Editorial conclusion

Adopt Meridian if you already run MMM in-house, have geo-level data and a GPU, and can afford to treat NUTS sampling as a real compute cost rather than a background job. Do not adopt it if you need national-level results from a laptop, if nobody on the team can read a posterior, or if you expect a managed service: the README points questions to GitHub Discussions and Issues, answered weekly in batches. Verify three things first: that your Python is 3.11-3.13 as the README states, that your GPU and CUDA toolchain can activate the and-cuda extra, and that your data is aggregated rather than user-level, since Meridian is documented as privacy-safe and does not use cookie or user-level information.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository