Server-side tracking: what it is and when it is worth it

What is server-side tracking, and is it worth setting up for my online store?

For years, every ad platform learned about your sales the same way: a pixel in the visitor's browser fired an event when the purchase page loaded. That still works for most visits, and it fails for a growing share of them. Server-side tracking moves the most important events off the browser. It is often sold as one thing, and it is really two, which solve different problems.

Two things called "server-side"

Server-to-server conversion APIs. When an order exists in your store, your backend calls the ad platform directly: Meta's Conversions API, Google's conversion uploads, TikTok's Events API. No browser is involved, so the purchase is reported even if the thank-you page never loaded.

Server-side tagging. A tag manager container runs on a server you control, usually on a subdomain of your site. The browser sends its events to your domain, and the server forwards them to each platform. Google's version is server-side Google Tag Manager. The events still start in the browser, but they travel first-party.

Many setups use both: the backend reports purchases, and the tagging server carries the rest of the journey, page views, product views, add-to-cart events.

What it solves

• Blocked and lost browser events. Ad blockers, tracking protection and closed tabs stop a pixel. A purchase sent by your backend does not depend on any of them.
• Purchases completed later. Orders paid by bank transfer or cash, or approved after a fraud check, can be reported when they are actually paid instead of when the browser happened to be on the page.
• Control over what is sent. On your server you decide which fields leave, hash personal data before sending it and drop what a platform does not need.
• Fewer third-party scripts on the page. Moving tags off the browser can make pages lighter, which helps the conversion rate you are trying to measure.

What it does not solve

• Double counting. If you send a purchase from the browser and from the server, the platform receives two events. Meta collapses them into one only if both carry the same event ID. Google has no equivalent safety net for the same order uploaded twice, so your side has to record what was already sent. We go through this in what the Conversions API actually fixes.
• Matching. A server event is only useful if the platform can match it to a person. That depends on the click identifiers you captured when the visitor arrived (fbclid, gclid) and on customer data hashed exactly as each platform expects. For Meta that is plain SHA-256 of a normalized value; a keyed hash is accepted and matches nobody.
• Attribution itself. Sending purchases more reliably makes the platforms' numbers more complete. It does not stop each platform from claiming the same order, so it raises the importance of checking claims against your store's orders.
• Consent. Moving collection to a server changes where data travels, not whether you may collect it.

What it costs

For self-hosted server-side Google Tag Manager, Google's Cloud Run setup guide estimates about $45 a month per server and recommends a minimum of two to reduce the risk of data loss, with autoscaling beyond that under load. Hosted providers remove the infrastructure work; Stape, for example, lists a free tier up to 10,000 requests and paid plans from $17 a month billed yearly, priced by request volume. Sending purchases from your own backend costs development time more than hosting, and platforms such as Shopify, WooCommerce and VTEX already emit order webhooks to start from.

When it is worth it

• Yes, if you spend meaningfully on Meta, Google or TikTok with campaigns optimized for purchases. The platforms bid on the conversions they receive, so conversions they never see are sales they cannot learn from.
• Yes, if a large share of your traffic is on Safari or mobile browsers with tracking protection, or your checkout completes on another domain.
• Yes, if your customers often pay later, by transfer or cash, and the purchase page is not where the sale really happens.
• Not yet, if your spend is small, most sales happen on a marketplace you cannot tag, or nobody will maintain the setup.

A practical order of work

Start with purchases from the backend, because that is the event with the most money attached. Use the order number as the event ID on both sides. Capture click identifiers on landing and store them with the order. Then add the Google side, covered in Google Enhanced Conversions, and TikTok's, in TikTok Events API. Finally, make the browser side first-party, which is what first-party cookies are about.

Adray does the backend half for the stores it connects: it receives orders from Shopify, WooCommerce, VTEX and Magento, sends purchases to Meta's Conversions API from the server once per order with the order number as the event ID, and its pixel can collect through your own domain.