00 The Tracking Stack

How a Shopify brand should be wired, in eight layers.

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. 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 is leaking.

Running a service business or lead-gen account? Read the Lead Quality Stack instead

A number that will not reconcile? Diagnose it in the Conversion Tracking library

Download the 25-page PDF Free · No email

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
~15% Conversions lost without server-side
30-50% Meta ROAS inflation without dedupe
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

Eight layers. One direction of data flow (downward), one exception (Email + SMS feeds identity back upstream into the server-side container). The oxblood bracket marks the dedup contract: Google Ads and Meta both receive the same event_id from the server container so neither double-counts the purchase. Click any layer to jump to its breakdown.

01 The store

Shopify, or whatever runs the transaction. It is the source of truth.

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.

Components

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

02 The container

The GTM web container. It is the traffic cop, not the storefront.

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.

Components

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

Field note

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 container

03 Server-side

A GTM server container. It earns its keep where client-side tracking breaks.

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 for leads) 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.

Components

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

04 GA4

GA4 is for analytics, not attribution.

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. Wire GA4 cleanly, then judge ad performance from inside the ad platforms, not from GA4 reports.

Components

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

05 Google Ads

Clean conversion imports and the right value model.

Google Ads gets its conversion data from one place: the server-side container, via the conversion API. Not from GA4 imports, which lag and lose ~15 percent of conversions to attribution model differences. 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.

Components

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

06 Meta

CAPI and deduplication, so the ROAS number is real.

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 by 30 to 50 percent. 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.

Components

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

07 Email and SMS

Klaviyo and Postscript. Your cleanest first-party identity graph.

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 for leads, and customer lists for both. The most underused piece of the stack at most home and furniture brands I audit.

Components

Klaviyo connected to Shopify, segments synced to Meta and Google
Customer match lists kept fresh (weekly minimum)
Hashed identity feeds enhanced conversions and CAPI

08 Reporting

A weekly written summary that gets read.

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.

Components

Monday written summary: numbers + interpretation
Looker Studio (or equivalent) for ad-hoc questions
Quarterly re-plan against the original ninety-day plan

09 The STACK Audit

Five passes, in order. The pass I run 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 actually 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 do not 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 do not skip steps when an account looks fine on the surface.

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.

Read the full STACK Audit walkthrough (last quarter's $40K/mo account, 7 findings)

10 A note on what this is

Opinionated, not universal.

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 are running this stack and it is working: leave it alone. If you are not, this is the order I would rebuild. Tracking first, ads second, reporting last. Nothing on this page is theoretical. Every component is in production at brands I have worked with this quarter.

11 Want this rebuilt for your account?