Server-side tracking

What actually changes: where the event is assembled and sent

With a browser pixel, a script running on the shopper's device assembles the event. It reads the page for order value and contents, reads its own cookies for the click and browser identifiers, and posts the payload to the platform's domain from the device. Everything about that chain is outside your control: the script has to load, execute, and complete its request before the shopper navigates away, on a device that may be running an ad blocker and a browser that limits how long the cookies survive.

With server-side delivery, your server builds the event from records it already holds — the order, the customer, the line items — and posts it to the platform's conversions endpoint as a server-to-server call authenticated with an access token. The shopper's browser is not involved at the moment of sending. The event fires because an order was written to your database, which is the most reliable signal in the business.

The identifiers change shape too. Instead of relying on a cookie the browser may have expired, the server sends hashed match keys — normalised email address, phone number, name, postal code — alongside any click identifier captured when the shopper landed and stored with the order, plus IP address and user agent. Match quality then depends on what you collected at checkout rather than on what the browser preserved.

What it fixes, and what it does not

It fixes delivery. Purchase events that were lost to a blocked script, a failed request or a shopper closing the tab at the payment redirect now arrive, and they arrive with match keys drawn from the order record rather than from whatever survived in the browser. It also unlocks a class of events the browser can never see at all: refunds, subscription renewals, chargebacks, cancellations and offline or phone orders, all of which happen long after the session ended and all of which materially change what the platform should be optimising toward.

It does not fix consent. This is the most common misunderstanding and the most expensive one. The obligation attaches to the processing of personal data, not to the wire it travels over. Sending an event about a shopper who declined consent is the same processing with a longer route, and the consent decision now has to be carried from the browser into your order record so the server knows whether it is allowed to send at all — work the pixel used to do implicitly.

It does not create identity you never collected. A guest checkout with no email and no stored click identifier is unmatched whether the event leaves from a browser or a server. It also does not replace on-page behavioural signals: if you want scroll depth or add-to-cart interactions server-side, the browser still has to report them to you first.

And it does not improve performance, only reporting. Turning it on raises reported conversions and lowers reported cost per acquisition immediately, because events that were always happening are now being counted. That is a break in the time series, not a result. Mark the date on the chart, and do not let anyone compare the month after against the month before as though the campaigns changed.

Deduplication: the event ID contract

Once both paths are live, every conversion the browser successfully reported is also reported by the server. The platform will count both unless you tell it they are the same event, and the way you tell it is a shared event identifier: both sides send the same event name and the same ID, the platform keeps whichever arrives first, and discards the other within its deduplication window.

Size the risk with an example. Assume 1,000 real purchases in a month and that 30% of browser events are lost — the browser reports 700, the server reports all 1,000. Without deduplication the platform records 1,700 conversions against 1,000 real ones, a 70% overstatement, and reported cost per acquisition falls to about 59% of the truth. The optimiser then learns from a signal in which some orders count twice and others once, which is worse than either path alone.

• Derive the ID from something both sides already know — the order ID is the obvious choice. Generating a random ID independently on each side guarantees they never match.
• Keep the ID stable across retries. A retry that regenerates the identifier turns your own error handling into a double-count machine.
• Match the event name exactly, including case and type. Platforms deduplicate on the pair, so a browser event and a server event that differ only in naming will both be kept.
• Send the browser click and browser identifiers with the server event as well. They are what lets the platform recognise the two reports as the same user, not just the same order.
• Respect the deduplication window. An event delivered days later — a delayed webhook, a backfill — is outside it and will be counted again.
• Test with real orders before trusting the numbers, and reconcile the platform's reported conversion count against your own order count for the same period. They should be close; a systematic gap in either direction is a wiring fault.

The operational cost nobody budgets for

A pixel is a tag someone pastes once. Server-side delivery is a service you now own, with an access token, a schema, a retry policy and a failure mode, and every one of those breaks quietly. An expired token, a platform API version that stopped accepting the payload you send, a deploy that dropped the click-identifier capture on the landing page, a hashing bug where email addresses were not lowercased and trimmed before hashing — none of these throw an error the marketing team will see. They present as a gradual decline in match quality or a sudden drop in conversions that looks exactly like a bad week of advertising.

So the monitoring is not optional and it is simple: compare server events sent against orders created, every day, and alert on divergence. Watch the platform's own event diagnostics or match-quality score, because a falling match rate is usually a data problem rather than an audience one. Log the response to every send rather than firing and forgetting, since a rejected payload is otherwise indistinguishable from a successful one.

Budget for the consent plumbing too. The decision has to be captured in the browser, persisted with the order, and read by the server before it sends — three components that all have to agree, in a system where the failure is silent in one direction and a compliance problem in the other.

The honest summary is that server-side tracking trades a category of unreliability you cannot fix for a category of maintenance you can. That is usually the right trade, and it stops being the right trade if nobody is going to own the pipeline after the quarter it was built in.