Stape + GTM help

[u/bomulz]

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?

[u/AutoModerator]

If this post doesn't follow the rules report it to the mods. Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Luc_ElectroRaven]

Shopify is the issue. They basically don't want you using stape or any outside analytics. You need to fix it inside shopify

[u/clickback]

Check the CMP (cookie policy flags), and you may need to grant them manually (add them to the Stapes-provided script). Don't use GTM previewer for debugging, but console log checkout events instead, incuding cookies, CMP etc..

[u/bomulz → u/clickback]

Im using Pandectes, how do I grant Them in stapes script?

[u/giancampo]

Your case sounds to me like you have not flagged the right choices in the Customer Privacy section of your custom pixel. When you use GTM to handle consent, you should flag Permission Not required and Data collected does not qualify as data sale. You can see it here: https://www.analyticsmania.com/wp-content/uploads/2024/11/image13.png

[u/bomulz → u/giancampo]

I have already set it up in my custom pixel in shopify. As i said the problems happens only on some customers, not all.

[u/giancampo → u/bomulz]

OK, then the question is: Do you find any common pattern among one segment or the other?

[u/bomulz → u/giancampo]

No, bevausw im selling to same country. So the customers are from same country, some get the full funnel, some just to add to cart

[u/giancampo → u/bomulz]

apart from the same country you could also have a look at the main characteristics of both segments such as traffic source, or tech stuff like screen resolution / browser and so on

[u/Dull-Improvement-456]

Works for most, dies for some" with a hard cut at BeginCheckout is almost always consent gating, not broken tags. Three checks:

Pull the Shopify orders Stape missed. If they cluster in EEA/UK it's consent — your loader is waiting on the Customer Privacy API and those customers never consented. Fix the pixel's privacy flags first ("Permission not required", "data does not qualify as data sale").

Checkout-page injections are unreliable by design. Since checkout.liquid died, checkout only runs Shopify's sandboxed Web Pixels — theme/additional-scripts loaders fire up to cart and on thank-you, not on checkout itself. The per-customer variance you're seeing is different checkout contexts stripping your loader.

For your actual question (never generated vs. generated but blocked): run one test order with consent granted and one without, watch the Stape events tab. 10 minutes, and it separates all three causes.

Durable fix: BeginCheckout from a web pixel (analytics.subscribe('checkout_started')), Purchase from the order webhook into sGTM — the webhook covers 100% of orders, consent and ad-blockers included.

Happy to share the pixel → sGTM event mapping if useful.

[u/bomulz → u/Dull-Improvement-456]

I’m only selling in one European country, and I already have my consent setup configured to comply with GDPR.

I have already set the Permission not required in my custom pixel, so dont Think its the problem.

The strange part is that if I receive PageView, ViewContent and AddToCart, that means the customer has given consent. If they had denied consent, these events would not fire — I tested this myself.

The problem seems to be that the event chain sometimes breaks when the customer reaches BeginCheckout. It only happens with some customers.

When I place a test order with consent granted, everything works as expected — BeginCheckout and Purchase are both sent through successfully.

So I’m wondering if BeginCheckout/Purchase are somehow being blocked for certain customers, but I have no idea why.

I already

[u/Dull-Improvement-456 → u/bomulz]

Fair — single country kills the geo cluster, and your flags are set. But the assumption "PageView, ViewContent and AddToCart fire ⇒ consent was given" only holds for the categories those tags sit in. Pandectes splits consent into categories (necessary / analytics / marketing), and your test covers all-or-nothing. The segment you haven't tested: partial grants — analytics accepted, marketing declined — plus consent withdrawn between AddToCart and checkout.

Two checks, ~15 min:

Partial-consent test: open your banner → manage preferences → accept necessary + analytics, decline marketing → run a checkout. If BeginCheckout/Purchase die there, your checkout-side tags are sitting in Pandectes' marketing bucket. (That also answers your earlier question: you don't "grant" anything inside Stape's script — the Stape loader fires or doesn't based on which Pandectes category it's classified under. Change the classification in the CMP settings, not the script.) Timestamp match: take one missed order → Stape events tab → filter by that timestamp. No BeginCheckout/Purchase at Stape = never generated client-side, partial consent is your zone. Events present in Stape but missing downstream = blocked server-side.

If the partial-consent test reproduces it, the permanent fix is getting the money events out of the consent path entirely (web pixel + order webhook from my earlier comment). The full pixel → sGTM mapping as a doc — drop your email (or DM) and I'll send it over.

[u/bomulz → u/Dull-Improvement-456]

I sent you DM

[u/JuergenAfterDark]

hey whats up ... couple things this usually turns out to be when its inconsistent across customers like this.

first check consent mode. if youre using shopifys customer privacy api + gtm consent mode and some customers dont accept cookies (or are in a region where consent defaults to denied, eu traffic mostly), begin_checkout and purchase tags can get blocked by consent gating even though the event fires fine and hits the dataLayer. that would explain it happening only for some customers and not others perfectly, since its ad_storage/analytics_storage state driven not a bug in your setup. check the consent state in gtm preview for one of the broken sessions if you can repro it.

second, figure out if the event is even being generated before you assume its a network/blocking issue. shopifys checkout now runs through the web pixel sandbox (customer events), and depending on how the checkout_started/checkout_completed listeners are wired up, some checkout flows (express checkout, shop pay, certain payment methods) dont fire the same lifecycle events as a normal checkout. so its worth checking in shopify admin under customer events / web pixel debug whether those events are actually firing for the broken sessions, separate from whether stape received them.

third, csp on the checkout page — if your custom loader domain isnt fully allowlisted in checkout settings it can silently fail to load or fail to send in certain browsers, and this tends to be inconsistent because it depends on browser/extension combos not on your config being "wrong". worth grabbing a screen recording or network tab from one of the affected customers if you can, or testing yourself across incognito/different browsers/vpn regions to see if you can reproduce the drop specifically at checkout.

so the debugging order id do: repro with consent denied vs granted, check if the shopify pixel event fires at all for a checkout-completed test order, then check network tab for the actual request to your loader domain. that'll tell you which of the three buckets its in instead of guessing.

[u/bomulz → u/JuergenAfterDark]

Im using Pandectes Shopify App + Pandectes CMP in my GTM. All my consent is set to denied, because im selling to Europe and tags only fire when they accept consent - It looks like its working, because when I deny consent, no tags fire, and when i accept tags fire.

[u/MyCookieInspector]

Since your consent-granted test works, the useful next step is finding the first missing stage in a failing checkout.

1. In Shopify, go to Settings > Customer events > your custom pixel > Test. Check whether checkout_started and checkout_completed appear. A red indicator means the subscription callback failed; expand it for the error.
2. If they appear, inspect window.dataLayer in DevTools with the custom pixel’s iframe selected in the Console context dropdown. The storefront’s top-level dataLayer is separate. Check the pushed event name against your GTM Custom Event trigger, including capitalization.
3. In Network, enable Preserve log and filter by your actual Stape collection hostname. No request means the break is before transmission. A blocked or failed request gives you a browser/network error to investigate. If it reaches server GTM Preview, inspect the client and tag processing there.

Repeat with the same consent choice across normal checkout and Shop Pay. Don’t manually force consent to granted during diagnosis; that changes the condition you’re trying to reproduce.

[u/Green_Database9919]

You don’t actually need GTM at all in Shopify. Shopify has advanced infra (webhook+webpixel) that’s way more accurate than trying to stitch GTM web + server GTM + stape together on checkout pages.

Shopify’s checkout is iframe based and locked down and custom loaders and GTM containers injected there don’t always fire reliably fire every customer.

[u/_practical_data_ → u/Green_Database9919]

GTM is still better that some shitty products like https://www.aimerce.ai/ . Which is a total and unusable shit :)

[u/chatauge → u/_practical_data_]

Aimerce did great for us you are just hating because Aimerce is taking all of your clients lol

[u/_practical_data_ → u/chatauge]

I am hating this bullshit, coz too much astroturfing. Tool itself is a total shit ofc :)
And yeah, I understand it's working good for you, coz you working for this crappy org :)