Conversion Tracking on First-Party Data: CAPI, Enhanced Conversions and Consent Mode

If your Meta Pixel and Google tag were set up in 2020 and left alone, they now report fewer conversions than actually happen. Browser restrictions, consent banners and ad blockers stop a meaningful share of conversions before they reach Google and Meta. Sending conversions from your own server, based on first-party data, recovers part of that signal. This matters for bidding, because automated bidding optimizes toward the conversions it can see.

Where your conversions go missing

Start with Chrome. Google spent years promising to phase out third-party cookies in Chrome. In 2024 it switched to a planned “user choice” prompt, and in April 2025 it confirmed it would not deprecate them or ship the prompt at all. Chrome keeps its existing cookie controls. If your measurement plan was built around a Chrome deadline, that deadline no longer exists.

The signal loss is still there, because it never depended on Chrome. Safari’s Intelligent Tracking Prevention blocks third-party cookies outright and caps the lifetime of any cookie written by JavaScript at seven days, or 24 hours for domains it classifies as trackers. Firefox blocks third-party cookies by default. Ad blockers remove the Meta Pixel and the Google tag from the page before they fire. In the EEA, a user who declines consent produces no client-side event at all. None of this depends on Google’s plans for Chrome.

So the pixel reports fewer conversions than happened, and the gap is uneven. Its size depends on the visitor’s browser and consent choice. It has nothing to do with how the campaign performed. That makes it a systematic bias. Random noise averages out over time. A bias does not, and your bidding algorithms learn from it.

Client-side and server-side compared

A conversion event can be sent in two ways. Client-side tracking runs in the visitor’s browser. The Meta Pixel and the Google tag run JavaScript, read cookies and POST the event to the platform. It is easy to install and collects a lot of context about the visit. The problem is that it runs inside the browser, which is where browsers, ad blockers and consent tools apply their restrictions.

Server-sidetracking sends the event from your own infrastructure (your application server, or a cloud tag container you control) straight to the platform’s API. It does not use document.cookie, browser extensions cannot see it, and you decide which fields leave your system. The cost is engineering work: you own the endpoint, the data cleanup and the maintenance.

Meta: the Conversions API and event deduplication

The Meta Conversions API (CAPI) is a direct server-to-server connection between your systems and Meta. It sends the same web events as your Pixel (Purchase, Lead, AddToCart), but from your server, where ad blockers and iOS restrictions do not apply. Meta recommends running CAPI alongside the Pixel and keeping both.

Running both creates a problem. If the browser sends a Purchase and your server sends the same Purchase, Meta could count it twice. Deduplication prevents that. According to Meta’s official documentation, the recommended method compares two fields. The Pixel’s eventID must equal the server’s event_id, and the Pixel’s event must equal the server’s event_name. When both match within 48 hours of the first event, Meta keeps one event and drops the duplicate.

Two other identifiers are easy to confuse with event_id. fbp is the value of the first-party _fbp cookie that Meta sets on your domain. fbc comes from the fbclid click parameter and is stored in the _fbc cookie. Both are matching parameters: Meta uses them to connect an event to a person, and neither is the deduplication key. Unlike email or phone, they must be sent unhashed. Meta does offer a second dedup method based on event_name plus fbp or external_id. It only works when the browser event arrives first and the server event second. That is why a shared event_id is the reliable default.

Google: Enhanced Conversions and hashed first-party data

Google’s version of this is Enhanced Conversions. When a conversion fires, it takes the first-party data the user already gave you: email, phone, name and home address. It normalizes that data (lowercase, whitespace trimmed) and hashes it with SHA-256, a one-way hash, before anything leaves the page or your server. Google matches the hash against hashes of signed-in Google accounts that engaged with your ads. This lets it attribute the conversion even after the click cookie is gone.

SHA-256 cannot be reversed, so Google never sees the raw email or phone number, only a fixed-length hash it can compare. You can send Enhanced Conversions through the Google tag, through Google Tag Manager, or through the Google Ads API up to 24 hours after the conversion is recorded. The API option makes a server-side setup simple. The thing to watch is normalization. A capital letter or a trailing space produces a different hash and the match fails, so format the data the same way every time before you hash it.

Consent Mode v2: which tags fire and when

In Europe, all of this depends on consent. Since March 2024, Google has required Consent Mode v2 from advertisers targeting the EEA and UK who want to keep using audience and measurement features. It passes the visitor’s choices to Google tags through four signals:

• ad_storage: whether advertising cookies may be set.
• analytics_storage: whether analytics cookies may be set.
• ad_user_data: whether user data may be sent to Google for advertising, including Enhanced Conversions.
• ad_personalization: whether the data may be used for remarketing and personalized ads.

There are two ways to implement it. In Basic mode, tags stay blocked until the user responds to the banner, so nothing is sent before consent. In Advanced mode, tags load with consent denied by default and send cookieless pings. The pings carry no identifiers, but Google uses them for conversion modeling and behavioral modeling. That gives a statistical estimate of the conversions from users who declined. A strict Basic setup never sees those conversions.

In Advanced mode, Consent Mode lets Google estimate the conversions from users who declined consent.

Server-side tagging: one container for all platforms

You can add CAPI to your checkout and Enhanced Conversions to your thank-you page separately. That works, but the tracking logic ends up in many places in the code. A server-side Google Tag Manager container keeps it in one place. The browser sends one small request to a container running on your own subdomain. The container then sends the event to Meta’s Conversions API, Google Ads, GA4 and any other destination. Hashing, enrichment and consent rules run on the server, where the browser cannot block them.

Cookies set in an HTTP response from your own server are exempt from Safari’s seven-day cap on JavaScript cookies, so attribution windows last longer. Sensitive data is hashed before it leaves your infrastructure. Consent is enforced in one place instead of separately in every tag. The cost is that you now run a container, including hosting, monitoring and versioning.

How tracking quality affects bidding

Automated bidding, such as Google Smart Bidding and Meta Advantage+, is a model trained on the conversions you send it. If you under-report, the algorithm bids as if some campaigns, audiences or hours of the day convert worse than they do, then moves budget away from them. So the tracking gap changes your spend as well as your reports. We explain how this works in our guide to automated bidding strategies.

Recovering the lost events reverses this. More accurate, deduplicated conversions give the algorithm more training data, which improves targeting and lowers cost per action. Meta cites this benefit for the Conversions API. The published numbers point the same way, but they come from platform and vendor studies, and there is no single agreed figure.

Use these percentages as a rough guide. Your result depends on your traffic mix, how much of it comes from Safari or sits behind a consent banner, and how clean your first-party data is. The platforms optimize toward what you measure, so fix measurement first, before you change any bid settings.

Rebuilding first-party measurement, step by step

Each step depends on the ones before it, so the order matters. A rough implementation path:

1. Collect first-party data at the conversion. Capture email, phone and order value at checkout or when a lead form is submitted. Every later match depends on this data.
2. Set up a server endpoint or an sGTM container. Create one server-side place that receives events and routes them, on a first-party subdomain.
3. Connect Meta CAPI with shared event IDs. Send server events alongside the Pixel. Generate one event_id per action and pass it to both. Check deduplication in Events Manager.
4. Turn on Google Enhanced Conversions. Normalize the first-party fields, hash them with SHA-256, and send them through the tag or the Google Ads API. Check the match rate in the diagnostics report.
5. Configure Consent Mode v2 (Advanced where the law allows it). Pass all four signals from a certified CMP, so modeling can run and EEA audience features keep working.
6. Check the totals, then let bidding use the data. Confirm the deduplicated totals look right, then let Smart Bidding and Advantage+ train on the recovered data.

Where Adriva fits

Adriva is built to handle this setup. It combines GA4, the Meta Pixel and the Google Ads tag into one deduplicated signal layer, then uses that data in every budget and bid decision. We describe the connection in how Adriva connects Google Analytics and pixels. Accurate cross-platform measurement is also what lets Adriva run Google Ads and Meta Ads from one workflow and compare creative performance on real ROAS instead of the partial numbers a browser-only pixel reports.

Google dropped the Chrome deadline for third-party cookies, but browsers still lose conversions. Collect first-party data, send it from your server, deduplicate it and respect consent choices. Then the automated systems spending your budget optimize toward the conversions that actually happened.