What does server-side tracking actually change?
In the browser-only model, every vendor tag runs on the customer's device and sends its own request - each one visible to ad blockers, constrained by browser privacy features, and dependent on the page surviving until the request completes. In the server-side model, the browser sends events once to an endpoint you control, and your server fans them out to vendors - Google, Meta, TikTok - over their measurement APIs. What changes is reliability and control of delivery: fewer lost events at checkout, one place to shape and filter payloads, first-party request paths.
What does it not fix?
- Consent. A visitor who declined tracking is still a visitor who declined tracking. Routing data through your server does not create permission - it concentrates the responsibility to honor the refusal, provably.
- Identity. The APIs match conversions to platform users via identifiers (hashed email, click ids). If your checkout does not capture those cleanly, server-side delivery is reliable transport of unmatched events.
- A broken data layer. If the browser observes the wrong value or fires twice, the server faithfully forwards the wrong value twice. Garbage, durably delivered, is still garbage.
How does the Shopify data layer fit in?
Shopify's customer events layer runs tags in a sandboxed context and exposes a defined set of commerce events - the modern replacement for the checkout-page script tags of old themes. The groundwork that decides whether server-side pays off happens here: mapping the platform's events to your schema, carrying transaction ids for deduplication, and capturing consent state as an event property so every downstream decision can honor it. Teams that skip this and jump straight to a server container inherit their old event bugs at higher infrastructure cost.
Browser pixel, conversions API, or both?
| Setup | Strength | Weakness |
|---|---|---|
| Browser pixel only | Simple; platform-maintained | Loss at checkout from blockers and browser policies |
| Conversions API only | Durable delivery; full payload control | Loses browser-context signals platforms use for matching |
| Both, with deduplication | The platforms' own recommended posture: browser signal plus durable server truth, joined by a shared event id | Deduplication ids must be correct or you double-count - this is the audit point |
The one metric that decides the business case: event delivery gain at the purchase step, measured against the orders table. If purchases recorded rise toward the orders count after cutover, the project paid. If nothing moves, the loss was never in transport.
What should be verified after cutover?
Three captures: the browser still consented-gated correctly (server-side is a common place consent enforcement quietly disappears); event ids deduplicating across browser and server senders; and platform diagnostics showing match quality rather than just receipt. Then the reconciliation against orders, again - the same standard as before the migration, because the migration's whole claim is measured there.