Server-Side Tagging for Shopify: A Complete Setup Guide

Why Shopify Stores Are Moving Tracking Server-Side

For years, a Shopify store's analytics and advertising tags lived entirely in the browser. Each pixel — analytics, ad platforms, affiliate scripts — loaded its own JavaScript, set its own cookies, and sent data straight from the shopper's device to a third party. That model is now breaking down. Browser tracking-prevention features shorten or block third-party cookies, ad blockers strip pixels before they fire, and privacy laws require genuine consent before any of it runs.

The result is a widening gap between what shoppers actually do and what your reports capture — lost conversions, broken attribution, and ad platforms starved of the signal they need to optimise. Server-side tagging closes much of that gap. Instead of every tag firing from the browser, your store sends events to a server container you control, and that container forwards clean, first-party data to each destination.

This guide focuses on Shopify specifically. If you want the broader rationale and architecture first, read Server-Side Tracking: Benefits and Architecture and our Server-Side GTM Setup Guide, then come back for the Shopify-specific steps.

The Two Halves of a Shopify Server-Side Setup

A Shopify server-side implementation has two distinct pieces that people often conflate:

• Capturing events from the storefront. Shopify exposes shopper behaviour through its Customer Events system (also called Web Pixels). This is where you observe page views, product views, add-to-cart, checkout steps, and purchases in a sandboxed, Shopify-sanctioned way.
• Forwarding events to destinations. A GTM server container, hosted on your own infrastructure or a tagging host, receives those events and dispatches them to analytics and advertising platforms server-to-server.

The Customer Events layer answers "what happened?" The server container answers "who needs to know, and in what format?" Keeping the two responsibilities separate is what makes the setup maintainable — you can change destinations without touching your storefront, and you can adjust storefront capture without redeploying tags.

Step 1: Stand Up a Server Container

Begin by creating a Server container in Google Tag Manager (not the default Web container). GTM will give you a tagging server URL once you deploy it. You host the container yourself — commonly on a cloud run service — or through a managed tagging host. The key requirement is that it runs on a custom subdomain of your store, such as sgtm.yourstore.com, so requests are first-party rather than cross-site. A first-party endpoint is what lets the resulting cookies survive browser tracking prevention.

Once the server container is live, test it with GTM's Preview mode to confirm it receives requests and that the default client is parsing them.

Step 2: Capture Events with a Customer Events Pixel

In your Shopify admin, go to Settings → Customer events and add a custom pixel. Shopify runs custom pixels in a sandbox with access to a well-defined event API: analytics.subscribe('checkout_completed', ...), product_viewed, product_added_to_cart, and so on. Your pixel code subscribes to the events you care about and forwards them to your server container's endpoint.

Because the pixel runs in a sandbox, it cannot reach into the page's DOM the way a classic theme script could — but for tracking purposes the structured event API is actually richer and more reliable than scraping the page. Send each event as a request to your tagging server, including the event name, the cart or order data Shopify provides, and any identifiers you are permitted to use.

Step 3: Wire the Server Container to Your Destinations

With events arriving at the server, configure tags in the server container to forward them. The typical destinations for a Shopify store are a web-analytics platform and one or more advertising platforms' server-side conversion endpoints. For each destination:

• Map Shopify's event fields to the destination's expected schema — order value, currency, line items, and transaction ID.
• Pass hashed customer identifiers (such as a hashed email) only where you have a lawful basis and the destination supports them, to improve match quality.
• Send a consent signal with each event so downstream platforms can adjust their behaviour, mirroring how Google Consent Mode v2 works on the web.

Server-side forwarding is where data quality is won or lost. Because you control the payload, you can deduplicate events, strip fields you should not send, and standardise currency and value formatting before anything leaves your infrastructure.

Step 4: Validate Before You Trust the Numbers

A server-side setup fails quietly: events look fine in Preview but never reach the destination, or purchases get counted twice because both a browser pixel and the server tag fire. Validation is not optional. Confirm that each destination receives the right number of events, that order values match Shopify's own reports, and that no event slips through when a shopper declines consent. Our Server-Side Tracking Validation guide walks through a systematic debugging process for exactly this.

A common Shopify pitfall is double-counting purchases: the native Shopify integration for an ad platform fires a browser conversion at the same time your server container forwards one. Decide on a single source of truth per destination and disable the duplicate.

Related Guides

Read Server-Side Google Tag Manager: Complete Setup Guide for the platform-agnostic foundation, Server-Side Tracking Validation for testing, and Server-Side Tagging for WordPress for the same approach on another platform. For authoritative documentation, see Google's server-side tagging docs and Shopify's Web Pixels (Customer Events) API.