How a Shopify brand should be wired, in eight layers.
This is the setup I use for home and furniture brands on Shopify spending between $25k and $500k a month on ads. It’s my working method, not an industry standard. If you don’t run the tracking yourself, read the short version and the one plain sentence under each layer.
What is the Tracking Stack?
The Tracking Stack is my eight-layer reference architecture for wiring conversion tracking on a Shopify brand: the store, the GTM web container, a server-side container, GA4, Google Ads, Meta, email and SMS identity, and a weekly written report. Each layer feeds the one below it, in that order. Fixing one out of order does not hold.
The short version
- The Tracking Stack is how I set up sales tracking for Shopify stores: eight layers, built in order, from the store to a weekly written report.
- The store’s own order data is the source of truth. Every other number is downstream of it.
- Google Analytics is for understanding the site, not for judging which ads made money.
- Google and Meta should each count every sale once, at the right value. Google gets the sale from your server. Meta gets it from both the browser and your server, with a shared ID so it counts once.
- The last layer is a short written summary every Monday on what changed and why.
I rebuild it myself, as a fixed-price one-time project. Fixing tracking is typically $2,500, inside the $2,500 to $20,000 range for one-time projects, and I quote it from the free audit before work starts. If you're not sure your tracking is broken yet, my custom audit is free and comes back within 24 hours of read-only access. See how projects are priced
Every home and furniture brand I audit has a tracking problem before it has a media buying problem. The two compound. Bad data leads to bad bids. Bad bids lead to wasted spend. The founder concludes the channel is broken. Emma Grace Home, a furniture store I designed, had GA4 filing its revenue as Unassigned and a Google Ads campaign optimizing toward add-to-carts. Here's what was broken. This is the architecture I rebuild every account to. Read it once, share it with whoever runs your tracking, then come back to me with a real conversation about what's leaking.
Running a service business or lead-gen account? Read the Lead Quality Stack instead
A number that won't reconcile? Diagnose it in the Conversion Tracking library
Hand it to whoever runs your tracking. Every layer, the dedup contract, a glossary, the post-2025 Shopify checkout extensibility audit, and the June 2026 Shopify Scripts cutover.
- 8 Layers, in order
- 1 Primary purchase conversion
- 1× Each sale counted once, browser and server
- Mon Written summary, every week
- L01
The store
Shopify · Source of truth · Web Pixel API on the order event
- L02
GTM web container
Browser tag manager · Fires conversion events client-side
- L03
Server-side container
First-party endpoint (sGTM / Stape) · The spine · Fans out to platforms
- L04
GA4
Behavioral analytics · Audience export · Not the source of truth for ad performance
- L05
Google Ads
Server-side conversion API + Enhanced Conversions · One primary conversion
DEDUP · event_id (shared with L06)
- L06
Meta + paid social
CAPI + browser pixel deduped via event_id · TikTok, Pinterest fan out from sGTM
- L07
Email + SMS
Klaviyo / Postscript · First-party identity graph · Feeds back into Meta CAPI + Google Customer Match
IDENTITY BACKFLOW → L03
- L08
Reporting
Written Monday summary · Looker Studio for ad-hoc · Not a real-time dashboard nobody opens
event_id from the server container so neither double-counts the purchase. Click any layer to jump to its breakdown.
Layer 1: The store
Shopify, or whatever runs the transaction. It is the source of truth.
Your store has to record each order cleanly and hand the order details, plus the buyer’s email and phone, to the tracking. Every other number starts there.
Everything else is downstream of what Shopify says happened. Orders, refunds, line items, customer identifiers. Before a single conversion fires, get the storefront emitting clean data. That means a properly configured Shopify Customer Events pixel, the post-purchase order data exposed to GTM, and the email and phone hashed and ready for downstream platforms.
- Shopify Customer Events pixel (sandboxed, no third-party tags)
- Order data exposed to dataLayer post-purchase
- Email and phone SHA-256 hashed for enhanced conversions and CAPI
Layer 2: The container
The GTM web container. It is the traffic cop, not the storefront.
One tool, Google Tag Manager, decides when each tracking tag runs, so tracking can be changed or rolled back without editing the store.
The GTM web container is where everything else lives. Not the Shopify code editor. Not hard-coded in theme.liquid. The container is the single deploy surface so you can roll back any tag without touching the store. Lock down trigger conditions to prevent the standard mistake of firing purchase events on cart pages.
- One web container, owned by the founder, not the agency
- Triggers gated on actual server confirmations, not URL path
- Versioned, with a working preview mode before every publish
The most common trigger anti-pattern is wiring conversions to Click Text matched against specific button copy. Every CTA change kills the data, silently.
Read the audit of my own containerLayer 3: Server-side
A GTM server container. It earns its keep where client-side tracking breaks.
A second Tag Manager runs on a server you control, on your own web address. Browsers and ad blockers lose fewer of your sales that way.
Server-side GTM is not optional in 2026. Safari and iOS strip client-side cookies, ad blockers eat client-side beacons, and conversion APIs (Meta CAPI, Google Ads enhanced conversions) prefer server signals anyway. Run a server container on a custom subdomain. Forward purchase events from the web container to the server, then fan out to Google, Meta, GA4 from there.
- GTM server container on a custom subdomain (e.g. data.yourbrand.com)
- Web container forwards purchase events to server
- Server container fans out to Google Ads, Meta CAPI, GA4
A server container is only as good as the events that reach it. At Emma Grace Home, a furniture store I designed, the full server-side stack received zero ecommerce events. Every server tag waited on data layer events, and the one checkbox that pushes them was unchecked in the tracking app.
Read the Emma Grace Home tracking fixLayer 4: GA4
GA4 is for analytics, not attribution.
Google Analytics shows how people move through the site. It isn’t the place to decide which ads made money.
GA4 is for behavioral analytics: which pages lead to add-to-cart, which campaigns produce sessions that convert, which products correlate with returning customers. It is not the place to grade ad performance against Shopify revenue. Those numbers will never agree, because GA4 sessionizes and Shopify just counts orders. Install it once. At Emma Grace Home, Shopify's Google channel app ran a second GA4 install on the same property, and the purchase event went out as "Purchase" when GA4 ecommerce reads "purchase". Wire GA4 cleanly, then judge ad performance from inside the ad platforms, not from GA4 reports.
- Purchase event de-duplicated between web and server
- Enhanced ecommerce items array passed cleanly
- Custom dimensions for customer type (new vs returning)
- GA4 ↔ Google Ads link, but for audience export only
How far apart the three numbers sit is a question I stopped answering from memory. I measured the gap between the ad platform, the analytics import and the store platform across real ecommerce accounts and published the spread, so you can check your own against it instead of arguing about which dashboard lies.
Read the measured evidence behind this frameworkLayer 5: Google Ads
Clean conversion imports and the right value model.
Google should hear about each sale once, from your server, valued after discounts and shipping, so its bidding chases sales that happened.
Google Ads gets its conversion data from one place: the server-side container, via the conversion API. Not from GA4 imports, which lag and credit sales by GA4’s attribution rules, not Google Ads’. Enhanced conversions on every conversion action. Conversion value set to gross revenue minus discounts and shipping, not order total. One primary purchase conversion, everything else set to secondary.
- Server-side conversion API as primary source
- Enhanced conversions on every action (purchase, lead, etc.)
- Conversion value = gross revenue minus discounts and shipping
- One primary purchase, all others set to secondary
Layer 6: Meta
CAPI and deduplication, so the ROAS number is real.
Meta should get each sale from both the browser and the server with a shared ID, so it counts the sale once instead of twice.
Meta runs on the same server-side spine. Conversions API fires every event. Browser pixel fires the same events with an event_id so Meta can dedupe them. Without dedup, Meta sees double conversions and inflates ROAS. The most common reason Meta reports look great and Shopify revenue does not move. Layer in lift studies for the incrementality read once the dedupe is clean.
- CAPI gateway via server container
- Browser pixel and CAPI share event_id for dedupe
- Server events include hashed email and phone
- Lift study every quarter at scale
Layer 7: Email and SMS
Klaviyo and Postscript. Your cleanest first-party identity graph.
Your email and text lists hold your most reliable customer emails and phone numbers. Sent to the ad platforms, they help match sales to ads and build customer lists for targeting.
Email and SMS platforms are not send engines. They are the cleanest first-party identity graph you have. Hashed email and phone from Klaviyo and Postscript feed back into Meta CAPI, Google enhanced conversions, and customer lists for both. The most underused piece of the stack at most home and furniture brands I audit.
- Klaviyo connected to Shopify, segments synced to Meta and Google
- Customer match lists kept fresh (weekly minimum)
- Hashed identity feeds enhanced conversions and CAPI
Layer 8: Reporting
A weekly written summary that gets read.
A short written note every Monday on what changed and why beats a dashboard nobody opens.
The last layer is not a tool. It is a discipline. A real-time dashboard nobody opens is worse than a written Monday summary that gets read. Pull the numbers that matter (spend, revenue, ROAS, new vs returning, top campaigns), write one paragraph each on what changed and why, and ship it. Looker Studio or a Notion doc, the surface matters less than the rhythm.
- Monday written summary: numbers + interpretation
- Looker Studio (or equivalent) for ad-hoc questions
- Quarterly re-plan against the original ninety-day plan
The STACK Audit is five passes I run, in order, before I touch a single bid.
The architecture above is what the stack should look like. The STACK Audit is how I verify any given account is wired that way. Five letters, five passes, mapped to the eight layers. Each pass takes 20-45 minutes on a typical Shopify account. Each catches one specific class of leak that Smart Bidding will otherwise compound for months.
I don't move a budget dollar until the audit lands clean. The signal cost of bidding against the wrong number for sixty days is larger than the labor cost of running the audit ten times. The audit has a name so I don't skip steps when an account looks fine on the surface.
One check sits in front of all eight layers and isn't among them. An analytics property is scoped to its key rather than to a site, so before auditing what the numbers say, confirm the property is describing the site you think it is. Break it out by hostname and read the list: a foreign hostname puts pages and sessions in your reports that were never on your site.
-
S
Source emission
Storefront emits clean order data before any tag fires. Layer 01.
-
T
Tag triggers
Tags fire once, on server confirmations, gated correctly. Layer 02.
-
A
Attribution spine
Events flow web, server, ad platforms with no double-fire. Layers 03 and 04.
-
C
Conversion values
Right number, right cohort, right primary mapping. Layers 05 and 06.
-
K
Klaviyo identity loop
First-party identity flows weekly back to the ad platforms. Layer 07.
Who this stack is built for.
This is the architecture I run for home and furniture brands on Shopify spending between $25k and $500k a month on paid acquisition. Below $25k, the server-side investment is hard to justify. Above $500k, you start needing pieces I left off this page (warehouse-level customer data platforms, MMM, dedicated incrementality pipelines).
If you're running this stack and it's working, leave it alone. If you're not, this is the order I'd rebuild. Tracking first, ads second, reporting last. Nothing on this page is theoretical. Every component is in production at brands I've worked with this quarter.
The questions each layer raises
- What server-side tracking is, before you pay for it.
- GTM versus GA4, which is the layer people mix up first.
- Setting up the Meta Conversions API, including the de-duplication contract.
- What Consent Mode does to your numbers.
- Which conversion value to send, so the two platforms reconcile.
- What Checkout Extensibility breaks, and the order to fix it in.
- Shopify conversion tracking that reports nothing.
- Why GA4 and Meta will never fully agree.
- Why Google Ads conversions never equal Shopify orders, and the gap band for every pair.
Words used here.
- Tag
- A small piece of code that tells an ad platform or analytics tool that something happened, such as a sale.
- GTM (Google Tag Manager)
- The tool that holds every tag in one place and decides when each one runs. The “web container” runs in the shopper’s browser.
- Server container
- A separate Tag Manager container on a server you control, at your own subdomain. The browser sends events to it and it passes them to Google, Meta and GA4. Ad blockers and browser privacy rules drop less of that data.
- GA4
- Google Analytics 4, Google’s site analytics.
- Data layer
- The place on the page where the store hands order details to Tag Manager.
- Hashed
- Turned into a fixed code with SHA-256, after trimming and lowercasing. The same email always gives the same code, so a platform can match it without the raw address being sent.
- Enhanced conversions
- Google’s add-on that sends the hashed email or phone with each sale, so Google can match it to a signed-in Google user when cookies are missing.
- CAPI (Conversions API)
- Meta’s way of receiving sales straight from your server instead of only from the browser.
- Dedupe (event_id)
- Giving the browser and server copies of one sale the same ID, so the platform counts it once.
- Primary and secondary conversions
- Google Ads settings. Primary conversions are the ones Google’s bidding aims at. Secondary ones show in reports but don’t steer bidding. I set one primary.
- ROAS
- Return on ad spend: the sales value an ad platform credits to its ads, divided by what the ads cost.
- Customer match
- Uploading hashed customer lists so an ad platform can recognize or exclude existing customers.
Same person on the audit as
on the keyboard.
Add me as a read-only user and I'll write the audit myself: a tracking read and where the leak is, 5 to 7 pages, back within 24 hours of access. No call needed. If you'd rather talk first, a call is open too.