Server-side tracking sends your store's measurement data to a server you control first, and that server passes it on to Google Analytics, Meta, Google Ads and any other tool you use. Most online stores that run paid ads every month should have some form of it, and many can get the most useful part from their store platform before paying for a tagging server of their own.
The pressure comes from the browser. Ad blockers stop pixels from loading, Safari deletes script-set cookies after a few days, and platforms such as Shopify are moving tracking code out of the open page. Each of those turns a real sale into a missing conversion, and an ad platform that can't see your sales can't learn which ads bring them in.
How server-side tracking differs from browser tags
With standard browser tracking, every tool gets its own script on your store. A shopper adds a product to the cart and their browser fires one request to Google Analytics, another to Meta, another to Google Ads, and one more for every app that wants to know. Each vendor collects what its script is built to collect, and you see whatever it reports back.
Server-side tracking puts one stop in the middle. The browser, or your store's backend, sends a single event to your server, and the server decides what goes where. Google's introduction to server-side tagging describes a server container that "runs on a server that you control" instead of in the shopper's browser or phone, and only you can see the data until you choose to send it on.
That middle step lets you clean events before any tool sees them, for example by fixing event names or adding the order value from your own records. It lets you strip fields such as IP addresses or email addresses, so each vendor gets only what it needs. And every vendor tag you move off the page is one less script a shopper's phone has to download and run.
Server-side setups come in two kinds, and the difference matters later. In the first, your store's backend sends the event, so a purchase travels from your platform's servers to the ad network with no browser involved. In the second, the browser still sends events, but to your own tagging server instead of to each vendor.
Why online stores lose conversion data in the browser
Browser tags fail quietly. The checkout works, the order lands in your admin, and the pixel never reports it. These are the causes worth checking.
Ad blockers stop pixels before they fire. Shopify's help page for its Meta integration says a browser-based ad blocker can prevent the Meta pixel from sharing data. Some browsers do this without any extension: Brave says its Shields are on by default for every site and block trackers and cross-site cookies.
Safari forgets the ad click. Apple's WebKit engine runs Intelligent Tracking Prevention, which blocks all third-party cookies and deletes cookies created by JavaScript after 7 days without the shopper interacting with your site. When the visitor arrives from a known tracker through a link carrying tracking details, that limit drops to 24 hours. A shopper clicks your ad in Safari on an iPhone, leaves, and comes back 10 days later by typing your address to buy. The cookie that tied them to the ad is gone, so the ad platform never credits the sale.
Platforms are retiring open scripts. Shopify has announced that script tags, the older way apps injected code into storefronts, stop running on March 1, 2027. For analytics and conversion tracking it points developers to web pixels, which run in a sandbox and respect customers' privacy permissions. If your tracking still depends on an older app, check what it will run on after that date.
The damage goes beyond a wrong report. Meta says the events advertisers send feed the systems that target ads and lower cost per result, so every purchase it misses is a signal it never gets about who to show your ads to next.
What it fixes, and what it does not
The biggest gain comes from events sent from server to server. Shopify's help page says that when the purchase event goes between Shopify's servers and Meta's servers, browser-based ad blockers can't block it. A purchase your backend records reaches the ad platform whether or not the shopper's browser cooperated.
A tagging server on your own domain helps with Safari as well. Google's custom domain guide says the default setup on a Google domain can only set JavaScript cookies. A first-party setup gets the more durable cookies a server can set, and Google lists a same-origin setup, where requests reach the tagging server through your main domain, as best practice.
Before you pay for one, know its limits:
- The browser still has to send the first event to your tagging server. If that request goes somewhere a blocker recognises, it gets blocked like any pixel.
- Safari watches for disguised setups. WebKit says it detects third-party CNAME cloaking and IP address cloaking and caps cookies set in those responses at 7 days, so a subdomain that resolves to someone else's server can land back under the same limit.
- Bad data stays bad. Duplicate purchases, missing order values or a broken checkout tag get forwarded faithfully.
- A server changes where data is processed, not whether the shopper agreed to it, so your consent banner must still control what gets forwarded.
- A tagging server needs monitoring, updates and someone who understands it when the numbers look odd.
What it costs to run
Hosting is the visible cost. Google's Cloud Run setup guide puts each Tag Manager server at about $45 a month and recommends running at least 2 instances to reduce the risk of data loss during an outage. That's roughly $90 a month before anyone configures a single tag. Google expects 2 to 10 autoscaling servers to handle 35 to 350 requests per second, depending on how many tags you run and what they do.
Setup and upkeep come on top. A developer or agency has to map your events, connect each destination, test deduplication and recheck the numbers after every theme or checkout change.
The cheaper route is already built into many platforms. Shopify's Facebook and Instagram app has data sharing levels, and the higher ones run the Conversions API alongside the Meta pixel, sending the purchase event from Shopify's servers to Meta's. Those levels also share customer details such as name and email address so Meta can match shoppers to its users. Meta lets advertisers who already have a pixel set up the Conversions API from Events Manager in one click, with no code, configuration or setup fees. For a store whose ad budget goes mainly to Meta, that delivers the server-to-server purchase event, the part blockers can't touch, without new hosting.
Does your online store need server-side tracking?
Run one check first. Compare the orders in your store admin for the last 30 days with the purchase events Google Analytics recorded over the same days. Every order should create a purchase event, so the gap is what your browser tags are missing, whether to blockers, cookie limits or a broken tag. If your admin shows 400 orders and Analytics shows 310, then 90 sales, more than one in five, never reached your reports, and your ad platforms are working from the same thin picture.
A full server-side setup pays its way when:
- You run paid ads every month and the gap is big enough to change which campaigns look profitable.
- You send data to three or more tools, for example Google Analytics, Google Ads, Meta and a CRM, and want one place to control all of them.
- You need to remove or reshape personal data before vendors receive it.
- Vendor scripts are slowing your product and checkout pages.
Hold off and use the server connections your platform already offers when your store takes a handful of orders a day, most sales come from organic search or email, or your purchase events are already wrong. Paying about $90 a month in hosting, plus setup, to recover a few untracked orders buys precision a small store can't use yet. Fix the events first.
A sensible order for setting it up
Work through it in this order, and each step tells you whether you need the next one.
- Audit your current events. Every purchase should fire once, with the right order value and currency.
- Get consent working, so a shopper's choice controls every tag on the page.
- Switch on what your platform includes, such as Shopify's Meta data sharing levels or Meta's one-click Conversions API setup.
- If you still need more control, set up a Tag Manager server container on your own domain, and move it to production mode before it handles live traffic, as Google recommends.
- Run browser and server events side by side, then confirm in each platform that duplicates are removed. Meta's own setup steps ask you to check that events are deduplicated and matched correctly.
- Repeat the orders against purchases check after 30 days.
That last number tells you whether the hosting bill is paying for itself. If you'd like help working out which of these steps your store needs, get in touch with the Techno Mantra team through our contact page and ask for a quote.
Frequently asked questions
Partly. Purchase events your store's server sends straight to an ad platform, such as Shopify sending purchases to Meta through the Conversions API, can't be blocked by a browser ad blocker. Events that start in the shopper's browser can still be blocked on their way to your tagging server.
Google estimates about $45 a month per server for a Tag Manager server container on Cloud Run and recommends at least 2, so roughly $90 a month in hosting before setup work. Platform options cost less: Meta lets advertisers with a pixel set up the Conversions API in one click with no setup fees.
No. The Conversions API is Meta's way of receiving events from a server. Server-side tracking is the wider setup, such as a Tag Manager server container, that can feed the Conversions API, Google Analytics and other tools from one place.
Yes. Moving tags to a server doesn't change what the shopper agreed to, so the choices in your consent banner have to decide which events the server forwards.
Yes, if it takes a handful of orders a day and spends little on ads. Fix your purchase events and switch on your platform's built-in server connections first, then look again when ad spend grows.