Server-side tracking for WooCommerce — purchases reported by the shop server
We set up your own tracking server between your shop and Google or Meta, so purchases are reported by the shop server — with consent, filtered, and documented.
With browser tracking, every reported purchase depends on a script running on the order confirmation. Someone who closes the tab after paying, uses an ad blocker, or comes back in Safari after a week still buys — Google and Meta just hear about less of it.
Server-side tracking puts a tracking server of your own between your shop and the ad platforms. The shop server reports purchases directly, with the Meta Conversions API and enhanced conversions for Google Ads, and on the server we set which data is passed on. Consent still comes from your existing consent banner: without it, nothing is reported.
First we work out whether a tracking server pays off for you — or whether a lighter route is enough.
What you get
Purchases arrive without the thank-you page
The purchase is reported when WooCommerce creates the order — not only once the browser loads the order confirmation.
Google and Meta from one source
The same order goes as a conversion to Google Ads, to GA4 and through the Meta Conversions API — with one shared event ID, so nothing counts twice.
You decide what leaves
The tracking server is where it is set which fields are passed on to which platform, and which are not.
Who this is for
WooCommerce shops running Google Ads or Meta ads
When budget is allocated by reported purchases and those reports visibly trail your actual orders.
Shops with external payment methods
When some customers don't return to the thank-you page after PayPal, Klarna or a card check.
Shops advertising on Meta
When Meta so far only gets the pixel in the browser and the Conversions API is missing.
Working with an agency
When your agency recommends server-side signals and the technical work in the shop isn't in their hands.
Where purchase data gets lost today
With browser tracking, every reported purchase depends on a script running at the right moment on the right page. That often works — and where it doesn't, you are missing exactly the purchases your campaigns are judged by.
The thank-you page never loads
Someone who closes the tab after PayPal, Klarna or a 3-D Secure check has paid, but the purchase tag on the order confirmation never fires.
Ad blockers filter the tags
Filter lists in uBlock Origin, AdGuard or Brave block Google and Meta scripts. The purchase happens; the report stays stuck in the browser.
Safari forgets visitors sooner
Safari limits the lifetime of cookies set by scripts in the browser. Someone who comes back after a week and buys is no longer attributed to the original ad.
Meta only sees the browser side
Without the Conversions API, Meta only gets purchases through the pixel in the browser — with the same gaps as any other browser tag.
Unclear what goes to third parties
Browser tags send whatever the platform collects, full page URLs included. Often nobody has decided how much of it is actually needed.
Purchases counted twice
A plugin reports the purchase from the server, the pixel reports it again from the browser — without a shared event ID, the platform counts both.
Comparing WooCommerce orders with reported purchases often shows the size of the gap on its own.
What we set up
Server-side tracking means your own tracking server sits between your shop and the ad platforms. These building blocks are part of most projects.
Your own tracking server
Server-side Google Tag Manager, hosted for example with Stape on servers in the EU and reachable through a subdomain of your shop.
Purchases from the shop server
WooCommerce reports the order directly to the tracking server, with order number, value and currency — whether or not the thank-you page loads.
Meta Conversions API
Purchases also go to Meta server-side. Browser and server reports carry the same event ID, so Meta merges them into one purchase.
Enhanced conversions for Google Ads
Google Ads receives hashed customer data such as the email address with the conversion, so purchases can be matched to ad clicks more reliably.
Data filter
On the tracking server we set which fields go to which platform — and strip out what the measurement doesn't need.
Connected to your consent banner
Consent still comes from your existing banner, such as Borlabs Cookie or Complianz. It is saved with the order, and the server only reports what consent was given for.
Not every shop needs every building block — we tell you up front which ones make a difference for you.
Lighter routes — compared honestly
Your own tracking server isn't the only option. For some shops less is enough, and some things sold as server-side tracking aren't.
Purchase tracking via plugin
PixelYourSite Pro can send purchases from the server to GA4 through the GA4 Measurement Protocol. That closes the missing-thank-you-page gap for GA4 without a tracking server of your own.
Meta Conversions API via plugin
Several WooCommerce plugins send purchases to Meta server-side. For shops that mainly advertise on Meta, that is often the shortest route.
Google Tag Gateway is a proxy
It serves Google's scripts and measurement requests from a path on your own domain. Measurement still happens in the browser — it isn't server-side tracking.
Limits of Tag Gateway
It only helps with visitors who have given consent, and common filter lists such as uBlock Origin's still block the requests. Some hosts' Cloudflare integrations, Cloudways' among them, don't support it.
A relay on your own server
Where Google Tag Gateway isn't available, the same principle can be rebuilt with a lean relay on your web server. Pointed at a tracking server, it also runs server-side GTM through your main domain.
When it pays off
A tracking server costs setup and ongoing hosting. That adds up where ad budget is allocated by reported purchases.
Ongoing budget on Google or Meta
When bidding strategies optimise for purchases, more complete reports give them more to learn from.
Few purchases, large baskets
With low order volumes, every unreported purchase weighs more heavily in how a campaign is judged.
No significant ad budget
Then a tracking audit comes first. If GA4, Tag Manager and conversions don't count correctly in the browser yet, a tracking server only moves the errors.
Running costs
Hosting the tracking server is a monthly amount you pay directly to the provider. It depends on the provider and on your shop's traffic.
If a lighter route is enough, we'll tell you.
What isn't included
So the scope is clear from the start:
Campaign management
We set up the measurement and hand it over. Ads, bids and budgets stay with you or your agency.
No legal advice
We implement what your consent tool requires, technically. Whether your setup as a whole is permissible is for your legal advisor to judge.
No complete capture
Without consent nothing is reported, not from the server either. Server-side tracking closes technical gaps, not this one.
The groundwork
GA4, Tag Manager and Consent Mode in the browser are a separate service. Server-side tracking builds on top of them.
How it works
Assessment
We compare the orders in WooCommerce with the purchases that reach Google and Meta, and look at your plugins, tags and consent tool.
Choose the route
Plugin route, your own tracking server or a relay on your web server — decided with you, based on ad budget, hosting and running costs.
Set up the tracking server
Server-side Tag Manager with the chosen provider on EU hosting, connected through a subdomain or a relay on your domain.
Connect the shop
WooCommerce reports purchases to the server, consent is saved with the order, and browser and server reports get a shared event ID.
Test
Test purchases with and without consent, checked in GA4, in Google Ads' diagnostics and in Meta Events Manager to confirm each purchase arrives once.
Document and hand over
A short overview of what is reported where, which data is filtered, and where the running costs arise — for you and your agency.
Before we start, we settle which access is needed and which provider hosts the server.
Why a tracking server can pay for itself
The value isn't in the server, it's in the decisions based on reported purchases:
More purchases that arrive
Purchases from customers who gave consent are no longer lost just because a page didn't load or a script was blocked.
A better basis for bidding
Automated bidding at Google and Meta learns from reported purchases. The fewer are missing, the less the platform has to guess.
Control over the data flow
What goes to Google and Meta is set in one place and traceable, instead of being spread across tags and plugins.
Maintainable when things change
New payment method, new plugin, new platform — it's documented where changes need to be made.
Frequently asked
What is server-side tracking?
Instead of your customers' browsers sending data straight to Google and Meta, measurement data first lands on a tracking server of your own, usually a server-side Google Tag Manager. From there it is passed on to the platforms. The shop server itself can also report purchases, so they don't depend on the browser.
Do we still need consent?
Yes. Consent still comes from your existing consent banner, such as Borlabs Cookie or Complianz. We save it with the order, and the server only reports a purchase to the platforms consent was given for.
What does it cost to run?
Besides the setup, there is a monthly hosting fee for the tracking server, which you pay directly to the provider. The amount depends on the provider and your shop's traffic. On the plugin route there is no tracking server, but there may be a plugin licence instead.
Where is the data?
We set up the tracking server with a provider hosting in the EU, Stape for example. From there the data goes on to Google and Meta — which fields, we set on the server.
Isn't Google Tag Gateway the same thing?
No. Tag Gateway serves Google's scripts and measurement requests from a path on your domain, but measurement still happens in the browser. It only helps with visitors who have given consent, common filter lists still block it, and some hosts' Cloudflare integrations, such as Cloudways', don't support it. Where it's missing, we can rebuild the principle with a relay on your server.
Isn't a plugin enough?
Sometimes, yes. PixelYourSite Pro can send purchases to GA4 through the Measurement Protocol, and several plugins handle the Meta Conversions API. If what you're mainly missing is purchases without a thank-you page, that is often the cheaper route. Your own tracking server pays off when several platforms are involved and you want to control centrally which data leaves.
Does it help against ad blockers?
It reduces the losses but doesn't eliminate them. Purchases reported by the shop server never pass through the browser. Whatever still loads in the browser can be recognised by a filter list, even with your own tracking server.
What changes with Safari?
Safari limits the lifetime of cookies set by scripts in the browser. A tracking server can set cookies itself — how long Safari keeps them depends on how the server is connected. A relay on your main domain works best; a subdomain works with restrictions.
Does it work with our consent tool?
Usually, yes. We work with Borlabs Cookie regularly, and Complianz and other common tools can be connected as well. What matters is that the customer's choice can be carried through to the order.
Does this make our setup privacy-compliant?
We implement your consent tool's settings technically, report only with consent, and filter out data that isn't needed. Whether your setup as a whole is permissible is for your legal advisor to judge — we don't give that assurance.
Is it worth it for our shop?
If you put ongoing budget into Google Ads or Meta ads, usually yes. If not, a tracking audit is the better first step — a tracking server doesn't make misconfigured conversions correct.
Are your purchases arriving where you pay for them?
Tell us your shop and where you advertise. We compare orders with reported purchases and tell you whether a tracking server, a plugin or an audit first is the right step.
