What is server-side tracking? A guide for webshops

Server-side tracking means that conversion events, such as a purchase, are sent to ad platforms from a server instead of only from a script in the shopper's browser. For a webshop, the server sends each order to Meta, TikTok or Google through their APIs, so the sale is reported even when the browser pixel is blocked or never loads.

This guide explains the difference between a browser pixel and server-side tracking, follows the data from the ad click to the ad platform, and shows what a server event contains. It also covers deduplication, server-side tagging, consent and how to tell whether your store needs it. For the Shopify setup itself, read server-side tracking on Shopify.

Browser pixel vs server-side tracking

A browser pixel is a piece of JavaScript from the ad platform. It runs on your pages and sends events from the shopper's device straight to the platform: a page view, an add to cart, a purchase on the thank-you page. It works only when the script loads, runs and reaches the platform before the shopper leaves the page.

Server-side tracking moves the sending to a server. The event can start from data your shop already has, such as a paid order, and the server posts it to the platform's API. Meta calls this API the Conversions API and TikTok calls it the Events API. Google Ads uses enhanced conversions, which add hashed customer data to a conversion.

Running both gives the platform the most complete data. The browser event adds cookies and page context. The server event arrives even when the browser fails. A shared event id makes sure the platform counts each purchase once.

How does server-side tracking work?

Server-side tracking for a webshop has two halves. The first half happens in the browser: when a shopper lands from an ad, a script saves the click id from the URL. The second half happens on the server: when the order is paid, the server links that click id to the order and sends the purchase.

Capturing the click

Ad platforms add a click id to the landing URL: fbclid for Meta, ttclid for TikTok, gclid for Google Ads and msclkid for Microsoft Ads. The click id is the strongest link between a sale and the ad that caused it, so it must be saved on the first page view. UTM parameters add the campaign, ad set and ad names in a format you control.

Matching the order

The server then needs to know which visitor placed the order. The most reliable link is a value that travels with the cart into the order, such as a visitor id saved on the cart. Other methods are weaker: an email address the visitor entered earlier on the site, or the same IP address and browser seen shortly before the order. Each webshop platform offers different options. Our guide for other webshops lists the methods ROASaurus uses per platform.

Sending the event

Finally, the server posts the purchase to each platform's API. The event includes the order value, the click id and customer data that helps the platform find the person who clicked. If a platform is down or returns an error, a good setup tries again later, so the purchase is not lost.

What does a server event contain?

Every platform has its own field names, but a purchase event carries the same kinds of data everywhere. Here is a shortened example for the Meta Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Hashing turns an email address into a fixed string of characters. The same address always gives the same string, but the string does not show the address. The platform uses the hashed values only to look for a match among its own users. This is how a purchase can be matched to the person who saw or clicked the ad, even when that person's browser blocked the pixel.

How does deduplication work?

When the pixel and the server both send the same purchase, the platform must count it once. Both copies carry the same event name and the same event id, for example order-1042. Meta compares the pair and keeps one copy, as long as the second copy arrives within 48 hours of the first.

Most double counting comes from two senders that do not share ids. A typical case is a platform's own shop app and a separate tracking tool that both send purchases with their own ids. Our help article on preventing double counting lists the usual causes and fixes.

Server-side tagging vs sending from order data

The term server-side tracking is used for two different setups. Both send events from a server, but they start in different places.

Server-side tagging, such as Google Tag Manager server containers

With server-side tagging, the browser sends its events to your own server instead of to each vendor. The Google Tag Manager server container is a well-known example. It runs in your own Google Cloud project or in another environment you choose. It receives requests from the browser, and its tags forward the data to Google Analytics, Meta and other vendors. You decide what data goes where, and the server can run on a subdomain of your site.

The events still start in the browser. If the tag in the browser is blocked, or the thank-you page never loads, the server container has nothing to forward. You also run, pay for and update the server yourself.

Sending from order data

The second approach starts the purchase from the order record in your shop. The shop reports the paid order to the server through a webhook or an API, and the server sends it to every connected platform. The browser is only needed earlier, to save the click id when the shopper lands.

The two approaches can be combined. Many stores collect page views and add-to-cart events in the browser, and send the purchase from order data. The purchase is the event that ad platforms use to report ROAS and to optimize bidding, so it is the one that most needs to be complete.

What does server-side tracking fix, and what does it not fix?

Consent still applies

Server-side tracking is a way of delivering data, not a way around privacy rules. Where the law requires consent for marketing cookies or tracking, that requirement covers the data you collect, whichever route it takes to the platform. Moving a tracker to your server does not change what a visitor agreed to.

Attribution stays platform-specific

Each platform still credits purchases with its own windows and rules. Server events give every platform better data, but the totals across Meta, TikTok and Google can still add up to more than your shop's revenue. To compare channels with one set of rules, use one attribution model across all of them, such as the models in ROASaurus attribution.

Does your store need server-side tracking?

A store that spends a meaningful budget on paid social or search ads usually benefits. The case is strongest when several of these points are true:

• The ad platform receives clearly fewer purchase events than your shop has web orders. Our guide to ad blockers and tracking shows how to measure this gap.
• Many of your visitors use Safari on iPhone or Mac, where cookies set by scripts last 7 days at most. See Safari ITP and ad tracking.
• Shoppers often buy days after the first ad click.
• Payment finishes outside your site, or orders are paid later, as with cash on delivery or bank transfer.
• You optimize campaigns for purchases or purchase value, so the platform needs every sale to learn from.

Here is how a gap changes decisions in practice. An example store has 1,000 web orders in a month. Its Meta pixel reported 820 Purchase events, so 18% of orders never reached Meta from the browser.

The store's break-even ROAS is 2.5, and Ads Manager shows a ROAS of 2.3 on pixel data. On those numbers the campaigns lose money. If ad-driven orders were missed at the same 18% rate, the real ROAS is about 2.3 ÷ 0.82 = 2.8, which is above break-even. That is an upper estimate, because not every missing order came from an ad. It still shows how a tracking gap can make a profitable campaign look like a loss.

Server-side tracking matters less for a store that does not advertise, or that spends very little on ads.

How ROASaurus sends server-side events

ROASaurus captures 19 click ids and six UTM fields on landing and stores them with a first-party visitor id. It sends each purchase from your shop's paid orders to Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll and Outbrain. On Shopify, Google Ads conversions are sent from the Shopify checkout. Browser pixels can run next to the server events with the same event id, and Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin and Spotify deduplicate them. Every delivery and the platform's response are listed in the Event log.

Read more on the server-side tracking page, or find your webshop on the integrations page.

Sources

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

In ROASaurus

• Server-side tracking in ROASaurus
• Consent and privacy
• Preventing double counting

Keep reading