National, DMA or Store Level Data for Google Meridian
Which geographic grain to feed Google Meridian, why Google prefers geo-level to national, how to roll store sales up to DMA media, and how much history each grain needs.
On this page
For the best results from a Meridian MMM, set data granularity at the geo level: treat national data as the fallback, use DMA as the working grain in the US, and roll store-level sales up to the geography your media is reported in. Our position, from Google's documentation as read on 7 October 2026, is that the right grain is the finest geography at which both the KPI and most of the media come from real records. A mix model estimates the incremental effect of media from aggregate history, the same quantity our guide to what incrementality is reaches through experiments.
Why does Google recommend geo-level over national?
On geo-level vs national in Meridian, Google is direct. The geo-level modeling page of the Meridian documentation says "Geo-level data offers several advantages and is thus recommended when possible". The advantages it lists include a larger effective sample from pooling across geos, tighter credible intervals when geos respond to media in similar ways, better estimates of trend and seasonality because each week is observed in many places, more variation in spend for fitting saturation curves, and less omitted variable bias.
The time-effect advantage has the largest practical consequence. The page on setting knots in the Meridian documentation explains that geo-level models default to one knot per time period, which gives "maximum flexibility to adjust for time-based confounding", while national models default to a single knot because one knot per period "would be completely saturated and unidentifiable". A national model therefore starts with time effects restricted "to a single constant intercept", and the analyst raises the knot count, by hand or through the Automatic Knot Selection the same page recommends starting with in most cases, or adds seasonal controls. National data remains usable. The data collection page of the Meridian documentation labels it an "Acceptable Alternative" for cases where geo-level data is not available.
Which grain fits which business?
Meridian data granularity is a choice among national, DMA and store level, although Google's definition of a geo is wider: "mutually exclusive geographic regions such as states, cities, DMAs, or even multiple countries". The decision path below is ours. It rests on a test the Meridian FAQ states for hierarchy variables other than geography, "it must be possible to stratify both the KPI and the media units by this variable", and we apply it to the choice of geography too. The data shapes in the two middle columns are assumed for illustration, so check them against your own exports.
| Business | Where the KPI sits | Where media is reported | Grain to feed Meridian |
|---|---|---|---|
| Ecommerce brand selling nationwide | Orders by shipping ZIP | DMA, state or region | DMA, or state if a major channel stops at state |
| Store or restaurant chain in many markets | Sales by store | DMA | DMA, with stores summed into it |
| Regional chain in a few DMAs | Sales by store | DMA, sometimes county or ZIP | The finest geography every large channel reports, with fewer knots |
| Brand with only national sales totals | One national series | Any level | National, three years, few channels |
| Low-volume lead generation | Leads by ZIP or state | State or DMA | State or region, where weekly counts hold up |
The third row follows a caveat on Google's geo-level modeling page: the benefit of geo modeling "is reduced when there are relatively few geos", and "It may be better to fit a model at a finer geo granularity and exclude the smallest geos, rather than aggregating geos to a coarser level."
What do you do with store-level sales when media is reported by DMA?
In a Meridian MMM where media is reported by DMA and sales arrive at store level, data granularity follows the media, so the stores are summed into DMAs. Treating each store as a geo fails the stratification test, because a market's impressions cannot be assigned to single stores. Splitting DMA media across stores by sales or population share leaves every store in a market with a scaled copy of the same media series, so the extra rows add sales noise without adding media variation. Google's researchers documented the same weakness one level up, where national spend is spread across geos. In the 2017 paper that Meridian's geo-level modeling page cites, Google Research reports from a simulation that a model with imputed geo spend "generally yields larger biases and wider credible intervals for the response curves" than one given the full geo-level spend, and that most imputation methods "do not introduce useful variability over time".
Our rules for the roll-up:
- One store, one geo. Map every store to a single media geography by ZIP or county and freeze that mapping for the whole history. Nielsen defines a DMA region as "a group of counties and zip codes that form an exclusive geographic area", counts 210 of them, and produces its ZIP by DMA report annually, so pick one edition and keep it.
- Sum volumes. Google's data collection page requires a KPI that is "summable across both geography and time". Add up revenue, units or transactions, and recompute any rate afterwards.
- Put online orders in the same geo. Assign ecommerce orders by shipping ZIP so that each geo's KPI holds everything its media could have driven.
- Carry store count as a control. Sales jump when a store opens. Google advises collecting controls with "a causal effect on both the target KPI and the media metric or media execution", and if your planners add media around openings, the count of open stores by geo and week meets that definition.
- Use one population basis. The FAQ says "Meridian automatically scales both the KPI and media units by population", and Google's example of a population input is "Nielsen DMA TV household population". Apply one basis to every geo.
For channels reported only nationally, Google recommends imputing them to geos, with population share as one method, and still running a geo model. Its knots page warns that a national-level variable is "perfectly collinear with time" in a model with a parameter for each period, so keep knots below the number of time periods when you include one. That pipeline work sits with our data and analytics service.
How much history does each grain need?
Google Meridian's data requirements for a geo-level model start, as a rule of thumb, at two years of weekly data. The data collection page puts it this way: "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 data also calls for three years. Weekly is the stated best practice: daily data can extend runtime, and monthly data can bring "non-convergence or wide credible intervals".
The rule makes more sense once you count data points per parameter. Take a hypothetical restaurant chain, invented for illustration: 6 media channels, 4 controls and sales in 60 DMAs. The lenient count comes from the exploratory analysis page of the Meridian documentation (geos minus one, plus knots, controls and treatments). The strict count comes from the amount of data page of the Meridian documentation, which gives every geo its own media and control parameters. We assume default knots: one for a national model, one per week for a geo model.
| Setup | Data points | Parameters, lenient | Lenient ratio | Strict ratio |
|---|---|---|---|---|
| National, 104 weeks | 104 | 6 + 4 + 1 = 11 | 9.5 | 9.5 |
| National, 156 weeks | 156 | 6 + 4 + 1 = 11 | 14.2 | 14.2 |
| 60 DMAs, 104 weeks | 6,240 | 6 + 4 + 104 + 59 = 173 | 36.1 | 8.2 |
| Top 40 DMAs, 104 weeks | 4,160 | 6 + 4 + 104 + 39 = 153 | 27.2 | 7.7 |
| 6 sales regions, 104 weeks | 624 | 6 + 4 + 104 + 5 = 119 | 5.2 | 3.7 |
In Google's own national example, four data points per parameter is "too low to estimate the model reliably" and roughly 15 might give "some directional information". The third year is what lifts the hypothetical national model from 9.5 to 14.2. For geo models Google declines to name a minimum and says the effective figure sits between the two views. Cutting the 20 smallest DMAs still leaves 27.2 on the lenient view and 7.7 on the strict one, while rolling up to six regions drops the lenient ratio to 5.2 unless knots come down too. That arithmetic is consistent with Google's advice to keep the finer grain and exclude small geos.
When should you drop or merge a small market?
Google's first instruction is "Drop the smallest geos by total KPI first", because small geos contribute less to ROI yet "can still have a high influence on model fit". For US advertisers the same page offers "a rough guideline", which is to "model the top 50-100 DMAs by population size", out of Nielsen's 210. Merging is the alternative when the model must represent every KPI unit, and Google attaches a warning to it: "Different geo aggregation grouping methods can lead to different MMM results."
The checks we would run before choosing:
- Coverage. Rank geos by total KPI and record the share of KPI the kept geos hold. Report that share beside every ROI the model produces.
- Sparsity. Count weeks with zero or near-zero KPI in each geo. Meridian's exploratory analysis treats a geo whose KPI has zero standard deviation after outliers are removed as "a weak or non-existent signal" and suggests grouping such geos.
- Footprint stability. A market served by one store that opened halfway through the window is a candidate to merge or drop.
- Media logic. Merge only neighboring markets that are bought as one media unit, and fix the grouping before the first fit so the results cannot steer it.
- Sensitivity. Refit at a second cutoff, for example 50 and 75 DMAs. If the ranking of channels by ROI changes, the cutoff is driving the answer.
The geo table that feeds the model also serves the experiments that calibrate it. A quarterly geo-holdout test runs on the same market definitions, its readout follows our guide to analyzing an incrementality test result, and the multiplier method carries the result over to platform-reported numbers. For the attribution side of your measurement, the Attribution Doctor is a further resource. Build the DMA table once, keep its store mapping and population basis fixed, and every model refresh and geo test afterwards starts from the same definitions.
Sources
- Google, Geo-level modeling
- Google, Collect and organize your data
- Google, Amount of data needed
- Google, Set knots
- Google, Perform an exploratory data analysis
- Google, Meridian FAQs
- Google Research, Geo-level Bayesian Hierarchical Media Mix Modeling
- Nielsen, DMA Regions
