Shopify Server-Side Tracking for Google Ads in 2026

For most Shopify merchants running Google Ads in 2026, the question is no longer "should I move to server-side tracking" but "how do I move without breaking the conversion data Smart Bidding has been training on for the last six months?" The platforms changed underneath the merchant community over 2023-2026 — iOS 17 hardened Intelligent Tracking Prevention, Chrome rolled out third-party cookie phaseout in stages, Consent Mode v2 became mandatory for ad personalization in the EU as of March 2024, and Shopify Plus stores were forced onto Checkout Extensibility in August 2024 with the rest of the platform following by March 2025. Each of these changes individually erodes the client-side tracking stack; in combination, they make client-side a strategic dead end.

This guide walks through what specifically broke, how server-side tracking fixes it on Shopify, how to choose between Stape, Elevar, and a self-hosted Cloud Run container, the exact 30-day migration plan, and the pitfalls that quietly inflate or deflate reported conversions if you don't catch them in week 3-4. The audience is Shopify merchants and the developers or agencies working on their accounts who already understand the basics of Google Tag Manager and Google Ads conversions — this is a hands-on technical tutorial, not an introduction.

Why server-side tracking is no longer optional in 2026

Four forces converged between 2023 and 2026 to make client-side Google Ads tracking on Shopify structurally unreliable.

1. iOS 17+ Intelligent Tracking Prevention truncates first-party cookies to 7 days. Safari has steadily tightened ITP since 2017, but iOS 17 (released September 2023) and iOS 17.4 made the behavior more aggressive for third-party scripts, including any pixel loaded from a domain other than your storefront's. For Shopify stores, this means the _ga cookie set by client-side GA4 expires after 7 days of inactivity, breaking attribution windows longer than a week. Server-side tracking, when served from a first-party subdomain (sgtm.yourstore.com), sets cookies that ITP treats as first-party and preserves for the full expected lifetime.

2. Ad blockers now strip 15-25% of Shopify pageview pixels. uBlock Origin, AdGuard, Brave Shields, and Privacy Badger collectively block roughly 15-25% of Google Ads gtag and Meta pixel requests on storefronts, with higher block rates on tech-savvy and EU audiences. The percentage rises every year as default browser configurations get more restrictive. Server-side tracking from your own subdomain is invisible to standard ad blocker lists — the request looks like a normal call to yourstore.com infrastructure, not to googleadservices.com or facebook.net.

3. Consent Mode v2 denies 30-45% of EU events outright. Since March 2024, Google requires Consent Mode v2 signals (ad_user_data, ad_personalization, in addition to the v1 ad_storage and analytics_storage) for personalized advertising and remarketing in the European Economic Area. When a user clicks "Reject all" on your cookie banner, the client-side pixel either doesn't fire at all (basic mode) or fires a cookieless ping (advanced mode). Server-side tracking does not change consent law — denied is still denied — but it makes the modeled conversion path more reliable by ensuring the cookieless pings actually reach Google's API. Our companion guide on Consent Mode v2 for Google Ads covers the legal framing in detail.

4. Shopify Checkout Extensibility removed legacy script injection. Shopify Plus stores lost the ability to add custom scripts to checkout.liquid as of August 13, 2024; all other plans must migrate by August 28, 2025. The replacement is the Web Pixels API — a sandboxed worker environment where third-party tracking code runs in isolation from the checkout DOM. The Web Pixels API does not allow direct DOM access, blocks most modal browser APIs, and gives you only the structured events Shopify chooses to emit. The cleanest way to push those events to Google Ads is via a sGTM container that the Web Pixel sends to — the server container does all the destination-specific work that you used to do in the browser.

The cumulative effect: a Shopify store running client-side Google Ads tracking in 2026 is missing 18-35% of conversions on average, with the loss skewed toward higher-value customers. Server-side tracking does not perfectly recover the signal (consent denials still apply), but in practice it closes 60-80% of the gap.

The four data leaks killing Shopify Google Ads ROAS

Before we cover how to fix the tracking, it's worth being precise about what's leaking and at what magnitude. Different leaks need different fixes, and not every Shopify store has all four problems.

Leak 1: Browser-blocked pixel requests (15-25% loss). The user reaches the thank-you page, but the gtag/js script either fails to load (blocked by uBlock) or loads but fails to send the conversion (blocked by anti-tracking config). Server-side tracking fixes this completely when the sGTM endpoint is on a first-party subdomain — the request looks like a normal API call to your store, not a third-party tracker.

Leak 2: Cookies expired before conversion (5-12% loss). Users who land on your store, browse, leave, and return 8+ days later under iOS 17+ Safari have already lost the _ga and _gcl_au cookies. Their conversion is recorded but with no click ID, so Google Ads can't attribute it to the original ad click. Server-side tracking with first-party cookies on a subdomain extends the cookie lifetime to the full configured duration (typically 730 days for _ga), making attribution windows of 30-90 days reliable again.

Leak 3: Consent denied (15-35% EU loss, lower elsewhere). Users in the EU who reject the cookie banner generate cookieless pings in Consent Mode v2 advanced mode, but those pings are modeled estimates — Google uses machine learning to infer the actual conversion rate from the denied cohort based on the granted cohort. Server-side tracking does not bypass consent (legally cannot), but it does make the cookieless ping mechanism more reliable, and it positions you for the modeled data path that Smart Bidding uses for non-personalized signals.

Leak 4: Late or missed events on browser close (3-8% loss). Some users close the tab before the thank-you page fully loads — the purchase completed server-side at Shopify, but the browser-side pixel never fired. Server-side tracking via Shopify webhooks (orders/create or orders/paid) catches these conversions because the event is sent server-to-server from Shopify to your sGTM container, independent of whether the browser stays open.

Adding these up: a typical Shopify store with 30% EU traffic and 70% global traffic loses roughly 20-30% of total conversions to leaks 1-4 combined, with another 5-10% measurement quality loss (later events, missing click IDs) that degrades Smart Bidding even on the conversions that do reach Google. Server-side tracking won't recover all 30%, but it consistently recovers the 15-25% caused by blockers and ITP, which is the most impactful chunk for Smart Bidding's learning loop.

Architecture: what server-side tracking actually does

The architecture is simpler than the marketing material makes it sound. Three layers, one new piece of infrastructure.

Layer 1: Event source. On Shopify in 2026 there are two reliable sources for purchase events. The Web Pixels API runs inside Shopify's sandboxed worker and emits standard events (page_viewed, product_viewed, checkout_started, checkout_completed) with structured payloads. Shopify webhooks (configured at Settings > Notifications > Webhooks) fire server-to-server when an order is created, paid, fulfilled, refunded, or cancelled. A robust setup uses both: the Web Pixel for client-side context (referrer, click IDs, session info) and the webhook for the authoritative server-side fire on orders/paid.

Layer 2: sGTM container. The server-side Google Tag Manager container is a separate Node.js application that you host yourself (Cloud Run, Stape, Elevar, or any other compatible runtime). It exposes an HTTPS endpoint on your first-party subdomain (sgtm.yourstore.com) and receives events in the format the GTM client expects. Inside the container, you configure clients (GA4, Google Ads, custom) and tags (Google Ads Conversion, Meta CAPI, TikTok Events API, custom destinations). The container does the destination-specific work — hashing PII, normalizing payload formats, enforcing consent gating, deduplicating events — before sending to each destination's API.

Layer 3: Destination. Google Ads receives the conversion via the gtag transport (or directly via the Conversions API in advanced setups). The conversion is associated with the Google Click ID (gclid cookie), which the sGTM container forwards from the Web Pixel. Enhanced Conversions adds hashed first-party identifiers (email, phone, address) to the same conversion event, which Google uses to match conversions to logged-in user accounts at Google's side, recovering attribution that client-side cookies missed.

A typical event lifecycle for a Shopify purchase:

1. Customer reaches Shopify thank-you page. The Web Pixel fires checkout_completed.
2. Web Pixel sends the event to sgtm.yourstore.com with parameters: transaction_id, value, currency, items array (item_id, item_name, price, quantity), gclid, hashed email/phone/address.
3. The sGTM container receives the event, validates consent signals from the CMP, and routes it to the Google Ads conversion tag.
4. The Google Ads tag in sGTM formats the payload for the Conversions API and POSTs to Google's endpoint with the conversion ID, conversion label, and user_data block.
5. In parallel, Shopify's orders/paid webhook also POSTs to sGTM with the order data, providing a server-to-server backup in case the Web Pixel missed the event.
6. sGTM deduplicates based on transaction_id — if it sees the same ID from both the Web Pixel and the webhook within 24 hours, only one conversion is sent to Google Ads.

This architecture solves the four leaks above and gives you a single point of control for all destinations — when you want to add Meta CAPI, Pinterest API, or TikTok Events API later, you reuse the same event source and add a destination tag to the sGTM container. For deeper background on the client-vs-server tradeoff, our server-side GTM vs client-side guide covers when each makes sense beyond Shopify.

Stape vs Elevar vs custom Cloud Run — choosing your sGTM host

The three credible hosting options for sGTM on Shopify in 2026 each target a different merchant profile.

Stape.io is the dominant managed sGTM host with roughly 30,000 active containers across e-commerce. Pricing starts at $20/month for the "Cloud" plan (10M requests/month, custom domain, basic monitoring) and scales to $200+/month for high-volume plans with priority support and EU data residency. Stape's value is operational simplicity: you provision a container in their UI, point your CNAME, and you have a working sGTM endpoint in under an hour. Their Shopify-specific assets — a pre-built Web Pixel template, webhook integration, recipe library for common tags — eliminate most of the implementation work. Best for: 80% of Shopify merchants doing €10k-500k/month in Google Ads spend who want time-to-value over per-event cost.

Elevar is more opinionated and Shopify-specific. Pricing starts around $150/month (Pro plan) and goes up significantly for higher-volume stores. Elevar owns the entire pipeline: their app installs on Shopify and replaces your data layer with their unified event schema; their consent banner integrates with the data layer natively; their destinations include not just Google Ads and GA4 but Meta CAPI, Klaviyo, TikTok Events, Pinterest API, all pre-configured. The tradeoff is vendor lock-in — you're using Elevar's data layer, not native GTM, so if you ever leave you rebuild from scratch. Best for: stores that want one vendor responsible for the entire tracking stack, willing to pay a premium for whitewashed operational complexity, typically €50k+/month in ad spend.

Self-hosted Cloud Run is the cheapest at scale and the most flexible. The infrastructure cost for sub-1M events/month is typically $20-30/month on Google Cloud (Cloud Run + load balancer + minimum container instance). You deploy the official sGTM image (gcr.io/cloud-tagging-10302018/gtm-cloud-image), map it to your custom domain via Cloud Run Domain Mappings, and you have a working endpoint. The container code is the same as what Stape and Elevar run — you just operate it yourself. The cost is engineering ownership: someone on your team needs to know GCP, monitor uptime, handle the occasional container upgrade, and debug when something breaks. Best for: stores with in-house engineering, very high event volume (>5M/month) where per-event hosting costs matter, or specific compliance requirements that mandate self-hosting.

The decision rule we apply on most audits: if you do not have a developer who has used Google Cloud before, pick Stape. If you do have one but they are busy on product work, pick Stape. If you want a vendor to manage the whole tracking stack and write the strategy, pick Elevar. Only pick Cloud Run if you have engineering bandwidth and either a cost-driven case (very high event volume) or a compliance-driven case (data residency requirements your other options can't meet).

Step-by-step sGTM setup on Shopify

The implementation walkthrough below assumes Stape as the host since it's the most common starting point; the steps are nearly identical for Elevar (their onboarding handles most of this) and Cloud Run (DNS and container deployment differ slightly). If you're using a different host, substitute their equivalent UI steps.

Step 1: Create the sGTM container in Google Tag Manager. Go to tagmanager.google.com, click "Create Account" or use an existing account, then create a new container with the type "Server." Copy the container configuration string (a long base64 blob) — you'll need it for Stape. Inside the new server container, navigate to Clients and confirm there is a default "Google Analytics: GA4" client. We'll add the Google Ads conversion tag later.

Step 2: Provision Stape and point DNS. Sign up at stape.io, create a new container, paste the configuration string from GTM. Stape will provision your container and give you a CNAME target (e.g. lb.stape.io). In your DNS provider (Cloudflare, Namecheap, GoDaddy), add a CNAME record: sgtm.yourstore.com → lb.stape.io. Wait 5-30 minutes for DNS propagation. Confirm in Stape's UI that the domain is "verified" and SSL is provisioned.

Step 3: Configure the Shopify Web Pixel. In Shopify Admin > Settings > Customer events > Add custom pixel. Name it "sGTM" or similar. Paste the Web Pixel code that Stape provides — it's a JavaScript snippet that subscribes to checkout_completed, product_viewed, and other standard events, then sends them to your sGTM endpoint. Set the permission level to "Customer privacy: Marketing" so the pixel only fires when the user has consented to marketing cookies (this is critical for Consent Mode v2 compliance). Save and connect.

Step 4: Add the Google Ads conversion tag in sGTM. Back in the server container at tagmanager.google.com, create a new tag of type "Google Ads Conversion Tracking." Enter your Conversion ID (from Google Ads > Tools > Conversions > your conversion action > Tag setup; format AW-1234567890) and Conversion Label (format abcDEF-123_456). Set the trigger to fire on the "purchase" event coming from the GA4 client. For the value and currency, map to event parameters value and currency. For Enhanced Conversions, expand the "User-provided data" section and enable it — we'll configure the field mapping in Step 6.

Step 5: Configure Shopify webhook backup. In Shopify Admin > Settings > Notifications > Webhooks, create a webhook for Order paid (event) with format JSON and URL https://sgtm.yourstore.com/data?event=purchase (or whatever endpoint Stape exposes for direct webhook ingestion). This webhook fires server-to-server when an order completes payment, ensuring you capture conversions even when the browser closes before the thank-you page loads. The sGTM container deduplicates between the Web Pixel event and the webhook event using transaction_id.

Step 6: Wire Enhanced Conversions data. In the Google Ads conversion tag's User-provided data section, map the fields: email_address to {{event.user_data.email}}, phone_number to {{event.user_data.phone}}, address.first_name to {{event.user_data.first_name}}, and so on for last_name, street, city, region, postal_code, country. The Web Pixel and webhook both send these fields from Shopify's customer object — make sure your CMP consent flow includes "Allow sharing of personal data for ad personalization" so this fires legally. Hashing is handled automatically by the sGTM tag template — do not hash manually on the source side.

Step 7: Set up the Consent Mode v2 client. In the sGTM server container, add a new client of type "Consent Mode v2" if not already present (most templates include it by default). In your storefront's CMP (Cookiebot, OneTrust, Iubenda, Klaro), configure the consent script to set the four consent signals: ad_storage, analytics_storage, ad_user_data, ad_personalization. The Web Pixel should forward these signals with every event so sGTM knows whether to send personalized or modeled data to Google.

Step 8: Publish containers and run smoke tests. Publish both the web GTM container (if you have one for client-side dual-tracking) and the sGTM server container. In the server container, click "Preview" to enter debug mode. Place a test purchase on your live or staging store. The sGTM preview should show the checkout_completed event arriving, the Google Ads conversion tag firing, and the response status from Google's API. If anything fails here, fix it before moving to the next phase — bad data flowing in week 1 is much harder to debug in week 4.

Enhanced Conversions and Consent Mode v2 wiring

Enhanced Conversions and Consent Mode v2 are the two features that make server-side tracking worth the trouble. Each addresses a different part of the signal-recovery problem, and both need to be configured correctly for the migration to deliver its expected ROAS lift.

Enhanced Conversions for Web sends hashed first-party identifiers — email, phone, name, address — alongside each conversion event. Google uses these identifiers to match the conversion to a logged-in Google user account on Google's side, which recovers attribution for users whose gclid cookie was lost (ITP expiration, cleared cookies, cross-device journeys). Match rates of 60-80% are typical for Shopify stores once configured correctly, and each percentage point of match rate translates roughly to 0.3-0.5% of additional conversions visible to Smart Bidding.

The Shopify advantage here: every Shopify order has structured customer data — email is always present, phone is usually present, billing address is always present. You don't have to chase down identifiers from a custom checkout flow. The Web Pixel's checkout_completed event includes the full customer object, so mapping the Enhanced Conversions fields is straightforward.

The pitfalls to avoid:

• Do not hash on the source side. The Google Ads tag template in sGTM hashes automatically using SHA-256 with the canonical normalization (lowercase, trimmed, phone in E.164). If you hash manually before sending, your hashes won't match Google's expected format and match rates will collapse to near zero.
• Do normalize phone to E.164 before sending. Shopify often stores phone as user-entered ("(415) 555-1234" or "+1 415 555 1234"). Convert to "+14155551234" in the Web Pixel or in the sGTM transformation tag before the Enhanced Conversions mapping picks it up.
• Do not send Enhanced Conversions data when consent is denied. Wire the consent signals so the Enhanced Conversions block is omitted on events where ad_user_data is denied. The tag template handles this automatically when consent signals are passed correctly.

For full Enhanced Conversions setup including diagnostic checking, see our companion Enhanced Conversions for Google Ads setup guide.

Consent Mode v2 is mandatory in the EEA for any advertiser using personalized advertising features (most Smart Bidding strategies, remarketing, similar audiences). The four signals — ad_storage, analytics_storage, ad_user_data, ad_personalization — must each be set to granted or denied before any Google tag fires.

On Shopify, the canonical implementation is:

1. Install a Google-certified CMP from the partner list (Cookiebot, OneTrust, Iubenda, Klaro, Usercentrics, Didomi).
2. Configure the CMP banner to set the four consent signals via gtag('consent', 'update', {...}) when the user grants or denies.
3. Make sure the Web Pixel reads the current consent state and forwards it to sGTM with every event, in the event parameters.
4. In the sGTM Google Ads tag, set consent requirements: ad_storage and ad_user_data required for personalized conversions, analytics_storage required for GA4.
5. Test both consent paths (granted and denied) and verify in the sGTM preview that the tag fires modeled data when denied and personalized data when granted.

The modeling math is opaque but real: Google's machine learning estimates the conversion rate of the denied cohort based on the granted cohort, and feeds modeled conversions to Smart Bidding. The modeling is only as good as the consent rate — if your banner has an 80% acceptance rate, the modeled portion is small and accurate; if it has a 20% acceptance rate, the modeling carries most of the volume and is noisier.

A common Shopify-specific gotcha: the Shopify storefront and the Shopify checkout are technically different domains/contexts (especially with Checkout Extensibility). Your CMP must handle consent on both — not just on the storefront. Most certified CMPs have a Shopify-specific integration that takes care of this; if you're rolling a custom CMP, you'll need to wire the consent state across the storefront → checkout transition manually.

Verification with Tag Assistant and the Network tab

The most common reason server-side tracking goes wrong on Shopify is that it appears to work — events flow into GA4, the merchant celebrates, the migration is declared done — but the Google Ads side is silently broken. The fix is rigorous verification across three independent layers before trusting the implementation.

Layer 1: Tag Assistant Companion + sGTM Preview Mode. Install the Tag Assistant Companion Chrome extension. In your sGTM server container, click "Preview" to start a debug session. Open your storefront with the preview link Tag Assistant gives you. Place a test purchase. In the sGTM preview pane, verify:

• The page_view event arrives on the homepage with correct parameters.
• The view_item event arrives on the product detail page with items array.
• The begin_checkout event arrives at checkout start.
• The purchase event arrives at checkout completion with transaction_id, value, currency, items, and user_data populated.
• The Google Ads conversion tag fires on the purchase event and the response status is 200/204.

Layer 2: Browser DevTools Network tab. In a regular browser tab (not Tag Assistant preview), open DevTools, filter Network by your sGTM custom domain (e.g. sgtm.yourstore.com). Place another test purchase. Verify:

• Multiple requests fire to sgtm.yourstore.com/g/collect (or similar endpoint) across the journey.
• The purchase request has the correct payload — inspect the Request Payload tab to see en=purchase, ep.transaction_id=..., epn.value=..., pr1=... (product 1 details).
• The response is 204 No Content (this is normal and means success).
• A request fires to googleads.g.doubleclick.net or www.googleadservices.com as the destination delivery — confirming the conversion reached Google's edge.

Layer 3: Google Ads diagnostics. In Google Ads, go to Tools > Conversions > [your conversion action]. Within 3-6 hours of the test conversion, the diagnostic panel should update:

• "Recording conversions" should show a green checkmark with the test conversion counted.
• The Enhanced Conversions section should show match rate data starting to accumulate (full match rate stabilizes over 7 days).
• There should be no "Critical issues" or "Recommended fixes" warnings related to the conversion source.

If all three layers pass, the implementation is correctly wired. If any layer fails:

• Tag Assistant fails: container/tag configuration issue. Check trigger conditions and parameter mapping.
• Network tab fails: DNS/SSL issue or Web Pixel issue. Check that sgtm.yourstore.com resolves and serves a valid cert.
• Google Ads diagnostic fails despite the first two passing: usually a Conversion ID or Conversion Label mismatch — re-check those values match exactly what's in Google Ads.

Run all three layers on at least 5 distinct test purchases covering: standard purchase, multi-item, discount applied, EU customer with consent granted, EU customer with consent denied. Edge cases break tracking more often than standard cases.

For the broader server-side GTM verification playbook beyond Shopify, see server-side GTM 2026.

Common pitfalls: deduplication, item_id mismatch, refunds

The technical setup is mostly mechanical once you've done it once. The pitfalls live in the details — the issues that don't surface until weeks 3-4 when you're comparing reported Google Ads conversions to Shopify orders and the numbers are off by 20%.

Pitfall 1: transaction_id format mismatch causing double counting. Shopify exposes order IDs in two formats: the global ID (gid://shopify/Order/5234567) and the legacy numeric ID (5234567). Different tools, Web Pixel versions, and webhook payloads may send different formats. If your client-side dual-tracking sends one format and your sGTM sends the other, Google Ads cannot deduplicate and counts both — inflating your reported conversions by potentially 100%. The fix: in the sGTM container, add a transformation that strips the GID prefix from any incoming transaction_id and forwards only the numeric portion. Apply the same normalization on the client-side tag if you're running both during the parallel-run period.

Pitfall 2: item_id mismatch with Merchant Center. Google Ads Performance Max and Shopping campaigns match purchase events to your Merchant Center feed by item_id (the product ID in the conversion event must match the product ID in the feed). Shopify exposes product IDs and variant IDs separately — and Merchant Center feeds usually use the variant ID (shopify_AU_123456_789 format) while the Web Pixel may send the bare product ID (123456). The mismatch breaks attribution to specific products, which silently degrades PMax bidding. The fix: in the sGTM transformation, construct the item*id in the exact same format as your Merchant Center feed — typically shopify*[country]_[product_id]_[variant_id]. Check the Merchant Center > Products > Diagnostics for "Conversions matched" stats to verify match rate stays above 90%.

Pitfall 3: Refunds not propagated. When a customer refunds an order, Shopify fires a refunds/create webhook. Most merchants set up the purchase tracking and forget refunds, which means Google Ads keeps the conversion counted even after a full refund — inflating reported revenue and degrading Smart Bidding accuracy. The fix: configure a Shopify webhook on refunds/create to POST to your sGTM container, which fires a Google Ads "refund" conversion event (a negative-value adjustment) using the upload conversions API. Stape and Elevar both have pre-built templates for this; on Cloud Run you'll need to write the tag manually. Refund tracking matters especially for stores with refund rates above 5%.

Pitfall 4: Test orders polluting production data. Shopify's test gateway and Bogus Gateway orders look like real orders to webhooks and Web Pixels — and they fire conversion events to Google Ads. If you test 50 purchases during the rollout, you'll inflate Google Ads conversions by 50 fake events. The fix: in the sGTM container, add a transformation that checks the payment_gateway_names field on the order and discards the event if it includes "bogus" or "manual." Document the test order convention for the team so you don't have to clean up bad data later.

Pitfall 5: Click ID lost between subdomain transitions. If your storefront is yourstore.com and your checkout is checkout.yourstore.com (some Shopify Plus setups), the gclid cookie may not carry across the transition without explicit cookie domain configuration. The result: purchases on the checkout subdomain have no click ID, so Google Ads can't attribute them. The fix: in the Web Pixel, read the gclid from the entry-point page and pass it explicitly in every event payload, rather than relying on cookies to be present. The sGTM container then forwards the gclid as part of the conversion event.

Pitfall 6: Currency formatting errors. Shopify exposes monetary values as strings or floats depending on the API path. The Google Ads conversion tag expects a number. If a string slips through ("39.99" instead of 39.99), the conversion either fails or counts as zero value — silently breaking Target ROAS bidding. The fix: explicitly cast value to number in the sGTM transformation, and add a guard that fails the tag with a clear error if value is not numeric and positive.

Pitfall 7: Consent state cached from previous session. Some CMPs cache consent state in localStorage and reuse it across sessions, including for users who deleted cookies. The result: a user who deleted all cookies still gets a "granted" consent applied to their new session, leading to events firing in a state that may not match the user's actual current preference. The fix: configure the CMP to re-prompt for consent if the consent token is older than 12 months or if localStorage was cleared. Document the CMP consent-refresh policy in your runbook.

Most of these pitfalls don't show up in Tag Assistant testing — they only surface when you reconcile a full month of Shopify orders against Google Ads conversions and find the totals don't match. Schedule the reconciliation at days 30, 60, and 90 post-migration as a recurring check.

If you want a second pair of eyes on your Shopify + Google Ads tracking setup before or after migration, SteerAds runs a free 14-day audit that includes a server-side tracking review and Smart Bidding signal-quality check.

For related Shopify-specific Google Ads context, see Shopify vs Prestashop Google Ads setup and GA4 setup with Google Ads conversion import.

Sources

Official and third-party sources consulted for this guide:

• developers.google.com/tag-platform

  — Google Tag Platform server-side documentation, Consent Mode v2 spec, sGTM container deployment

• shopify.dev/docs/api/web-pixels-api

  — Shopify Web Pixels API reference, Customer Events catalog, Checkout Extensibility migration guide

• stape.io/blog

  — Stape's Shopify sGTM implementation guides, Web Pixel templates, deduplication recipes

• simoahava.com

  — Simo Ahava's GTM and server-side tracking deep-dives, consent mode debugging, item_id mapping patterns

• support.google.com — Enhanced Conversions for Web

  — official Google Ads documentation on Enhanced Conversions setup, match rate diagnostics, hashing requirements

Related reading: GA4 + Google Ads conversion import setup 2026: complete 30-day implementation guide · AI image generation for Google Ads 2026: Midjourney, DALL-E, and ad creative · BigQuery + Google Ads data pipeline 2026: build your reporting warehouse · Claude Skills for PPC Managers: 12 Real Workflows 2026 · Consent Mode v2: Conversion Modeling & Loss Recovery 2026 · Consent Mode v2 implementation 2026: mandatory EEA setup for Google Ads + GA4

FAQ