Attribution setups have grown layers the way old houses grow extensions. Each one was added to fix something specific, and few teams can say precisely what each does or what it costs.
This is a plain description of the layers, in the order data moves through them.
What are the layers?
| Layer | What it does | What it cannot do |
|---|---|---|
| Consent capture | Establishes what may lawfully be collected | Make unconsented data available |
| Client-side collection | Sends events from the browser | Survive blockers and storage limits |
| Server-side collection | Sends events from your own server | Create a lawful basis |
| Enhanced matching | Reconnects a conversion to a known person | Work without a lawful basis |
| Modelled conversions | Estimates what was never observed | Be verified against ground truth |
The sequence matters. Every layer below consent is constrained by it, and no amount of engineering further down compensates for a decision made at the top.
Layer 1: consent capture
Consent determines what everything else is allowed to do, which makes it the most consequential layer and the one most often implemented as an afterthought.
Two failures are common and both are quiet.
The banner that does not gate anything. Tags fire on page load regardless of the choice. The data looks complete, the dashboards look healthy, and the organisation is carrying a liability nobody has priced. This is worth testing directly: decline consent, open the network tab, and watch what fires anyway.
Consent rates nobody monitors. The proportion of visitors who accept varies enormously by market, by design, and by how the choice is framed. It is also a number that can move ten points after a banner redesign, which changes the completeness of every downstream report without anyone announcing it.
Where consent is declined, well-built stacks send a signal that says so, rather than sending nothing. Platforms use that to model the gap — which is legitimate, provided everyone understands that the result is an estimate.
Layer 2: client-side collection
The browser tag. Still the default, still useful, increasingly incomplete.
Its problems are structural rather than fixable. Content blockers remove the script entirely for a meaningful share of users. Browser storage policies limit how long first-party script-set identifiers survive, so a returning visitor after several weeks often looks new. And a tag that fails on a slow connection takes its event with it.
None of this makes client-side collection useless. It makes it a partial census, which is a different thing from the complete record most reporting treats it as.
Layer 3: server-side collection
Events sent to advertising platforms from a server you control, rather than from the visitor's browser.
What it genuinely improves: reliability, because a server-to-server call is not subject to blockers or connection failures; control, because you decide exactly what is sent rather than shipping whatever the vendor's script collects; identifier durability, because server-set values are not subject to the same browser storage limits; and coverage of events that never happen in a browser at all — a sale closed on the phone, a subscription renewal, a refund.
The honest cost is operational. Server-side tagging is infrastructure: it needs hosting, monitoring, deployment discipline and someone who understands it when it breaks at an inconvenient moment. For a small site with a simple checkout and healthy consent rates, that cost can exceed the gain.
Layer 4: enhanced matching
Sending hashed identifiers you already hold — usually an email address, sometimes a phone number — so the platform can match a conversion to a person it recognises without relying on a third-party cookie.
It is effective where it applies, because an email address is stable in a way that browser identifiers are not. It also has the narrowest scope of any layer here: it only works for conversions where you actually collected an identifier, which excludes most anonymous purchases and nearly all top-of-funnel activity.
The hashing deserves a precise reading. It protects the value in transit and means the platform does not receive a plaintext address. It does not de-identify the data in any meaningful sense — matching is the entire point — and it does not remove the need for a lawful basis for the disclosure.
Layer 5: modelled conversions
Where a conversion could not be observed, platforms estimate it from the behaviour of comparable users who could be.
The technique is sound in principle: if measurable users who saw an ad convert at a given rate, applying that rate to unmeasurable users is a defensible estimate. The practical issues are that the modelled share is often large and rarely surfaced, the confidence intervals are not published, and the party producing the estimate benefits from it being high.
Two things follow. First, find the modelled proportion — most platforms expose it somewhere, though rarely prominently — because it should change how hard you lean on the number. Second, keep at least one measurement method the platform does not control, or you are checking a model's homework with the same model.
How the layers fail together
The failure mode worth planning for is not one layer breaking. It is several degrading quietly at once.
A consent banner redesign lowers acceptance. The modelled share rises to compensate. Reported conversions hold roughly steady, so nothing looks wrong. Meanwhile the algorithms are optimising against a larger proportion of estimates, and the estimates are calibrated on a shrinking measurable population.
The tell is not in the platform dashboard. It is in the gap between platform- reported conversions and your own order count, tracked over time as a ratio. When that ratio drifts, something in the stack has changed, and the platform view will not tell you what.
What to do about it
Monitor the ratio. Platform-reported conversions divided by actual orders, by channel, weekly. Its absolute value does not matter much; its trend matters a lot.
Test consent as an adversary. Decline, then verify nothing fires. Repeat after every tag manager change, because this breaks silently and in the direction that looks like good news.
Know your modelled share. Per platform. If it is high, treat that platform's reporting as a strong optimisation signal and weak evidence.
Keep one independent method. A quarterly holdout test on the largest channel is enough to calibrate everything else.
The stack is worth building well. It is not worth believing completely — and the distinction between those two positions is most of what separates useful measurement from confident nonsense. The wider context is in marketing measurement in a privacy-first world.