The GA4 & GTM Audit That Found a Shopify Store's Google Ads Data Was 2x Inflated

A UK Shopify jewellery brand spending £18,000+ a month on Google Ads asked for a routine GA4 and GTM audit ahead of a Shopify deprecation deadline. The audit found two active problems that had been quietly corrupting campaign performance the entire time: conversions counted twice, and a chunk of purchases with no ad click attached to them at all.

The Audit: What Was Actually Wrong

Duplicate conversion tags, 2x inflation

Two GTM tags were firing to the same Primary Google Ads conversion action on every purchase. The legacy tag sent no order ID, so Google couldn't deduplicate it against the current one. Over a 28-day window, the account reported 625+ conversions worth £66,000+. The real number, once the duplication was accounted for, was approximately 300 to 310 purchases. Every Performance Max campaign and the brand Shopping campaign were running Target ROAS bidding on that inflated data, meaning Smart Bidding had been optimizing toward a conversion volume that didn't exist.

GCLID dropped at checkout

The Conversion Linker tag's domain list covered the storefront domain but not checkout.shopify.com. A GCLID cookie set when someone clicked a Google ad and landed on the storefront couldn't be read once the browser moved to the separate checkout domain, and there were no tracking templates configured anywhere in the account as a UTM fallback. The purchase conversion still fired, but with no GCLID attached, so Google Ads had no way to connect it back to the ad click that earned it. Google's own Tag Diagnostics flagged this directly, it had been sitting there unaddressed.

A separate GA4 referral misattribution

A related but distinct problem: shopify.com wasn't on the GA4 referral exclusion list, so when checkout sessions redirected back to the store, GA4 attributed the purchase to shopify.com as a referral instead of the original marketing channel. Over 90 days this misattributed 1,015 sessions, 48 purchases, and £5,856 in revenue away from the channels that actually earned it. This is a separate setting from cross-domain tracking, both need configuring independently, and only one had been done.

Two silent variable bugs

A GTM variable feeding Enhanced Conversions was reading the wrong dataLayer field, sending a two-letter region code ("ENG", "SCT") as the postal code on every hit instead of an actual postcode, degrading Meta and Google's ability to match the hashed customer data. Separately, a currency variable's fallback default was set to EUR on a store that transacts entirely in GBP, a silent bug that would only surface if the real currency value was ever missing from the dataLayer. Neither had thrown an error. Both had been quietly shipping bad data.

The forcing function: a Shopify deprecation deadline

Shopify was removing the legacy "Order status page additional scripts" mechanism for non-Plus merchants on a fixed date. The store's entire GTM setup depended on that mechanism plus a custom pixel using a postMessage bridge to talk to a GTM container loaded via theme.liquid. Once Shopify's change landed, both pieces would stop working together. Google's own documentation is explicit that running Google tags inside a Shopify custom pixel isn't a supported implementation in the first place, an unrelated finding that made the deadline more of a forcing function than a surprise.

The Fix, in Two Phases

Phase 1 fixed what was actively broken, before touching the migration:

• ▸Removed the legacy duplicate purchase tag from GTM
• ▸Added the checkout domain to the Conversion Linker's domain list
• ▸Corrected the postal code variable to read the right dataLayer field
• ▸Corrected the currency variable's fallback to GBP
• ▸Added shopify.com and shop.app to the GA4 referral exclusion list
• ▸Fixed a begin_checkout tag set to fire unlimited times per session instead of once, which had been inflating the GA4 checkout funnel

Phase 2 migrated the store off GTM entirely, onto Shopify's native Google & Youtube App, which fires directly from Shopify's Customer Events system with no dependency on theme.liquid:

• ▸Removed the GTM snippet from theme.liquid and disconnected the GTM custom pixel from Customer Events
• ▸Connected GA4 and ran Shopify's tag migration wizard to carry over the existing Google Ads purchase conversion
• ▸Removed a duplicate conversion destination that had been configured inside the app itself
• ▸Kept the original GTM container intact and untouched in Google Tag Manager, purely disconnected from the store, as a full rollback path

Verifying It Actually Worked

A real test purchase was run through the new setup and checked via Tag Assistant and the GA4 debugger:

• ▸Google Ads conversion fired once, transaction ID matched, deduplication confirmed (the tag technically fires twice on the thank-you page due to a Shopify post-purchase survey re-render, but Google deduplicates by transaction ID so only one conversion counts, worth knowing so it doesn't look like a regression)
• ▸Currency correctly reported as GBP
• ▸Enhanced Conversions confirmed sending hashed customer data
• ▸GA4 purchase event fired with the correct transaction ID and both ad_storage and analytics_storage consent granted

The old Google Ads conversion action was kept active as a Secondary, reporting-only action through a 10 to 14 day monitoring window, so Smart Bidding had stable data to recalibrate against and there was a clean before/after comparison. It was removed once the monitoring period confirmed zero conversions were still routing through the old path.

Key Takeaways

• ▸A conversion count that looks plausible can still be roughly double the real number, the only way to know is checking for duplicate tags firing to the same conversion action without order ID deduplication
• ▸Cross-domain GCLID loss at checkout is a Google Ads attribution problem, and referral misattribution in GA4 is a separate reporting problem, they look similar but need two different fixes
• ▸Variable bugs that silently send wrong-but-valid-looking data (a region code instead of a postcode, a fallback currency that's never supposed to trigger) are the hardest class of tracking bug to catch, because nothing errors, the data just quietly degrades match quality
• ▸When a platform deprecation forces a migration anyway, it's worth a full audit first, a clean migration onto broken assumptions just carries the same bugs onto the new platform
• ▸Keeping the old setup as an intact rollback path and running a monitoring period before fully decommissioning it turns a migration from a leap of faith into something reversible

Frequently Asked Questions

How do you actually confirm conversions are being double-counted, versus just high-performing?

Check whether more than one tag fires to the same conversion action on the same trigger, and whether each one includes an order ID or transaction ID for deduplication. If a legacy tag lacks that field, every hit it sends counts as a brand new conversion no matter how many times the same order already fired elsewhere. Cross-referencing the platform's reported conversion count against actual order volume in the backend is the fastest sanity check.

Why keep the old conversion action running instead of switching over immediately?

Smart Bidding algorithms need a stable run of consistent data to recalibrate after any tracking change. Running the new setup as Secondary and the old one as Primary (or vice versa, whichever was live longer) for a monitoring window means there's a real before/after comparison and a safe rollback if the new setup has an issue, instead of finding out two weeks later with no baseline to compare against.

Does moving off GTM to a platform's native app mean giving up flexibility?

For standard ecommerce events, no, native apps like Shopify's Google & YouTube App cover the core conversion events out of the box. The tradeoff shows up with custom event structures or sending data to multiple third-party platforms simultaneously (Meta, TikTok, Pinterest, etc.), which is where a server-side GTM setup becomes the stronger long-term option since it can fan one clean data source out to every platform at once.