What Enhanced Conversions and CAPI actually give you back

Since 2024, 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 have taken the platforms from roughly 90% signal coverage in 2020 to somewhere between 50% and 70% in 2026, depending on market and audience composition.

Enhanced Conversions and CAPI are the most widely adopted technical responses. Both work by sending first-party, hashed conversion data from the server to the ad platform, bypassing the mechanisms that break client-side tracking. Both recover meaningful ground. Neither is a complete fix, and treating them as one is where most implementations go wrong.

They are the first line of defence, not the final answer. Useful to deploy today, insufficient to rely on tomorrow.

The four ways signal dies now

Consent denial. When ad_storage or ad_user_data are set to denied, cookie writes are blocked and conversion attribution halts at the browser. UK and EU traffic loses roughly 30% to 50% of attributable conversions on this alone, depending on banner UX and pre-tick behaviour.

Ad blockers and ITP. uBlock Origin, Brave's built-in shields, Safari's Intelligent Tracking Prevention and Firefox Enhanced Tracking Protection all block or degrade third-party pixel requests. The hit varies by audience: 25% to 40% in desktop-skewed segments, considerably less on mobile-heavy DTC.

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 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.

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 click that drove it. The match happens on Google's infrastructure; the browser never carries the personally identifiable data to the platform.

Against the four failure modes:

• Consent denial: partial recovery. Works for users who consented to Google's own data processing but denied third-party cookies. Google's modelled conversions fill some of the rest.
• Ad blockers: meaningful recovery. The server-side match bypasses client-side request blocking entirely.
• Client-side fragility: partial. The initial Enhanced Conversions payload still depends on capturing the hashed identifier from the form on the conversion page, so 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. Server-side GTM makes it more robust by removing the browser as a hop in the data path, but is not a prerequisite to start.

What Meta CAPI recovers

The server sends conversion events directly to Meta's Conversions API with hashed user identifiers (email, phone, external ID, IP, user agent). 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 still owns.
• Cross-device: strong recovery when external_id is passed, which requires an authenticated user identifier. Guest checkouts recover less.

Implementation: direct API integration or via server-side GTM. Meta's deduplication between pixel and CAPI requires event_id matching on both sides, which is the most common implementation failure.

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-platform (phone calls, in-store visits, offline conversions) need separate handling. Call tracking, store visit conversions, offline conversion uploads. These are different products with different integration patterns and are not what Enhanced Conversions or CAPI are for.

The 10% to 25% of sessions with no identifier at all (no login, no checkout, anonymous research sessions) contribute nothing to either system. They show up in the platforms' "direct" or "unattributed" buckets and stay there.

Realistic ceiling, fully implemented, audited monthly: 75% to 85% of the signal you had in 2020. Anyone promising full recovery is selling a dashboard, not a solution.

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:

1. 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.
2. Google Enhanced Conversions on every Google Ads conversion tag. Native support inside GTM makes this a same-day change in most setups.
3. 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.
4. Monthly audit of match rates. Silent degradation is common when site changes ship without a tracking review.

The number to watch

Meta's Event Match Quality score, measured per event in Events Manager, is the most honest number in this stack. It runs from 1 to 10 and reflects how many identifiers Meta received per event and how many matched against its user graph. Below 6 and the CAPI implementation is leaking. Above 8 and most of what is recoverable is being recovered. Google's equivalent sits in Enhanced Conversions diagnostics inside Google Ads and is less granular but directionally similar.

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 function. 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: warehouse-first data infrastructure, server-side event collection that you own, and an attribution layer that does not depend on any single platform's identity graph.

That is the architectural argument. These tools are the tactical answer. Both are necessary. Neither is sufficient.

That bigger picture is the two-layer measurement model: EC and CAPI feed the signal layer, Bayesian MMM covers the oversight layer. Both need to work for the stack to earn its place.