Blended ad spend hides the exact thing you are comparing

Here is a small methodological choice that quietly ruins date-range comparisons, which are the main thing anybody uses marketing reporting for.

A campaign ran for nine days in March. Your report needs a March number. What does it show?

The convenient answer is to take the campaign’s total spend and treat it as a March cost. Or, slightly more sophisticated, take a monthly average and spread it evenly across the days.

Both are wrong in ways that only appear when somebody asks a comparison question.

The failure mode

Blending assumes spend is uniform across a period. It almost never is.

Campaigns start and stop mid-month. Budgets get raised for a push and cut afterwards. Seasonal categories concentrate spend into narrow windows. A single week of aggressive bidding can be half a month’s budget.

Now compare two windows. Say the last 30 days against the previous 30 days, which is the single most common comparison in marketing reporting.

If spend is blended, both windows show something close to a monthly average. The comparison shows almost no change. The underlying reality might be that you spent nothing for three weeks and then went hard for nine days, which is an enormous difference in what happened and what it produced.

The blending did not just lose precision. It erased the variable you were comparing.

Why it happens

Not laziness. Genuinely awkward data.

Platform reporting is organised around campaigns and date ranges that do not align with your reporting calendar. Some exports give daily granularity, some give totals for a requested window, some change what they give you depending on how far back you ask. Currency conversion, invoicing periods and platform-side adjustments all move numbers after the fact.

The authoritative number, the one that matches what you were actually billed, often only exists at a coarser grain than the report needs. So somebody divides.

The division is the problem. It is invisible, it is never labelled, and it silently converts an exact figure into a smoothed one.

What range-aware means

Two rules, applied depending on what the data supports.

For short windows, use precise daily figures. If daily granularity exists, use it. A seven-day comparison built from daily actuals is exact and there is no reason to approximate it.

For long windows, prorate the authoritative export by exact day overlap. When the trustworthy number only exists at campaign or monthly grain, do not spread it evenly. Compute the actual overlap between the campaign’s run dates and the reporting window, and allocate proportionally.

A campaign that ran 12 March to 20 March contributes nine days of its spend to a window covering March, and zero to a window covering April, regardless of when it was invoiced.

That is more computation than dividing by thirty. It is also the only version that gives the same answer whichever way you slice the calendar, which is the property you actually need.

The rule underneath

Never blend. Prorate by exact day overlap, and prefer daily actuals wherever they exist.

The general principle: an aggregation that is fine for a total is usually wrong for a comparison. The moment somebody puts two periods side by side, every smoothing decision made upstream becomes an error in the delta.

Since comparisons are the whole point of a time series, this is worth getting right at the storage layer rather than at the presentation layer.

Why the storage grain matters

There is an architectural version of this argument.

If you store data at daily grain from day one, any date range is a query. Somebody asks about a nine-day window and you answer it exactly, immediately, without re-pulling anything from a platform that may have changed its export behaviour since.

If you store monthly aggregates, every non-monthly question requires either an approximation or a fresh pull. Approximations get made under time pressure, and fresh pulls are where historical numbers quietly change.

Daily grain from day one is more storage and more collection overhead. It is also the difference between a system that can answer a question and one that can produce a number.

What this looks like when it goes wrong

The tell is a comparison that does not move when you know something happened.

Somebody remembers a big push in the second half of the month. The month-over-month spend comparison shows a 2% change. Everybody shrugs and assumes the push was smaller than they remembered.

The push was real. It got averaged.

The second tell is more subtle and more damaging: cost per lead that is stable when everything else moved. If spend is blended and leads are counted properly, cost per lead inherits the smoothing from the numerator and stops reflecting the actual efficiency of the actual spend. You then optimise against a figure that has had the signal averaged out of it.

The connected mistake

Blended spend often travels with the other denominator error, which is dividing spend by all leads rather than by the leads that spend produced.

They compound. A blended numerator over an inflated denominator produces a cost per lead that is smooth, low, and unrelated to anything. It will look stable quarter over quarter, which reads as good performance, and it is stability produced by two averaging errors rather than by consistent results.

Fixing one without the other produces a number that moves for confusing reasons. Fix both and the series starts reflecting what actually happened, which usually means it gets noisier and more useful at the same time.

That is a fair description of what honest measurement generally feels like at first. The line stops being smooth and starts being true.

Every metric definition we use, including the range-aware spend rule, is published here.