Shopify - huge gap between Shopify and sGTM (Stape Logs)

Hi,

I’m experiencing a huge difference in purchases between Shopify and logs from the Stape server (incoming Data Client). These differences often reach 70% daily.

Website: https://thestorytime.pl/
I’m using “Custom Loader” and “Cookie Keeper.” I have everything set up according to the instructions or webinars. I have CMP, but at this moment my tags don’t require consent - they always fire.

For example, yesterday in Shopify, I had 5 orders, of which the sGTM Data Client only received 2. Most of the tag settings are from Setup Assistant (I only added “stitching” and “purchase_webhook”).

Has anyone had a similar experience? I’m sending missing transactions via webhook, but it should be a maximum of 20%, not 70%.

Hi @Stanislaw_Krol

It seems you aren’t viewing the logs correctly.
You’re using the Data Client → Purchase event filter
But webhook events are listed under the “Other” category.
That’s why you’re only seeing some of the events

In your case, the best way to validate events is to use the outgoing logs.
I see 5 outgoing Facebook - Purchase events for the 31.05.2026

So, It looks like you don’t have any problems :slight_smile:

Hi,
Thank you for replying. I mean the difference between CRM and sGTM. Purchase events for 26.05:


6 were picked up by sGTM

10 were sent via webhook, which shows how many orders there were in total in the store.


10 were sent to FB (ignore error in 2 cases, I already fixed it).

Finally 6 were sent from a browser and 4 were sent via webhook.

There’s a similar level of missing events every day. Is 40% normal? It looks suspicious because I use power-ups.

Hi @Stanislaw_Krol

Okay, I got what you mean.

The discrepancy between the number of standard events and webhooks has nothing to do with power-ups.
The “purchase_stape” event triggers based on the native Shopify analytics.subscribe(‘checkout_completed’) event.
In some cases, the native event does not fire, which causes the “purchase_stape” event does not fire as well.
This is most often due to certain payment methods that do not redirect the user back to the site where the item was purchased.
This issue is also frequently associated with certain upsell apps.
Also please note that the standard “purchase_stape” event only covers orders from the “Online Store” channel. So, draft orders, subscription orders, and certain upsell orders can only be processed via webhooks.

So the answer is: no, a 40% difference is usually not normal, but it really depends on how your Shopify store is set up and how you structure the user journey.

Hi Vlad,

​Thanks for the explanation.

​To give you more context about my setup: the store only sells physical products. We don’t have any subscription plans, recurring orders, or recurring billing options at all. Every transaction is a standard, one-time purchase of a physical item.

​Also, we don’t process any draft orders or manual orders from other channels - everything goes strictly through the standard Online Store checkout.

​Given that subscriptions and other sales channels are out of the equation, a 40-70% discrepancy still feels way too high. What else should I look into?

​Thanks again for your help

Hi @Stanislaw_Krol

In that case, my best guess right now related to the the payment method which is not redirecting back to the site after a successful payment / or redirecting with delay.

Vlad is right that the counts reconcile. The piece that count reconciliation doesn’t show is how much signal those webhook-only purchases carry. A Shopify webhook won’t include fbp or fbc unless you captured them earlier in the session and stitched them back, usually through something like checkout_started keyed to the cart token, which Custom Loader and Cookie Keeper don’t do on their own. Those orders still match on hashed email and phone plus IP when it’s there, so nothing is broken, Meta just has fewer identifiers to work with. Ten orders is too small to call it a 40 percent loss rate, but if the pattern holds on more volume, that’s the kind of thing that quietly weakens the optimization signal without ever showing up as a missing order.