Server-side tagging and conversion APIs

Two things that get used interchangeably and aren’t the same.

Server-side tagging changes where your tags run. The browser sends one request to an endpoint on your own domain, and a server you control fans that event out to whichever vendors need it. Google’s server-side GTM is the common implementation, though the pattern predates it and you can build your own collector.

Conversion APIs change where the event originates. Meta’s CAPI, Google’s Enhanced Conversions, TikTok’s Events API and the rest accept events sent directly from your backend, with hashed identifiers, no browser involved at all. The order-confirmed event fires from the system that knows the order exists, rather than from a pixel hoping the confirmation page loaded.

You can run either without the other. They’re usually deployed together because they solve overlapping halves of the same problem.

What they fix

• Recovering events lost to blocking. A request to your own domain isn’t on a blocklist. This is the main pitch and it’s real.
• Cookie lifetime. Cookies set by your server in an HTTP response aren’t subject to the same aggressive caps browsers apply to cookies set by client-side JavaScript. Returning-visitor recognition survives longer, which is directly relevant to everything covered in consent and tracking loss.
• Page performance. Every vendor tag you remove from the browser is script you no longer ship, parse and execute. On a tag-heavy site this is one of the larger available Core Web Vitals wins, particularly for INP.
• Data control. The server is a chokepoint where you decide what each vendor receives. You can strip fields, hash identifiers, and stop sending a marketing platform things it has no business having.
• Reliability for backend truth. Events that originate server-side (order placed, subscription renewed, refund issued) get reported accurately rather than depending on a browser reaching a thank-you page.

What they don’t fix

Consent still applies. Server-side collection changes the transport, not the legal basis. If a user declined tracking, you don’t get to send their data because it left from a different machine. Any vendor pitching server-side as a way around consent requirements is selling you a compliance problem with a latency improvement attached.

It also doesn’t fix bad instrumentation. If your event schema is inconsistent and your data layer is unreliable, moving it server-side gives you the same mess in a more expensive location. Fix the contract first.

Deduplication is where it goes wrong

The most common failure in the field, by some distance.

Once you’re sending conversions from both the browser pixel and the server API, the platform receives the same purchase twice. It needs to recognise them as one event, and it does that by matching a shared event ID that you generate and include in both payloads. Get that wrong and every conversion counts twice.

The symptom is unmistakable and frequently celebrated: reported conversions roughly double shortly after the CAPI implementation goes live, with no corresponding change in revenue. If your ad platform reports 400 purchases and your commerce backend reports 210, you have a dedup bug, not a measurement improvement. Check backend truth before anyone builds a slide about the uplift.

The corollary is that CAPI makes ad platform numbers less comparable to their own history for a while. Note the changeover date, because the step change in reported performance is an artefact.

Match quality

CAPI’s value depends entirely on the platform being able to tie your event to a person. That means sending good identifiers - hashed email, hashed phone, the click ID from the ad platform, IP and user agent. Send an order event with none of these and it’s effectively discarded.

Capturing and persisting click IDs is the unglamorous work that determines whether the whole project pays off. If a user arrives with a click ID and converts four days later, that ID has to have survived the intervening sessions and be attached to the order record. Where it doesn’t survive, match rates fall and the platform optimises on partial data.

Where it connects to experimentation

Server-side collection is the reliable path for experiment data, for the same reasons it’s reliable for ad platforms - it doesn’t depend on the browser cooperating. If you’re choosing where experiment exposure and conversion events get recorded, server-side is the answer.

Separately, moving assignment server-side is the fix for flicker, covered in server-side vs client-side experimentation. Different problem, same architectural direction, and worth doing in one project rather than two.

For leadgen, this is the plumbing that offline conversion imports run on top of. You can’t feed closed-won CRM data back to the ad platforms without a server-side path to send it down.

The honest cost

This is infrastructure. A server-side container needs hosting, monitoring, alerting and someone who understands it when it breaks at the weekend. Costs scale with request volume, and a busy site is a real line item.

It’s a growth-engineering commitment rather than an app you install. For a store where the tag load is light and the measurement gap is modest, the cost may not clear the benefit. For a site where ad platforms are the primary acquisition channel and match quality directly determines campaign efficiency, it usually does.