Conversion signal loss has four overlapping causes: consent denial, ad blockers, client-side tag failure, and cross-device session breaks. Each kills a portion of your reported numbers. Together they leave the platforms bidding on a partial picture of your conversions.
Enhanced Conversions and CAPI are Google's and Meta's own technical responses. Both send hashed first-party customer data with each conversion, which the platform matches against its own logged-in users. Sent from a server, that data also bypasses the mechanisms that break client-side tracking. Both recover meaningful ground. Neither is a complete fix.
They're the first line of defence and worth deploying now.
The four ways signal dies now
Consent denial. When ad_storage is denied, Google's tags don't write or read ad cookies, so cookie-based attribution halts at the browser. When ad_user_data is denied, Google's conversion pings also go without cookies, and no user data goes to Google for advertising, Enhanced Conversions included. In the UK and EU, ad cookies need opt-in consent, so this loss grows with the share of visitors who refuse.
Ad blockers and ITP. uBlock Origin, Brave's built-in shields, Safari's Intelligent Tracking Prevention and Firefox Enhanced Tracking Protection all block third-party pixel requests or restrict the cookies they rely on. The hit varies by audience: blockers mostly run as desktop browser extensions, so they cost desktop-heavy segments the most.
Client-side fragility. JavaScript errors, slow page loads, tag manager dropouts, hydration races on SPA frameworks. Unpredictable in volume but predictable in shape: the failures correlate with the highest-intent sessions, because complex pages run more scripts and break more often.
Cross-device. Post-iOS 14.5 deterministic ID loss, mobile-to-desktop journeys that cannot be stitched without a first-party login. Particularly damaging for considered-purchase categories where research and conversion happen on different devices days apart.
Different causes, different remedies. A single technical response to all four does not exist.
How much each cause costs depends on market, device mix and audience. Map the four against your own traffic before choosing tools.
What Enhanced Conversions recovers
Google Ads receives hashed email and phone data from the conversion page, matches it against Google's logged-in user graph server-side, and attributes the conversion to the earlier ad click. The match happens on Google's infrastructure, and the data is hashed before it's sent, so Google never receives the raw email or phone number.
Against the four failure modes:
- Consent denial: partial recovery. Works for users who allow their data to be sent to Google for advertising (
ad_user_data) but refuse ad cookies (ad_storage). Google's modelled conversions fill some of the rest. - Ad blockers: partial. The match doesn't need the click cookie, so it holds up against Safari's cookie limits. Sent through the Google tag, though, the data travels with the conversion request, so a blocker that stops the tag stops it too. Server-side GTM or an upload gets it past.
- Client-side fragility: partial. The initial Enhanced Conversions payload depends on capturing the customer's details from the form on the conversion page, so a total client-side failure still kills it.
- Cross-device: strong recovery, given the size of Google's logged-in identity graph.
Implementation: Google Tag Manager handles it natively for any conversion tag with Enhanced Conversions enabled, once Google's customer data terms are accepted in Google Ads. Server-side GTM makes it more reliable: the browser sends the event to your own domain, and your server passes it on to Google. It isn't a prerequisite to start.
What Meta CAPI recovers
The server sends conversion events directly to Meta's Conversions API with customer details Meta can match on: hashed email and phone, an external ID, and the IP address and user agent, which Meta takes unhashed. Implemented fully server-side, it bypasses the browser entirely.
Against the four failure modes:
- Consent denial: recovery depends on the data processing agreement and the consent flags passed through with each event. Works when users consent to Meta's processing even if ad cookies are denied at the browser.
- Ad blockers: strong recovery. Server-to-server delivery bypasses every form of client-side blocking.
- Client-side fragility: strong recovery if implemented fully server-side. Hybrid implementations (CAPI plus pixel) still depend on the client for the events the pixel owns.
- Cross-device: strong recovery when
external_idis passed, which requires an authenticated user identifier. Guest checkouts recover less.
Implementation: a direct API integration from your server, or server-side GTM, where the browser still sends the event to your own domain. Meta deduplicates a pixel event and a CAPI event when both carry the same event name and event_id and arrive within 48 hours of each other, so both sides have to send the same ID.
Duplicate events are the CAPI failure to check first: CAPI and pixel both send the same conversion, so it's counted twice. Meta deduplicates them on a matching event_id from both sides. A setup that gets this right at launch can lose it in a later site release, when one side stops sending the ID. Audit monthly.
Where both tools hit their ceiling
Neither tool recovers users who decline the platform's data processing entirely (not just cookie consent, but processing as a whole, where the option is given). Neither recovers users who are not in the platform's logged-in user graph at all: deterministic match fails, probabilistic models fill some of the gap, and the rest stays unattributed.
Events that happen entirely off-site (phone calls, in-store visits, offline conversions) need separate handling: call tracking, store visit conversions, offline conversion uploads. Both platforms accept offline conversions, Google as imports and Meta as offline events through the Conversions API, but each needs its own feed from the CRM or call system.
Sessions with no identifier at all (no login, no checkout, anonymous research sessions) contribute nothing to either system. Their part in any later conversion stays unattributed.
Fully implemented and audited monthly, the two tools never close the whole gap. The rest has nothing left to match on.
What to implement in what order
Neither EC nor CAPI will recover signal that never entered the system. The consent layer is the upstream check; if defaults are wrong, downstream recovery does not apply.
Sequence by recovery per hour of implementation:
- Meta CAPI via server-side GTM, with event deduplication. Highest signal recovery for the engineering time invested. Plan for a couple of days of build and a week of validation.
- Google Enhanced Conversions on every Google Ads conversion tag. Native support inside GTM makes this a same-day change when the conversion page already has the customer's email, or their name and postal address.
- Event quality validation across both. Check Meta's Event Match Quality score (aim for above 8) and Enhanced Conversions coverage in the Google Ads conversion diagnostics. Fix anything below threshold before declaring done.
- Monthly audit of match rates. Match rates can degrade quietly when site changes ship without a tracking review.
The number to watch
Meta's Event Match Quality (EMQ) score, measured per event in Events Manager, is the quickest check on whether a CAPI setup is working. It's a score out of 10, for web events only, and reflects how well the customer details sent with each server event can be matched to a Meta account. Below 6 and the CAPI implementation is leaking. Above 8 and most of what is recoverable is being recovered.
Google has no EMQ. Its check is the Enhanced Conversions diagnostics report in Google Ads: coverage (the share of conversions that carry customer data), a match rate against signed-in Google accounts, and a status for the setup. It answers the same question as EMQ, more coarsely: the match rate comes in two bands.
Neither platform shows you what you are still missing. That is a different measurement problem, and it is where this stops being enough.
Where this stops being enough
Enhanced Conversions and CAPI recover signal that the ad platforms need to bid well. They answer the platforms' question, which is "did this click convert?" They do not answer the business's question, which is "what share of our revenue was incremental to marketing spend, and where should the next pound go?"
That second question cannot be answered by stitching platform signals back together no matter how clean. It needs a different class of measurement: an incrementality model, run on spend and sales data in a warehouse you own, that doesn't depend on any single platform's identity graph.
That is the architectural argument. These tools are the tactical answer.
That bigger picture is the two-layer measurement model: EC and CAPI feed the signal layer the platforms bid on, and Bayesian marketing mix modelling (MMM) covers the oversight layer that shows where the next pound of budget should go. One doesn't replace the other.
