Platform signals not deduplicated

Symptom and cause

Symptom

Meta and Google report more conversions than actually happened. The browser hit and the server hit both claim the same sale.

Cause

Server-side conversions sent without the dedup key the platform needs: Meta CAPI and the Pixel firing without a shared event_id, or Google's server and browser conversions without a shared transaction_id, so the two hits are never recognised as one sale.

Where it's caught

Meta Events Manager showing low or zero deduplication; conversion counts running above actual order counts.

How browser and server both claim one sale

One sale produces two hits by design. The browser sends the Meta Pixel or the Google web tag, and the server sends the Conversions API, the Measurement Protocol or the sGTM tag. Each hit fires exactly once and each is individually correct. The platform collapses the pair into one conversion only when both copies carry the same dedup key, and the key is not the same across platforms. Meta deduplicates a Pixel event against a Conversions API event only when the event_id and the event_name both match, on the same dataset, within roughly a 48-hour window. The event_id has to be byte-for-byte identical, so "order_12345" does not match "12345" and the string "12345" does not match the number 12345, and the event_name match is case-sensitive, so a Pixel sending "Purchase" against a CAPI event labelled "purchase" double-counts even with an identical event_id. If either field differs, or one side carries no event_id, both copies count, unless Meta's weaker fbp/external_id fallback applies (browser event received first, with fbp and/or external_id consistent on both copies; see the fix). Google reconciles on a different key. Google Ads treats a second conversion on the same conversion action with the same transaction_id (the order id) as a duplicate and drops it, so an imported, server or Measurement-Protocol conversion deduplicates against the browser conversion tag on a shared transaction_id. The ids must match exactly, since a different prefix, suffix or an extra space breaks the match, and the id is capped at 64 characters. The keys are not interchangeable. event_id reconciles Meta, transaction_id reconciles Google, and sending the wrong key to a platform fixes nothing. fbp, fbc, fbclid and hashed user data are user-matching and attribution signals, not dedup keys, and timing is not the matcher either. Firing the browser event first and the server event second is good practice and influences which copy Meta keeps, but correctly-keyed events match regardless of order and identical-timing events still fail without the shared key. Meta's window is the only documented one, approximately 48 hours. Google publishes no fixed window for Ads or GA4.

event	Pixel / browser	CAPI / server	shared key?	counted
page_view	evt ████-a01	evt ████-a01	yes	1×
add_to_cart	evt ████-c14	evt ████-c14	yes	1×
Purchase / purchase	Purchase · order_████-9f3	purchase · ████-9f3	no, id and name differ	2×

no shared key, so both count

How to catch it

1. Read the dedup readout in Meta Events Manager first. Open the dataset, select the purchase event and open its details view, where the source breakdown (browser / server / both) and the deduplication readout live, and check whether the event was received from the browser, the server, or both, and whether it was deduplicated. A low or zero deduplication rate while reported conversions run above true order counts is the F-102 fingerprint. The exact menu wording shifts over time, so read the function, not a fixed label.
2. Separate this from F-101 before touching anything. In DevTools, Network, switch on Preserve log, complete one purchase, then filter on /tr for the Meta Pixel and on /g/collect for GA4. DevTools Network confirms only the browser leg: one /tr for the Meta Pixel, one /g/collect for GA4. GA4 batches several events into one request, so confirm the purchase inside the payload (the en=purchase parameter) rather than counting request rows. For an sGTM first-party setup the browser posts to the server container path, not /g/collect, so filter on the server container hostname instead. The server copy (Meta CAPI, or the sGTM / Measurement-Protocol call) is server-to-server and does not appear here. Read it in Meta Events Manager (event received from the server) or in the sGTM container / server logs. The separator is this: two hits from the same source in Network is F-101; one browser hit in Network plus a server-side copy confirmed in Events Manager or server logs, with a missing or mismatched key, is F-102. The two can co-exist, so confirm which you have.
3. Inspect the event_id on both copies. On the Pixel /tr request read the dedup id from the query string (it rides as the eid parameter, the on-the-wire form of the fbq eventID property). On the server copy read event_id where the server leg is observable, in the sGTM container Preview for an sGTM/CAPI setup, read the incoming value on the request's Event Data tab, then confirm the value actually sent to Meta on the CAPI tag's Outgoing HTTP Request (the event_id field in the request body), since a tag- or transformation-minted id will not appear in the inbound event data, or in Meta Events Manager Test Events (the server-received event's parameters) for a direct CAPI integration. It is not in the browser Network tab. Confirm the /tr eid and the server event_id are the identical string for one sale: "order_12345" against "12345", or a string against a number, will not match.
4. Check the event_name on both sides for an exact case match. Meta treats "Purchase" and "purchase" as two different events, so a Pixel firing standard "Purchase" against a CAPI event labelled "purchase" will not deduplicate even when the event_id is identical. Read the event name on the Pixel hit and on the server payload and confirm they are the same string, same case.
5. For the Google side, confirm the transaction_id is present and exactly equal on the browser conversion tag and the server, imported or Measurement-Protocol conversion. In Google Ads, open Goals > Summary and select the Diagnostics tab. If the conversion action ships data from both the tag and a server/imported source, a "Conversions using multiple data sources" card appears, open View Details and read the transaction-ID match-rate warning (the "Your conversions may be overcounted" alert fires when fewer than 10% of transaction IDs match between the tag and the additional data source over the past two days). The "Conversions using multiple data sources" card and the 10%/past-2-days overcount alert live in Google's multiple-data-sources diagnostics, which is a beta surface and may not appear on every account. Where it is absent, fall back to comparing transaction_id presence and exact equality on the tag against the imported/server source directly, or the conversion-action tally against the order count. A different prefix, suffix or a stray space breaks the match, and a blank transaction_id is treated as a real value, which under-counts rather than over-counts.
6. Rule out Event Match Quality as the cause. In Events Manager read the EMQ score separately from the dedup status: a dataset can hold a high EMQ and still double-count when event_ids do not match, and can deduplicate correctly on a mediocre EMQ. If conversions run above orders while EMQ looks healthy, the fault is the missing shared key, not match quality.

What putting it right involves

1. Mint one dedup key per sale at source and carry it to both hits. Generate a single stable id from the order id at order creation, set it as event_id on the Meta Pixel and on the Conversions API event, and as transaction_id on the Google browser tag and on the server, imported or Measurement-Protocol conversion (the Google Ads imported/server conversion is the reliable transaction_id matcher; for the GA4/Measurement-Protocol leg the shared id is best-effort only, web-stream and undocumented-window, per the FAQ). The same value must reach both copies of the same sale; a per-fire or per-hit id defeats the whole mechanism. Keep the shared id within Google's 64-character transaction_id limit and free of leading or trailing spaces, since that is the tighter of the two platform constraints, a value chosen for Meta can still fail Google if it runs too long.
2. Match the event_name exactly on Meta. Send the same name, same case, from the Pixel and the CAPI event ("Purchase" on both, not "Purchase" against "purchase"). Meta needs the event_id and the event_name to agree, so a correct id with a mismatched name still double-counts.
3. Send the right key to the right platform and do not swap them. event_id is the Meta key; transaction_id is the Google key. Sending a transaction_id to Meta or an event_id to Google reconciles nothing. Sending the matching key to both browser and server is what collapses the pair into one conversion.
4. Keep the firing order as good practice, not as the matcher. Fire the browser event first and the server event second: this influences which copy Meta keeps and enables Meta's secondary fbp/external_id fallback, which deduplicates on event_name plus fbp and/or external_id only when the browser event arrives first. The primary match still comes from the shared event_id within Meta's window (approximately 48 hours), so do not rely on timing to reconcile, and treat the fbp/external_id route as a weaker, order-dependent backstop, not a substitute for minting the shared event_id.
5. Treat the shared key and Event Match Quality as separate jobs. A shared event_id deduplicates the two hits; it does not raise EMQ, and a high EMQ does not deduplicate anything. If match quality is the real concern, send hashed first-party data (email, phone) on the CAPI event, which is the F-402 work, not this fix.
6. Verify in the platform readouts, not against the store. Re-run one purchase and confirm Events Manager shows the event received from both browser and server and marked deduplicated, with the dedup rate climbing, and confirm Google Ads no longer flags the imported conversion as a second count on the same transaction_id. The Meta Events Manager dedup readout is the fast check. The Google-side confirmation lags because imported/offline conversions and Ads reporting take time to process, so read the Google duplicate-flag check after Google's processing delay, not immediately on the test purchase. Keep the revenue-versus-store reconciliation on F-302; F-102's proof is the platform-side dedup readout and conversions falling back to the order count.