What is Server Side Tracking for Shopify Stores

Ildi Veliu

Written by Ildi Veliu

What is Server Side Tracking for Shopify Stores

Meta pixel fires while GA4 shows the sale. Everything looks connected. Then you check your ad account against your actual Shopify orders, and the numbers don't match.

That's not a glitch. The browser is losing the signal before it reaches the ad platform and Shopify changed enough this year that the old fixes don't cover it anymore. Server side tracking is the fix. Instead of the browser talking straight to Meta, Google, or TikTok, it talks to a server you control first, and that server decides what gets sent, and where.

This article covers how to set up server side tracking on Shopify, for which stores it’s best fit and the mistakes to avoid.

What does server side tracking mean?

Server side tracking is sending customer events like purchases and add-to-carts from your own server instead of the visitor's browser, so ad blockers and browser restrictions can't stop them before they reach Meta, Google, or TikTok.

In a normal setup, a script sits in the visitor's browser. The moment something happens, a page view, a cart add, a purchase, it fires an event straight to Meta, Google, or TikTok. Ad blockers can see that script and stop it. Safari and Firefox restrict what it's allowed to set. If the visitor closes the tab half a second early, the event never fires at all.

Server side tracking moves the handoff behind the scenes. The event goes to a server you control first, often through a custom subdomain like data.yourstore.com, which forwards it to whichever platforms you've set up, carrying whatever data you choose to send. The browser is no longer the only thing standing between a sale and your ad account knowing about it.

This isn't cookieless tracking. The server still sets a cookie. It's just a first party cookie from your own subdomain, not a third party one from a vendor's domain, which is exactly why it survives restrictions the old setup didn't.

If GA4 itself isn't set up yet, start there first. What follows builds on top of it, it doesn't replace it.

If it's not cookies, what changed?

A lot of what's written about this still says Chrome was about to kill third party cookies. It didn't. Google reversed that decision in April 2025. It shut down most of Privacy Sandbox by October. Third party cookies are still on by default in Chrome. Safari, Firefox, and Brave still block them, just like they always have. That was never a Chrome problem to begin with.

Three updates from Shopify and Google here matter.

What changed

When

What it affects

Shopify's app pixel default switched from Always On to Optimized

January 13, 2026

Third party app pixels only. Custom pixels and server side tracking are untouched

Custom checkout scripts stopped working on non-Plus stores

August 26, 2026

Every store, every plan. Web Pixels is now the only way in

Google turned on native server to server GA4 tracking

July 2026

Purchase event only, Google properties only


Under Optimized, Shopify can throttle or pause a pixel's data if it decides the signal isn't useful. It doesn't tell you when this happens.

The checkout change finished what Plus stores already went through the year before. If a store hasn't touched Additional Scripts since then, whatever used to live there stopped firing months ago, on every plan, not just Plus.

Google's new connection is a genuine improvement, and it's free. But it does nothing for Meta or TikTok. Anyone running ad spend anywhere besides Google Ads still has the exact problem this article is about.

For which stores is server side tracking most useful?

Server side tracking makes sense for stores running real ad spend across more than one platform, where a missing percentage point of signal actually costs money. A smaller store running occasional ads on one platform will get more out of just checking that Settings > Customer Events is set to Always On than building out a full server side stack.

Server side tracking closes a real gap, but it comes with real tradeoffs of its own, and a few of them only show up after the setup is already live. Worth weighing both sides before treating this as the obvious next step for every store.

Pros and cons of server side tracking for Shopify

Advantages

Disadvantages

Harder for ad blockers to catch, since requests read as first party

Takes setup, either engineering time or a monthly fee

Catches sales that client side tracking misses entirely

Needs ongoing maintenance, not a one time job

Improves match quality on platforms like Meta, when deduplicated correctly

Gets numbers wrong in a different way if event_id dedup isn't set up

Cuts third party script weight, which also helps page speed

Doesn't touch attribution modeling, only data collection

More control over what data goes where, especially if built in house

Doesn't reduce consent obligations under GDPR or similar laws

How do you set up server side tracking on Shopify?

On Shopify, the flow usually starts with a custom pixel. It's set up under Settings > Customer Events. It listens for a checkout event, then sends it to your server container's endpoint.

Web Pixels run in a sandboxed iframe with no direct access to the page. So the pixel passes data through Shopify's API instead of scraping it off the screen. That's a deliberate security choice, not a limitation you're working around.

A server side setup needs four pieces in place:

  • A web container, collecting events from the browser the way a normal GTM setup does

  • A server container, which receives those events, enriches them, and forwards them on

  • A custom subdomain, mapped to the server container so requests read as first party instead of crossing to a vendor's domain

  • A host, either self-managed on Google Cloud Run or through a managed provider like Stape, which handles provisioning, domain mapping, and the SSL certificate for you

Creating a web container from the Meta Tag Manager

Don't confuse this with Shopify Scripts.That's a separate system, the engine behind discount and shipping rules, running on its own deprecation schedule. None of it touches tracking.

DIY server side tracking setup or let an app handle it?

DIY GTM is the right call for stores with real ad spend and someone technical on staff to maintain a Cloud Run instance. Otherwise it turns into a fire drill every few months. Apps like Elevar, Stape, Taggrs, and Converlay do the same job through a monthly fee instead of owned infrastructure. They make more sense for stores without that person on staff.


DIY GTM

Managed app

Cost

Cloud Run hosting, cheap infrastructure wise

Monthly fee, from free (Stape) to about $225/month (Elevar)

Control

Full control over configuration

Configured through the vendor's interface

Maintenance

Ongoing, needs someone technical

Handled by the vendor

Setup time

Days to weeks

Hours

Best for

Real ad spend, in-house technical capacity

No dedicated dev resources

Either way, the cost is engineering time, not money. Self hosting on Cloud Run is cheap on infrastructure. You pay in hours instead, building and maintaining it. Neither path is inherently more responsible than the other. It comes down to whether the store has technical staff to own it, nothing more.

Common mistakes in setting up server side tracking in Shopify


Running Conversions API without deduplication

A store adds Conversions API on top of an existing Meta pixel and never deduplicates the two. Event Match Quality climbs toward 9 or 10, and reported conversions quietly double. Fix it with a shared event_id sent from both the browser pixel and the server event.

A live event match quality score from the Meta Events Manager

Assuming server side tracking replaces consent

Moving tracking server side doesn't touch consent requirements either. If a visitor needs to opt in under GDPR or a similar law, that's still true. It doesn't matter if the event travels through a browser or a server. Server side tracking changes where the data goes, not whether you needed permission to collect it in the first place. Google's consent mode changes affect this directly and get their own coverage separately.

Review your store’s tracking setup

None of this is complicated once it's built. It's just easy to get quietly wrong, and the wrong version looks identical to the right one in every dashboard except the one that matters: your bank account.

If a second set of eyes on a server side setup would help, especially on the Meta and Instagram side, Shero's analytics team walks through exactly this every week for Shopify stores running Meta ads.

Book a call with our team.

FAQs on Shopify server side tracking

Does server side tracking fix attribution, or just data collection?

Server side tracking fixes collection only. It gets more of what actually happened onto the platform's servers. It doesn't decide which channel gets credit for a sale, that's attribution modeling, a separate problem with its own fixes.

What's the most common reason a tracking setup works in testing but breaks in production?

DNS, more often than not. The custom subdomain looks fine in a browser during testing, but if it isn't fully propagated or the SSL certificate hasn't finished provisioning, requests fail silently once real traffic hits it. Worth testing from a few different networks, not just the one in the office.

Why do reported numbers jump right after switching to server side tracking?

Because the setup starts catching sales that were always happening but never getting reported, not because more people started buying. Expect a step up in reported revenue the first week or two, and don't read it as a performance win.

How do I know my tracking is actually broken, and not just normal platform variation?

Some gap between ad platform numbers and actual Shopify revenue is expected: different attribution windows, currency handling, refunds landing on one side and not the other. A real problem looks different. It's a sudden, unexplained drop that lines up with a theme update, an app change, or a platform update, not a steady gap that's been sitting there for months.

Does anything extra need checking before a high volume period like BFCM?

A dry run at real volume, not just one test checkout. Push enough test orders through to see whether dedup and match quality hold steady the way they do on a normal day. Cheap to check ahead of time, expensive to find out on the day itself

Ildi Veliu

Ildi is a Technical SEO Specialist at Shero Commerce on a mission to help websites unlock their full organic potential. With a background in Informatics-Economics, he bridges the gap between technical web development and search engine algorithms, specializing in technical audits and search performance strategy. He is always looking for new ways to outsmart the algorithms and drive high-intent organic traffic.