Server-side tracking for Shopify, explained simply

The short answer

Server-side tracking means your paid orders are sent to ad platforms from a server, using their server APIs (the Meta Conversions API, the TikTok Events API, Google's conversion uploads and so on), next to the browser pixel. Events from a server can't be stopped by an ad blocker, a closed tab or a thank-you page that never loaded.

It doesn't replace the browser pixel, and it doesn't replace cookie consent. Done well, it fills the gaps the pixel leaves, so your ad platforms learn from more of your real sales.

Browser tracking vs server-side tracking

Browser tracking (the classic pixel) runs in the visitor's browser. It's easy to install and it sees everything the visitor does on the page, but anything that stops scripts — ad blockers, privacy settings, a closed tab — stops the tracking too.

Server-side tracking sends events from a server you (or your tool) control, using the ad platforms' server APIs: the Meta Conversions API, the TikTok Events API, Google's conversion uploads, the Snapchat Conversions API and the Pinterest Conversions API. The buyer's browser isn't needed for the event to arrive.

Why Shopify stores lose purchases in the browser

On Shopify, pixels for the checkout run through the Customer Events system. Shopify's Help Center says app pixels and custom pixels run in a secure sandbox and load on the storefront, checkout, thank-you page and order status page (checked October 2026). In markets that require consent, such as the EEA and the UK, they only run once the visitor has given the permissions the pixel needs.

So the purchase still depends on a browser: the right page has to load, the sandbox has to be allowed to run, and nothing on the device may block the request. Typical places where that goes wrong:

• Ad blockers and privacy browsers block the pixel's requests to Meta, TikTok or Google.
• Safari and iOS limit cookies, so a buyer who comes back days after the ad click is harder to link to it.
• Buyers who pay through an external page (a wallet or buy-now-pay-later flow) or close the tab right after paying may never see the thank-you page.
• In-app browsers (Instagram, TikTok) are short-lived; buyers often switch to Safari or Chrome to pay and the click goes with it.
• A strict cookie banner, or a visitor who simply ignores it, means marketing pixels don't run at all.

You want both, not one or the other

The best setup sends every event from the browser and from the server, with the same event id. The platform keeps one of the two (deduplication). If the browser event was blocked, the server event still gets through; if both arrive, nothing is counted twice.

The browser pixel still matters: it sees page views, add-to-carts and checkout steps as they happen, and it sets the browser ids (like Meta's _fbp) that help the platform match the server event to a person.

What a good server-side setup sends

• The purchase at the moment the order is paid, straight from the store's order data — not from a thank-you page that may never load.
• The ad click id from the landing URL (fbclid, ttclid, gclid, ScCid), saved when the visitor arrives and kept until they buy.
• The browser ids the pixels set (like Meta's _fbp), so the platform can connect the server event to the browser.
• Hashed email and phone (SHA-256), never in plain text.
• Order value and currency, and the products.
• The same event id as the browser event, for deduplication.

What server-side tracking can't do

It's often sold as a fix for everything. It isn't:

• It doesn't make consent optional. If a visitor said no to marketing cookies, you still have to respect that, on the server too.
• It can't link every sale to an ad. The platform still has to recognise the buyer; without a click id or matching details, a purchase arrives but may not be attributed to a campaign.
• It doesn't fix a broken setup. Two apps sending the same purchase without a shared event id will still double count.
• It doesn't make your ads better on its own. It gives the algorithm more of your real sales to learn from; the creative and offer still have to work.

Your options on Shopify

Shopify's own sales channel apps can send some server events for their own platform. The Facebook & Instagram app, for example, has data sharing levels: on Enhanced and Maximum it uses Meta's Conversions API as well as the pixel, on Standard only the pixel (Shopify Help Center, checked October 2026). That helps, but each platform is set up separately and you don't control what's sent.

Google Tag Manager with a server container gives full control, but needs hosting, Shopify webhooks or custom scripts to feed it, and someone who knows GTM well to keep it running.

A dedicated tool like Settl takes care of all platforms at once: one line in your theme, connect your pixels, done. Paid orders come straight from Shopify's order data, failed sends are retried, and you see per order which platform received it.

Whichever you pick, check you're not running two server connections for the same platform (say, the Facebook channel on Enhanced and another Conversions API app) without deduplication. That's a common cause of Ads Manager suddenly showing more purchases than Shopify.

How to check that it works

• Meta: Events Manager → your dataset → Overview. The Purchase event should show both Browser and Server as connection methods, with deduplication.
• Compare a few days of paid orders in Shopify with the purchases each platform reports for the same days. Server-side tracking should narrow the gap; a platform reporting more purchases than you have orders points at double counting.
• Place a test order and follow it through: did each platform receive it, and only once?

What about privacy and GDPR?

Server-side tracking doesn't remove your obligations. You still need a cookie banner and a privacy policy that explain what you send to ad platforms. Personal data should be hashed before it leaves your systems, and only what the platforms ask for should be sent.

Common questions