GuideMeasurement and attribution
Server-side tracking (Conversions API)
Definition
Conversion events sent to the ad platform from your own server, alongside or in place of the pixel in the visitor’s browser.
How it works
When an order completes, your server reports it to the platform directly: an API call carrying the order value and something the platform can match to a person, usually a hashed email or a click ID. The call survives what silences the pixel: ad blockers, browser tracking prevention, cookies that expired before the purchase. Events the browser lost come back into the count. Two limits are built in. A visitor who declined your consent banner stays off-limits on this route too; the API does not create consent. And wherever the pixel still fires, the same sale arrives twice, once from the browser and once from the server; without a shared event ID to collapse the pair, the platform counts two conversions.
What to watch for
Set platform-reported purchases against orders in the shop system for the same period; more reported than sold means deduplication is failing, and every ROAS built on the count is inflated with it. Mark the go-live date: if the rollout recovered signal, conversions step up on that date while sales do not, and any before-and-after comparison across it compares two counting methods. And ask where the server call checks consent. On the browser route, blockers stopped the event whether you wanted them to or not; on the server route, nothing stops it unless you built the check.
The question you ask
“Do the browser and server events share an event ID, or are some sales counted twice?”