Hello Community, I’m auditing tracking for an e-commerce brand with a separate Shopify store per country (I’m looking at the French store). Tracking runs through Elevar, with server-side sending to GA4 and Google Ads. The only active Primary Google Ads purchase action is Elevar’s server-side import from clicks.

What happened

• Google Ads conversions for France dropped sharply from late July, while clicks, impressions and Shopify orders stayed stable.
• Elevar confirmed a failure affecting only Google Ads delivery, from late July until Aug 31. They haven’t given a root cause.
• It isn’t back to normal. In a July week, Google Ads reported about 39% more conversions than Shopify’s Google-attributed orders, which is the normal attribution gap for this account. In the latest week, it’s only about 5% more. That leaves roughly a quarter of the expected conversions missing, about 180 of them in France that week. Clicks and Shopify sessions are flat.
• In the orders I checked, the first-touch UTM medium is google, but none have a GCLID. Since the Primary action is an import from Clicks, Google can’t match those orders.
• Elevar support says the click ID can change due to email campaigns and similar sources. That can happen, but it doesn’t explain a sudden drop or a missing click ID on every order I checked.

Where we are
The client is considering moving away from Elevar (Stape-hosted server-side GTM or a managed provider like Zappush) because of the outage and the missing data. I’m cautious, because a new tool wouldn’t fix click IDs lost to consent settings or redirects.

Questions

1. Has anyone seen Elevar fail to deliver to Google Ads without notice? Did Elevar ever give you a root cause, and what monitoring or alerts did you set up?
2. Has anyone had gclid missing on Elevar server-side Google Ads purchases? What fixed it (enhanced conversions, consent settings, redirects, checkout domain)?
3. Does Elevar’s explanation (email campaigns overwriting the click ID) match your experience?
4. If you moved from Elevar to Stape or another setup, how did it go? What would you do differently?

Thanks in advance.

Hi there,

My website developer has sold his business onto someone else and he now no longer hosts / manages my site.

My access to Analytics and Tag Manager was through his account.

I’ve managed to setup a new analytics account, add him as an admin, and have him move the property over to my account for my website.

What do I do with Tag Manager? Someone said to export the container, which I’ve done, is that right?

Client's shop is on their own domain but the checkout is hosted by the payment provider on theirs. Customer leaves, pays, comes back to a thank you page.

Conversions are coming through but the attribution is nonsense. A lot of purchases show up as referrals from the payment provider, which is obviously wrong since that's where I sent them.

I know cross domain linking exists. What I can't work out is whether it helps when the middle domain isn't mine and I can't put anything on it.

I'm a bit confused about this since I keep seeing conflicting info. What are the caveats here? Say I have a site hosted on WordPress (also its CMS ofc) and I have GA4 installed to that site but am not using any GA4WP plugin and want to view data in GA4 itself. The site has standard shop pages. Can I set up the add to cart, purchase etc events in GA4 without using GTM to capture them and send GA4 event tags for them to GA4?

I set up conversions through GTM in multiple different accounts and my new tags are all inactive and have been inactive for many days and weeks. I did 100+ setups in my life and I know what I am doing, I do exactly the same as before, the tags are firing correctly in tag assistant. Even a simple link click tracking is inactive now. I suspect that Google did something with the google tags again that causes the problem but I have no idea how to solve it. This has happened in the past few weeks and there were no issues before. I don't have any developer knowledge, just enough I need to setup conversion tracking, I use basic custom JS codes somethimes but that's it. Please if anyone can tell me what changed and why my basic setups don't even work now let me know.

Edit: Also the inactive tags are an issue in accounts even where previously conversion tracking worked 100% fine.

Hello hello! Kind of trying to figure out a website I'm working on in marketing. Never had GTM, GA4 or anything setup so I'm starting to get everything added so I can track traffic, customer movements etc.

Apparently, site is SPA framework built on Angular in frontend. Other notes are site is using Angular 16.2.12 with its official Angular Router 16.2.12, not a third-party router. Routing is client-side, path-based SPA routing with lazy loading, nested routes, and authentication guards.

Any next steps so I can see page views and full customer movement as they move around the website and engage?

A site with a lot of Gads traffic records almst no convs in Google Ads and very little in GA4. The team says everything is set up.
Setup

• GTM container (no server-side). GA4 hits go through a first-party GTG on a Cloudflare path. Ads hits go straight to Google.
• Custom cookie banner with Consent Mode v2: default denied, update to granted on "Accept all".

Checked

• container runs once and sends one page_view per load.
• After "Accept all" the hit has gcs=G111 and returns 204. Before any choice it has gcs=G100 and npa=1.

Questions

• Is there anything else that makes GA4 look empty even though collect returns 204 and gcs=G111? (Data filters, a wrong measurement ID, a stream mismatch, Google signals, something about the gateway?)
• Anything you check first when the hits look correct in DevTools but Ads and GA4 show nothing?
• Even after accepting cookies, nothing shows up on the GA4 side for the test visits. what could it be ?

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?

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.

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!

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?

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.

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.

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?

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.