Ecommerce Analytics · focused work
Server-side tagging for ecommerce
Server-side tagging moves event collection off the shopper's browser and onto a server the store controls. The browser sends one request to that server, and the server passes events on to analytics and advertising destinations. It buys durability against browser restrictions and one place to govern what leaves the store. It also costs money to run and skill to keep running.
This is the right work if
- Ad platforms record far fewer conversions than the store's own order list contains
- Identifiers set by browser scripts expire quickly and returning visitors keep appearing as new
- Several tags collect the same customer fields and nobody has reviewed what each vendor receives
- Purchase tracking depends entirely on a confirmation page that some shoppers never load
- The business has to document which data fields are shared with which vendor
What it is
The parts of a server-side setup
There are four components. A tagging server, running on infrastructure the store pays for and sized to its traffic. A subdomain on the store's own domain pointing at that server, which is what makes the collection request first-party. A client on the server that receives events from the browser. And destination tags that forward those events onward, each with rules about which fields it receives. Alongside that sits the piece that matters most for a store: the purchase sent directly from the store's backend when an order is created, using the same event identifier as the browser event so destinations recognise them as one purchase rather than two.
It is equally important to be clear about what this does not do. It is not a way around consent, and it does not recover data from someone who declined. It does not fix an incomplete measurement plan; a badly specified event is just as wrong on a server as it was in a browser. What it does is make collection more durable where browser storage is short-lived or scripts are blocked, let the order be reported from the system that knows it happened, and put the decision about which fields reach which vendor in one reviewable place instead of scattered across a dozen tags.
How it is done
The work, in order
What changes
- Measurement survives browser restrictions that shorten or block collection in the page
- Orders are reported from the system that created them rather than from a page load
- One reviewable place decides which data fields reach which vendor
- Duplicate conversions are prevented by an identifier shared across both paths
Size the problem before building
Measure the actual gap between the store's orders and what each platform reports, and check how much of it is consent, blocking or a plain tagging fault. If most of the gap is a broken event, fix that first, because the server will forward the same broken event faithfully.
Stand the server up on your own subdomain
Provision hosting appropriate to the store's traffic, point a subdomain of the store's own domain at it, and put uptime and error monitoring in place from day one. An unnoticed outage here loses measurement quietly for as long as it lasts.
Move browser events across with a fallback
Route existing events through the tagging server to their destinations and keep the previous path available while both run, so a comparison is possible and a rollback is quick. Compare counts per event for a full week before switching over completely.
Send the order from the backend
Trigger a purchase event from the store's own order creation, carrying an identifier that matches the browser event so destinations deduplicate. This is the part that makes revenue reporting independent of whether a confirmation page ever rendered.
Put consent and field rules in one place
Enforce the visitor's consent state on the server, define exactly which fields each destination receives, hash what needs hashing before it leaves, and record the whole mapping in a document the business can hand to a reviewer.
Reconcile, then keep watching
Compare conversions per platform against store orders before and after the switch, check for duplicates in the first weeks, and track server cost against traffic so the running expense stays visible rather than appearing on an infrastructure bill nobody reads.
Platform notes
Shopify
Order webhooks are the natural trigger for the backend purchase event, and browser side collection runs through the customer events sandbox, so the two paths use different mechanisms and both need the same event identifier written into them.
WooCommerce
A hook on the order status transition serves as the backend trigger, which also means deciding which status counts as a sale, since a store that reports on order creation and one that reports on payment will not produce the same totals.
Does moving collection to a server change what consent is needed?
No. Consent requirements follow what is being collected and why, not where the code runs. A server-side setup should enforce the visitor's choice at least as strictly as the browser did, and presenting it as a way to keep measuring people who declined would be both wrong and risky.
Will it recover all the conversions the platforms are missing?
Some of them, not all. The gains come from longer-lived identifiers, requests that are less likely to be blocked, and an order sent from the backend. Losses caused by consent declines, cross-device journeys and modelled reporting remain, so expect an improvement rather than a reconciliation.
What does it cost to run?
Hosting billed by traffic, plus the engineering time to configure, monitor and update it. The infrastructure cost scales with visits rather than orders, which is why the case is stronger for stores with high traffic and meaningful ad spend than for small stores with quiet catalogs.
Can a smaller store justify the setup?
Sometimes, but usually only after the simpler work is done. Complete event tracking, a well-designed consent banner and the ad platforms' own direct conversion connections close much of the gap at a fraction of the effort. Server-side tagging is worth it when those are in place and the gap is still large.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.