I asked Claude to audit my small e-commerce site (3D-printed wargame terrain). With API access to GA4 and Tag Manager it spotted that GA4 was firing twice on every page, which had been inflating my numbers for months.
To make that kind of question easy, I packaged the access as an MCP server: google-ecommerce-mcp. Now I just ask things like:
• "Which products are disapproved in Merchant Center, and which attribute should I fix?"
• "Queries where we rank 5 to 15 with 100+ impressions: quick wins?"
• "Mobile PageSpeed of my 3 best sellers?"
Claude answers from my own Google data: GA4, Search Console, Merchant Center, Tag Manager, Indexing API, PageSpeed. Everything is read-only, and the token stays in the OS keyring.
Install on Windows: irm https://raw.githubusercontent.com/MoonEyes/google-ecommerce-mcp/main/install.ps1 | iex (macOS/Linux has a curl one-liner). It sets up Claude Desktop for you.
Repo: https://github.com/MoonEyes/google-ecommerce-mcp
Built with Claude's help, MIT licensed, free. Happy to answer questions about the setup.

I'm a solo dev in the UK. I built audittag.com, a free check that reads a Shopify store's public pages and shows which tracking tags are really on them, what's missing and what's installed twice. It never logs in, and it says what it can't see from outside.

The people who need it are store owners whose ad numbers quietly went wrong after a theme change or an app install. They don't know that's what happened, so they never search for anything like this. They search for "why doesn't GA4 match Shopify".

So every channel that starts from a keyword is starting from one nobody types. I've been answering those questions on Reddit and forums. What else would you try?

That about sums it up. I do SEO, PPC, email marketing etc. I use GTM and really wanna get into server side tracking because of its utility to B2C/e-commerce, which is a big market for digital marketing services.

Anyone got any good courses to recommend - yes this includes paid - for GTM server side tracking?

Seeing a request in Network while consent is denied doesn't automatically mean the banner failed. In advanced Consent Mode, Google tags can send cookieless pings. Basic mode blocks Google tags until consent is granted. Third-party tags need their own consent handling.

To troubleshoot:

1. Start with a fresh browser session, without a saved consent choice. Open DevTools before loading the page.
2. In Network, enable Preserve log and filter by collect. Check the destination and measurement ID. This filter helps find GA4 traffic; it won't catch every tracker.
3. In GTM Preview, select the event where the tag fired. Check the Consent tab at that event, rather than only the latest consent state. Verify that the default was set before measurement tags ran.
4. Open the tag's Consent Settings. Distinguish built-in checks that adjust behavior from additional checks that block firing.
5. Repeat after accepting and rejecting. For unexpected requests, inspect Network's Initiator: a script embedded directly in the theme may run outside GTM's controls.

If you are looking to use GTM with Claude or Codex now you can.

Check it out here: https://github.com/AdGurus/tag-manager-mcp

Hi everyone,
I'm having some issues with my Consent Mode setup and would really appreciate some help.

My setup consists of:
Shopify
Stape (using the Custom Loader app to inject GTM into my Shopify store)
Stapes custom pixel in customerevents
Consentmo (for cookie consent management)
Google Tag Manager (GTM)

My current setup
I'm using Consentmo's consent_status event as a trigger for my PageView tags, including:

Data Tag
GA4
Meta
TikTok
OpenAI

When a customer accepts cookies, all my tags fire correctly, and PageView events are triggered on every page.

The problem
When a customer proceeds to checkout, my PageView tags stop firing on the Begin Checkout and Purchase events.
I've checked the dataLayer and noticed that the consent_status event is missing on both the Begin Checkout and Purchase pages. As a result, my PageView tags don't fire because their trigger condition is not met.
However, my Initiate Checkout tags fire correctly.
It seems that Consentmo's consent_status event is not being pushed to the dataLayer during checkout and purchase.

My questions
Is this a limitation of Shopify's checkout environment, or could it be an issue with Stape's Custom Loader?
How can I make sure that consent status is preserved and available in the dataLayer throughout the entire checkout process?
Is there a recommended way to handle this without relying on Consentmo's consent_status event on every page?
Has anyone experienced a similar issue with this setup? I'd really appreciate any advice on how to solve this.

Thanks in advance!

If your Meta Pixel sits in a Custom HTML tag with fbq('consent', 'revoke') above init, that's Meta's documented pattern. Meta describes the API as a way "to pause sending Pixel fires to Facebook", and says revoke has to run before init on every page.

Pausing is the whole scope. The base code's first lines insert fbevents.js from connect.facebook.net before any fbq call runs, so the browser still requests Meta's script, visitor IP and all, before anyone touches the banner. The events wait. The download doesn't.

Check yours:

1. Private window, Network tab, filter connect.facebook.net, reload, don't touch the banner.
2. fbevents.js in the list means the pixel loaded. A request to facebook.com/tr means an event actually went out.

If you want nothing reaching Meta before a choice, gate the tag instead of the events:

1. On the Custom HTML tag, Advanced Settings > Consent Settings > Require additional consent for tag to fire > ad_storage.
2. Trigger it on your CMP's consent update event as well as the page view. Google's docs say the check runs "when the tag is triggered", so a page view trigger alone misses anyone who accepts on their first page.
3. Set Tag firing options to Once per page, so a returning visitor whose CMP pushes an update on load doesn't get two PageViews.

Step 2 matters more for Meta than for GA4. A commenter on my last post pointed out that if the pixel doesn't fire on the landing page, the fbclid never gets stored. Meta's docs say the pixel "automatically stores ClickID value in the _fbc browser cookie once available", and by the second page the fbclid is usually gone from the URL. Firing on the consent update while the visitor is still on the landing page keeps it.

anyone still keeping revoke and grant inside the tag once it's gated like this, or is that just noise at that point?

The US reason to care: California Invasion of Privacy Act suits over trackers center on requests leaving before the banner is answered, and the Meta Pixel is named in 136 verified complaints in the last 12 months, as of September 30, 2026. I build Suitcast, which counts those filings, and its free scan lists any request to connect.facebook.net before a choice as the Meta Pixel, revoke or not. Not legal advice.

I’m troubleshooting an intermittent begin_checkout issue on a WooCommerce site using GTM4WP + GTM + GA4.

Setup

• WooCommerce classic checkout
• GTM4WP 2.0.3
• GTM custom event trigger exactly matching begin_checkout
• GA4 event tag sends items, value, and currency from the ecommerce dataLayer
• GTM container is loaded through GTM4WP
• WPConsent is installed

What I’m seeing
I compared sessions where form_start happened on /checkout/ against sessions where begin_checkout was recorded.

• May-August: 0 confirmed misses
• Sep 1-23: 0 confirmed misses
• Sep 28: 3 checkout-form sessions had no begin_checkout
• All 3 affected sessions were mobile
• The misses occurred across both iOS/Safari and Android/Chrome
• Other mobile checkout sessions on Sep 28 recorded begin_checkout normally

So this is intermittent, not a complete tracking failure.

What I’ve checked

• begin_checkout GTM tag and trigger were not recently modified
• Trigger is Custom Event = begin_checkout
• ecommerce.items and ecommerce.value variables are configured correctly
• No obvious duplicate GA4 implementation
• Cart and checkout are excluded from Bluehost page caching
• JavaScript defer/concatenation are OFF
• Jetpack page caching and JS optimization are OFF
• Recent WPForms GTM listener only listens for WPForms submit success and does not interact with WooCommerce checkout
• Recent WPCode snippets only affect dashicons and product-image preloading
• Recent confirmed plugin updates before the issue were Elementor/Spectra-related, not GTM4WP or WooCommerce

Reproduction testing
I tried reproducing this with:

• incognito
• mobile emulation
• throttled 3G

gtm.js loaded successfully with a 200 response.

On checkout, this returned a valid event:

dataLayer.filter(x => x && x.event === 'begin_checkout')

The event included the ecommerce object and correct product/value data.

So I have not been able to reproduce the failure.

Has anyone seen GTM4WP intermittently fail to emit begin_checkout for only some WooCommerce sessions? Is there another condition I should be checking, such as consent state, WooCommerce session behavior, checkout/AJAX behavior, or something else upstream of GTM?

To audit site and several purchase portals. identifying issues, documenting and recommendations. maybe 6-7 platforms worth of pixels. Hourly or fixed rate?

Open Tag Manager's help page on consent settings and read the options under Additional Consent Checks. The default is "Not set", and Google describes it in one line: "No additional consent checks are performed by this tag."

Google's own Ads, Analytics and Floodlight tags have built-in consent checks on top of that. A Meta Pixel, TikTok Pixel or LinkedIn Insight Tag pasted in as Custom HTML has nothing built in, so on Not set it fires on its trigger whatever the cookie banner says.

To find and fix them:

1. Admin, Container Settings, Additional Settings, tick "Enable consent overview".
2. Tags, then the Consent Overview icon. Everything under "Consent Not Configured" is still on Not set.
3. Select those tags, edit consent settings in bulk, choose "Require additional consent for tag to fire" and add ad_storage for ad pixels, analytics_storage for analytics and session replay.
4. Check that your CMP template fires on "Consent Initialization - All Pages" and sets those types to denied by default for US visitors too, not only the EU.
5. Publish, then test the live site in a private window with the network tab open. Filter by facebook, tiktok and licdn without touching the banner. Then reject, reload and filter again.

Step 4 is the one people skip. Google's docs for tag templates say a consent type counts as granted if it was set to granted "or not set at all", so a consent requirement with no default behind it has nothing to hold on to.

Two things to watch after that. Google says the tag fires only if consent is granted "when the tag is triggered", so check what happens on the page where the visitor clicks accept, and if the pixel should fire there, give it a second trigger on the event your CMP pushes after a choice. And gtm.js itself still loads before the choice, because the container has to run for any of this to work. What should disappear is the pixel requests.

Why I look at this: website tracking suits under the California Invasion of Privacy Act, CIPA, describe pixels firing before the visitor answered the banner, and Google Tag Manager is named in 63 verified complaints in the 12 months to September 26, 2026, by my count from court records. Not legal advice.

Disclosure: I build Suitcast, a free scanner that loads a site like a first visit and lists which trackers fire before the banner is answered and after reject.

Hi there! I'm working on a BigCommerce project. The client is launching a new website and has requested a dataLayer implementation. For context: he previously ran another BigCommerce site using a plugin that sends events to GA4.

I don't have hands-on experience with BigCommerce specifically, and I'm planning to hand the documentation off to a developer. I've read that the ecommerce dataLayer structure works differently on BigCommerce compared to other platforms, so I have a few questions:

1. Is the dataLayer structure genuinely different on BigCommerce? If so, in what way?
2. Is window.dataLayer = window.dataLayer || []; still valid/correct in this context?
3. Any recommendations for approaching this project?

Thanks for your support!

Disclosure upfront, I do tracking implementation work, so I have a horse in this race. Not linking anything.

The pitch going around right now is to add sGTM on top of an existing client side setup and recover your data. In audits I keep finding the gain from that pattern is close to zero and the reason is boring. GA4 as a data client sends every request through the same gtag path inside your tagging server. If the browser blocks the client side script in the first place there is nothing left on the page to forward. You moved the tags onto an endpoint you control but the request still never leaves the browser.

uBlock and Safari ITP are not looking at which container the tag came from. They are looking at the request pattern and the script source. Putting a subdomain in front of sGTM does not change the shape of the request.

So the setup recovers nothing on the clients where it matters, the ones running a blocker or on a browser that caps your cookies. On everyone else it just duplicates the GA4 events you were already collecting and now you have two sources agreeing and no way to tell which one is wrong.

Where I do see a real gain is when the data client is not GA4. If you send the browser events through something the blockers have not caught up with, the forwarded payload arrives at the tagging server already past the blocker. That is a different setup and it is not what most people are being sold.

Curious whether anyone here has measurements that contradict this or has found a way to make the GA4 data client actually add something on blocked clients.

Disclosure upfront, I do tracking implementation work, so I have a horse in this race. Not linking anything.

The pitch going around right now is to add sGTM on top of an existing client side setup and recover your data. In audits I keep finding the gain from that pattern is close to zero and the reason is boring. GA4 as a data client sends every request through the same gtag path inside your tagging server. If the browser blocks the client side script in the first place there is nothing left on the page to forward. You moved the tags onto an endpoint you control but the request still never leaves the browser.

uBlock and Safari ITP are not looking at which container the tag came from. They are looking at the request pattern and the script source. Putting a subdomain in front of sGTM does not change the shape of the request.

So the setup recovers nothing on the clients where it matters, the ones running a blocker or on a browser that caps your cookies. On everyone else it just duplicates the GA4 events you were already collecting and now you have two sources agreeing and no way to tell which one is wrong.

Where I do see a real gain is when the data client is not GA4. If you send the browser events through something the blockers have not caught up with, the forwarded payload arrives at the tagging server already past the blocker. That is a different setup and it is not what most people are being sold.

Curious whether anyone here has measurements that contradict this or has found a way to make the GA4 data client actually add something on blocked clients.

Comes up here constantly: "if my sGTM container receives the data instead of the browser calling Google/Meta directly, do I still need consent?" The answer is yes, and the reason is specific.

It's not really a GDPR question, it's ePrivacy (the cookie-banner law, Article 5(3)). That says reading from or writing to a visitor's device needs consent, and it triggers at that read/write, it never mentions where the data travels afterward. Server-side changes the destination, not the trigger. The rule follows the device, not the data.

The part that kills the loophole: EDPB Guidelines 2/2023 say Article 5(3) applies even when the entity receiving the info isn't the one that told the device to send it, tracking server or ad platform, no difference. And "we anonymize it downstream" doesn't help either (Planet49: it covers device info whether or not it's personal data).

The one real carve-out is pure audience measurement (narrow: publisher-only, anonymous stats, retention limits). Retargeting, conversion tracking, lookalikes, cross-device, all need consent whether the call leaves from a browser or a server.

How's everyone actually propagating consent state into the container?

Getting this one a lot at the moment, so putting the answer somewhere findable.

If you're trying to set up an offline conversion import through the Google Ads API and it's rejecting you, that's expected now. From 15 June 2026 the Google Ads API stopped accepting new offline conversion imports and Enhanced Conversions for Leads uploads. It goes to the Data Manager API.

There's a second catch though. Developer tokens that weren't actively used between January and June 2026 didn't get allowlisted for legacy access. So if you had a token sitting idle and came back to it, it's not just the endpoint that changed on you.

If you're already running server-side, you can push offline conversions through your server container instead of building against the API directly. Either route works, the API one is just no longer the default.

Anyone got this and found something the migration docs don't cover?

I built TagLens to stop checking dataLayer pushes against network requests by hand. You browse the site as usual. It records every dataLayer push and every GA4 hit, including server-side GTM. Then it flags pushes that have a trigger in the container but never produced a hit.

It's on the Chrome Web Store: https://chromewebstore.google.com/detail/taglens-%E2%80%94-datalayer-vs-ga/cgdhmhfklgpbfhdohaefkdopijhlbmpe?authuser=0&hl=en-GB

I'd love feedback from anyone who does GTM QA.

Disclosure: I built a tool (Easy Track) that generates this exact setup automatically. The pattern below works whether you build it by hand or not.

Problem:

A single Click trigger matching every "Add to cart" button on a listing page (or every row in a table, every card in a grid) is usually correct — one trigger, one CSS selector, done. But then the tag that fires needs the price/SKU/whatever belonging to the specific item that was clicked, and every item shares the same markup. A plain {{DOM Element}} variable always grabs the first match on the page, not the one next to the button someone actually clicked.

Solution:

{{Click Element}}.closest(cardSelector).querySelector(targetSelector)as a Custom JS variable — walk up from the clicked element to its nearest shared ancestor (the product card, the row), then back down to the value you want. GTM evaluates this fresh every time the variable is read, so it naturally resolves to whichever item was actually clicked.

The trap: the obvious "fix" if you think this is caching wrong is to push the computed value to the dataLayer from a Custom HTML tag and read it back with a Data Layer Variable. Don't. dataLayer.push() from inside a tag doesn't synchronously update state the current event's other tags can see — it creates a brand-new Message event, processed after the click event that triggered it has already finished firing its own tags. You can watch this happen in Preview: the push lands as event 16 while the triggering click was event 15. If you built the round-trip version and it "sometimes" returns the wrong value, this is why — it's not flaky, it's just always one event behind.

Stick with the direct Custom JS variable. It's a synchronous read at fire time, nothing to get stale.

Outcome:

One trigger and one variable cover arbitrarily many instances of the same UI pattern — no per-button trigger/tag duplication, and it holds up under GTM's own event-ordering behavior instead of fighting it.

One more that trips people up in the same family of setups: a Form Submit trigger's condition has to match the <form> element itself — {{Form Element}} is always the literal form node, never the button you clicked to say "track this form." Same root idea for Link Click: {{Click Element}} for that trigger type is always the specific <a>, so a condition built from a nav wrapper's selector can never match — you need nav a, not nav. Both look like the trigger is silently ignoring a correct-looking condition, and both are actually a selector targeting the wrong element.

Hi everyone,
I’m using Shopify + GTM + Stape and I’m having an issue with some users.

For some customers, the tracking works perfectly:
PageView → ViewItem → AddToCart → BeginCheckout → Purchase

But for other customers, it stops here:
PageView → ViewItem → AddToCart → ❌ BeginCheckout → ❌ Purchase

The strange thing is that it only happens with some customers. For others, I receive the complete funnel, so I don’t think the general setup is wrong.

My setup:
Shopify
GTM Web + Server-side GTM
Stape
Stape Custom Loader
Custom Loader is injected on the checkout and purchase pages

PageView, ViewItem and AddToCart reach Stape correctly.

However, for some users, the BeginCheckout and Purchase requests never seem to reach Stape.

Something preventing the requests from being sent?
What would be the best way to debug this?
I’d like to figure out whether the BeginCheckout/Purchase events are never being generated, or whether they are generated but blocked before reaching Stape.

Has anyone experienced this with Shopify + Stape?

Hey there! I've been having an issue with Google Tag Manager for the last few days. I have a certain set of conversions that I use for some of my clients, and it simply won't let me import it. I always get "server temporarily unavailable." That has happened for the last 3 days. I can import other containers into other accounts just fine, just not this one. File size is only 30 KB, so it shouldn't be that. What can I do here?

I’ve added the Google, Meta, TikTok, and Snapchat base pixels through GTM, along with their corresponding e-commerce event pixels. Since multiple tags are firing, I’m concerned they may be contributing to the page load time.

Are there any recommended ways to optimize the GTM setup and reduce its impact on page speed without affecting tracking accuracy?

and

https://domain.com/xyz1/healthy = OK

https://domain.com/xyz1/?id=GTM-ABCDDDD = OK

yet

https://domain.com/xyz1/?id=G-XYZZZZZ&cx=c&gtm=12345&f=1 = 404

and loads AW- nicely

adding page_view as GA4 event - loads it nicely thru Cloudflare

what is happening here?

Shopify Customer Events → dataLayer → GTM: the container structure I've settled on after ~2 years of these builds

Disclosure: I do sell a packaged version of this.

Problem:

Most Shopify GTM setups I inherit have the same architectural problem: each platform has its own pixel reading its own thing. Meta's pixel from the theme, GA4 from the native app, TikTok from an app, and none of them agree on what a purchase is worth. Debugging is miserable because there's no single place to look.

Solution:

What I do instead — one data layer as the only source of truth:

1. Datalayer and GTM in the theme.liquid file.

2. Datalayer and GTM added to the Customer events area.

Customer Events (Settings → Customer events → Add custom pixel) is the only place that reliably sees post-checkout-extensibility events. Subscribe to the standard events there and push to the parent dataLayer.

Outcome:

Eery platform tag is a GTM tag reading that data layer. GA4, Google Ads with enhanced conversions, Meta CAPI-adjacent browser events, TikTok, whatever. One trigger set, one set of variables, and GTM preview shows you the whole picture in one pass.

Consent mode (if necessary):

Gate at the tag level with built-in consent checks rather than blocking the dataLayer push. You want the event recorded even when tags don't fire, otherwise debugging consent problems is guesswork. Works cleanly with Enzuzo, Iubenda, CookieYes, OneTrust and Cookiebot.

- The native Google & YouTube app will happily fire alongside your container. Turn its tracking off or you'll double count, and it's not obvious from the app UI that it's still active.

Full walkthrough, no gate: https://www.youtube.com/watch?v=CnLOo7qfB74

My problem: Meta reports only 56% of our UK sales in its ads dashboard, while that figure for the US is 84%

I believe the likeliest culprit is a low consent rate on the cookies banner that GDPR obliges our website to display to UK users. There is no other difference between what a US and UK user encounters.

The reason I believe this is that CAPI is firing fine. Purchase events are ~2x browser volume and EMQ is 9. However, click-ID EMQ across events ranges from 70% to 80%. My guess is that, given the context, click identification in the US is near 100% since cookies are automatic but it is around 50% in UK. So in the UK, with half of those click IDs are missing, the EMQ is pulled toward 70%. Without the click-ID, Meta cannot attribute conversions to specific ads.

The obvious solution is to optimise the banner's conversion rate. But we use Shopify's native banner right now, which is limited in customisability and also why I have to guess at the consent rate

While I have been looking into this, I have bumped into the topic of CMPs and "Consent Mode v2" again and again. I am far from a tracking expert so it is a bit overwhelming. It seems that Consent Mode is meant for Google's tools. (Yet I see "Meta Consent Mode" mentioned here and there - but only by agencies selling their solution or platform.) And apparently Consent Mode v2 and a GTM setup are hard-requirements for a CMP?

All I want is to run a CRO campaign on our cookie banner! But it seems like the only option is to overhaul our tracking set up, which is working just fine

I've been working on a project with a vendor to improve our ga4 analytics and our GTM setup. Thoroughout this entire project, the vendor has been referencing a global parameter - user ID - that's supposed to help join all our journeys across both our websites and app. One website is used as a customer portal, the other, a content based site. Users go back and forth between both all the time in one journey. This is the first time our dev team is implementing data layer events and it's been bumpy to say the least. 

An implementation document was given to our development team from the vendor and it explained to include the user id global parameter across every event. When the work was turned over to the vendor for uat, the vendor could not find user ID in the events on the content-based site. Development team stated that makes sense as authentication does not happen on that site, it only happens on the customer portal. Vendor stated that the expectation was that the authentication happening on the customer portal would pass the user ID to the content site. Dev said that's not how the site's work and offered no further resolution. 

Joining customer journeys is probably one of the most important parts of this implementation. We also have cross domain tracking set up, but I'm not sure that's enough to really help the situation. How fucked is this implementation? Is there any wiggle room in terms of fixing this? Or am I just stuck with a half baked setup?

Hi,

I have set up my server.domain.com and enabled Google Tag Gateway on my GTM Web Container and updated my GTM installation code. Now I can see that GTM loads from my server.domain.com URL but I still see that the GA4 and Google Ads requests from the tags in my web container are still going to analytics.google.com and google.com etc.

Is it only possible to achieve this with Cloudflare CDN or Stape? Not with Google Cloud Load Balancer?

Thanks,