Blog · 2026-08-30

Track First, Scale Later: Dual-Sending Pixel and CAPI With a Shared event_id

Browser-side pixels lose events in the iOS privacy era. We dual-send the same event with one shared event ID, deduplicate it, and feed clean match keys, which put measured event match quality at 6 to 7.

The ads are spending, but the conversion count in the ad platform never lines up with the actual orders. Customers clearly bought, yet the Pixel reported nothing, because the sale closed on a third-party checkout page off your site and browser-side tracking never sees that step. Even when the sale does happen on your site, the iOS share of it comes back incomplete. The algorithm learns who to target from that broken signal, and the more budget you pour in, the further off it drifts.

Why a Pixel Alone Will Always Miss Events

Browser-side tracking has been cut down year after year. Apple's ATT lets a user refuse tracking with one tap. Tracking prevention in Safari and Firefox has slashed cookie lifetimes. Ad blockers drop the pixel request outright. The common industry estimate is that these factors together cost pure browser-side tracking somewhere around 20 to 30 percent of events.

What you lose is not just a number in a report. Meta's delivery algorithm learns who buys from your conversion events, and if two or three tenths of the textbook are missing, the audience it builds is skewed. The fix is clear enough: open a second, server-side channel (the Conversions API) that posts straight from your server to Meta, out of reach of browser extensions. But once both channels fire, the same conversion gets counted twice, so deduplication becomes the first engineering problem in this architecture.

Dual-Send Deduplication: event_id Is the Only Bridge

Our setup: the front-end Pixel fires the event as usual, and at the same moment the server sends the identical event again through CAPI. The CAPI endpoint is self-hosted on a Cloudflare Pages Function, so the front end calls our own endpoint and that endpoint attaches the credentials and forwards to Meta. The access token never touches the front end, and any validation or filtering we want to add later stays in our hands.

Deduplication relies on Meta's matching rule: same event name plus same event_id means one event, counted once. So the event_id has to be generated once on the front end and handed to both the Pixel and the backend. Do not generate it separately on each side, and do not pad it with a fixed string. It has to be a value that is unique per event. Failed deduplication costs you more than an ugly report: one sale counted twice makes performance look like it doubled, and you will decide to raise budget on a number that is not real.

Verification is not optional. Before going live we confirmed the event_id matched exactly on both sides, the CAPI endpoint got events_received:1 back from Meta, and the Test Events tool showed both events paired and flagged as deduplicated. Only then did we let it through.

Match Keys: Normalize First, Hash Second, Drop the Garbage

Meta uses match keys to tie an event back to a real person, and event match quality (EMQ) scores exactly that. We send six keys: email, phone, last name, first name, city and country, all normalized on the server before they are SHA256 hashed and sent. Normalization follows the official spec: email lowercased with whitespace trimmed, phone stripped of symbols and leading zeros with the country code prefixed. The rules have to line up, or the two sides will not produce the same hash.

Putting normalization on the server is deliberate. There is exactly one copy of the rules, so a front-end release cannot make the same person's hash drift. The rejection rules are just as strict: malformed emails, phone numbers with too few digits, and empty values never get sent. Correctness comes first. Bad data that gets hashed and shipped matches nobody and drags the overall match quality down, which means you spent effort sending noise.

With this in place, measured EMQ on our on-site intent events sits at 6 to 7 on Meta's ten-point scale. Nothing mystical about it: the keys are complete and the keys are clean.

Offline Uploads Carry No IP or UA, and That Is on Purpose

For the part of the sale that happens off site, we upload the Purchase event through CAPI with action_source set to system_generated, and we deliberately omit IP and user agent.

The reason is simple: that sale did not happen in the user's browser, so you do not have their real IP or UA at that moment. Substituting your own server's IP is feeding a fake signal. It matches nobody and it pollutes match quality, so you lose twice. Send less rather than send wrong. And because offline events lack the browser-side environment signals, matching rests entirely on the match keys, which means the normalization and rejection rules from the previous section decide directly whether these events find a person at all. This batch uploaded 7 events successfully, and for the first time the algorithm had a list of real off-site buyers instead of only seeing who arrived and never how it ended.

Closing: Do Not Scale Budget on Unverified Tracking

The whole architecture is three things: dual-send deduplication on a shared event_id, normalized and hashed match keys, and offline uploads that never fabricate signals. Get that done and the algorithm finally receives a complete, clean buyer signal, which is what makes scaling defensible. Raise budget before tracking is verified and you are paying to teach the algorithm the wrong lesson. Verify at least three things before you scale: event_id identical on both sides, Test Events showing the pair as deduplicated, and EMQ in a healthy range.

If your ad platform conversion counts never reconcile with real orders, or the sale happens in an off-site system entirely, we have run this whole path end to end, from self-hosting the endpoint to cleaning match keys to gating the launch on verification. Come talk to us.

We Turned Tracking Into a Service

The deduplication and parameter work above runs on every new account we take on. It is the first stop before any media spend.

• Conversion event dual-send deduplication: Pixel and CAPI fire together, aligned by one shared event ID, counted once
• Parameter completion: click ID, browser ID and hashed customer data filled into the fields that should carry them, raising match quality
• Free tracking health check: we look at what you have installed today before anyone talks about changing it

Three tiers, one-time build:

Specs and delivery timelines are on Data Tracking and Attribution Setup. Do not rush to add budget before tracking is installed correctly. That is the rule we apply to every account we take over.