Why cross-channel frequency capping rarely happens

Each platform can see its own delivery and nothing else. When it caps at four, it means four exposures within its own inventory, to the identifiers it recognises. It has no visibility of the same household being reached by a different seller an hour earlier.

The consequence compounds with the number of channels. Two channels overlap somewhat; four overlap substantially, particularly when they are all targeting the same narrow audience. That is precisely what a well-briefed multi-channel plan does, so tighter targeting increases the overlap.

None of this shows in a per-channel report. Each one reports its own frequency accurately, and nobody computes the aggregate figure, which is the one a marketing director needs.

To deduplicate across sellers you need every channel writing exposures into one record, keyed on an identifier they can all supply. The difficulty is that they cannot all supply the same one. A streaming platform can offer a household; a billboard can offer a postcode sector and nothing finer; a podcast can offer a delivery log.

The workable design is multi-key with graceful degradation: an opaque household key where available, a hashed advertising identifier where one exists, a consent-based identifier where the chain supports it, and a postcode sector as the coarsest key that always works. Precision varies by channel and the record says which key it used.

The record has to degrade this way because the channels supply different keys, and a spine that depended on one of them would lose every exposure that arrived without it. Multi-key is what keeps the record whole when a channel can only say where, not who.

A single record of who saw what across several channels is exactly the kind of dataset that deserves scrutiny, and the design decision that matters is where identity resolution happens.

The defensible arrangement is that the exposure record itself never performs an identity join: it stores whichever key it was given and never resolves it back to a person or across key spaces. Resolution happens in one separate module, which is then the only place a reviewer has to read to understand what is joined to what, and the only place a retention rule has to be enforced.

In AdBuyMCP that module holds hashed advertising identifiers for at most 90 days, after which the hash is persistently stripped from the event and the record re-graded to a coarser key rather than deleted. Today the exposure ledger is fed only by the deterministic sandbox, because a seller's live report proves aggregate delivery and not household exposure, and AdBuyMCP will not create an identity from a report.

Launches need cross-channel capping most, because a launch campaign deliberately buys the same audience across several channels in a compressed window, which maximises overlap at exactly the moment somebody is going to report a combined reach figure to a board.

The second case is a narrow B2B audience. If your market is fifty thousand people in three cities, four channels aimed at them will overlap heavily by construction, and the difference between the deduplicated and naive reach figures can be large enough to change a decision.

The case where it matters least is a broad national consumer campaign with genuinely different audiences per channel, which is rarer than media plans imply.

Because nothing counts one person across sellers, a plan that promises a market a number of showings a week can only plan that number. AdBuyMCP's awareness plans are built on that limit. You pick 3, 5 or 12 times a week, and the plan defines the number this way: “Frequency is planned: each week we buy enough ads aimed at your market for it to see you that many times on average. Some of every channel's audience sits outside your market, and the weekly report shows what each channel delivered against the plan.”

No UK service de-duplicates frequency across out-of-home, streaming TV, podcasts and ChatGPT ads, so each channel's count is read on its own, in its own unit: