GA4 purchase events for multiple Shopify stores spiked to billions in revenue starting Aug 4–5, with no matching Shopify orders. Events featured malformed product names, zero prior engagement, and often no Transaction ID.
Observed patterns:
Single-event sessions from desktops (Chrome), English, mostly geolocated to Germany (also NL, Pakistan). Source/medium “(not set)” and page URLs on /checkouts/cn/[hash], not /thank-you. Later variants added T_ transaction IDs and fired on /thank_you, sometimes tripled.
Working theories:
Spoofed purchase events injected into the dataLayer (a tracking object GA uses), not real checkouts. Potential relation to Shopify’s Checkout Extensibility and single-page checkout; some noted abandoned-cart link similarities. Google suggested “misfiring tag,” but many doubt a tag issue given the timing/scale.
Mitigations tried:
GA4 Explorations filtering (exclude missing Transaction ID, exclude Germany or (not set) source/medium). Event modifications had limited success. Using Shopify reports, Looker Studio/BigQuery to cleanse data, or spinning up a new GA4 property (which for some did not receive spoofed data). GTM rule “Transaction ID must not be blank” helps only if GTM controls the purchase event.
Status:
Shopify investigating; no confirmed fix. Activity subsided around Aug 23 for several but was intermittent. Nov 2024 post about real Shopify orders via /checkout/cn/ deemed a separate issue; advised to contact Shopify Support.
Open questions:
Root cause and definitive prevention remain unresolved.
Summarized with AI on December 13.
AI used: gpt-5.
Earlier this week, we had $21 billion in sales over 2 days logged in GA4… which I can assure you is not remotely accurate. Looking at the purchase events, it looks like fake events are being sent into our GA4 account. If you compare the fake events to the real ones, you’ll see the product names are not structured right, and there are 0 views and 0 add to carts for those items. We had no code updates this week that could’ve accounted for this. Does anyone have any suggestions as to what might have occurred or how to check?
Our SEO agency suggested that the way to see where it came from would be to look at the server data, but since we can’t see the backend of our Shopify store, I’m not sure if there’s another way to figure out what happened or keep it from happening again.
Below, you can see the top 6 products are the ones with the crazy data, and the ones at the bottom are are normally formatted products.
haha. Congrats on the biggest windfall in ecommerce history. Create a report to have a look at the hostname of such data. That’ll tell you whether it even came from your domain, which means it’s got nothing to do with your set up or store. A lot of spam can identified from different host names. Chances are it isn’t since a purchase is what triggers the purchase event in Shopify’s standard GA set up.
I’m seeing the same thing in the GA4 Property of two stores. One has now reached $14B in fake purchase events and the other is just under $90B. The “good news” is that none of these purchases hit either site’s Shopify orders table, so none were processed and there were no charges from a fraud prevention service or a processing fee. We’ve been able to isolate them in GA4 quickly because none of them have a Transaction ID. To find them in your GA4 property create an exploration for purchase events and then use the filter to exclude any order with a Transaction ID.
Findings from my investigations on one site earlier this week are below.
The purchases that took place on August 4th and 5th were contained within the hours of 4am-11am, and a small spike at 3pm-4pm, but those that took place on August 6th and 7th expanded into the afternoon, until 2pm.
GA4 shows each Purchase as being from a unique user and session.
GA4 shows that each purchase was from a user in Germany, the Netherlands, or Pakistan.
All events took place on Desktops, via Chrome browsers, English language.
Traffic source/ medium for the session is unknown/ unassigned.
Value for these purchases are totaling just under $14B (for the site associated to the findings posted here, and just under $90B for the second store. The second store’s dimensions are virtually the same.)
These purchase events did NOT take place on thank-you pages. URL shows the event took place on URLs containing /checkouts/, meaning that these purchase events did not fire as a result of a completed purchase, but an extra/ erroneous event during checkout. For example:
I think it’s noteworthy that they all begin with /checkouts/cn/Z2NwLWV1cm9wZS13ZXN0MT but I don’t know enough about how the checkout URL is constructed to take this any further.
Also noteworthy, Shopify Checkout URLs (for the this site) end in /information, /shipping, or /payment for shoppers depending on the step of the workflow, and none of the URLs where the purchase event took place have any suffix beyond their hashed string. Attempts to remove the suffixes refreshes/ redirects to add it back.
All purchase events contained one or more of a selection of three products, in various quantity
There are no Transaction IDs associated to any of these purchase events. There is no record of them in Shopify or our server-side GA4 integration that is monitoring for purchase events, meaning they did not hit a Shopify purchase event, rather, a purchase event was somehow added to the dataLayer and picked up by Google Analytics.
I have been unable to replicate this but ChatGPT said I could do it with PostMan and then told me that it was glad I’m a good person and it knows that I would never abuse that ability.
Using the User Explorer function in GA4 to isolate users with one of these rogue purchases shows that these Sessions have zero other activity and the only recorded event associated to that user was “purchase”.
GA4 believes that the user was not on any other pages, the user did not actually add an item to their cart in the session, and that the actual duration of their session was 0 seconds.
There is no recorded Landing Page, meaning GA4 does not know what page the user entered the site.
This is confusing because each purchase events has a Page Referrer dimension from another page within the site.
Hope this helps anyone who finds this in their Properties. It doesn’t seem to have any kind of purpose, but there are more and more analysts and managers of stores/ GA4 accounts posting about this cropping up last week. This is causing a pretty big smear in the data for stores- Friendly reminder to make sure that any filters you’re applying to the Property to read the data remove all aspects of the sessions with the purchase events, not just the purchase event itself and the associated revenue.
Hi there! We are seeing the same issue… how do we stop it? Nothing is reporting on Shopify, only in GA4. We recently upgraded the checkout process to enhanced checkout integration.
Hey Natmurray- solid question… This is still going for a couple of sites that I can see. I’m looking for a way to prevent it without too much luck yet though. I do have a ticket in with Shopify, and I’m hoping that they can help.
If this were being measured in GTM, we could add a condition to the purchase event trigger for “Transaction ID must not be blank” or something, but the issue is that these events are hitting the checkout pages with a purchase event directly, so there’s no change to GA4’s configuration or GTM triggers that would prevent these. I’ll post if I have an answer.
Any response from Shopify yet? I have found I can at least filter my GA4 reports to exclude Germany because all of the fake data is coming from Germany.
The only response I’ve had from Shopify thus far is that they were still looking in to it. I sent them the link to this thread though. So hopefully they have enough info to start troubleshooting.
I have been going absolutely crazy all week trying to nail down this issue. I knew it had to be some type of fluke because it started happening while I was on vacation, so I know nothing was changed on my end that may have caused it.
Just wanted to chime in that we’ve been seeing the same thing happen in GA4 for our shopify store. It also started around the same date - August 4th or 5th, and also seems to be intensive traffic coming from germany. There is a direct correlation between the amount of traffic and the amount of claimed orders for that day, ie days which have higher traffic have higher orders. And also similarly the order totals are up in the $billions with $millions of quantities sold.
I had a hunch that maybe it was some bot or something refreshing an order thankyou page, but as post above says maybe its more of an event being triggered on a checkout page. It also for us only applies to 2 or 3 seeming products, and the product titles are mis-formed and don’t quite match actual products in terms of specific formatting and hyphenation etc but are very close to the kind of structure we use so almost look like normal products. The annoying thing is that this fake data is polluting our real data making it very hard to view any actual sales or traffic reports because they’re totally blown of scale by the huge spikes.
Anyone know if there might be a way to add some kind of filter or something to GA to block out and ignore this incoming data from specific locations or sneders or whatever? I’m not sure what we can do to really stop this happening.
In the next day or so, we are releasing a potential fix to prevent the purchase events on one of our sites and I will update once I have some idea of if it has worked or not.
I am still looking for the most effective way to exclude ALL of the data associated to these purchase events in GA4.
Options such as "Exclude purchase events where Order ID Does not RegEx Match: .* " will result ONLY excluding the purchase event while keeping the session/ user data in tact, which impacts Conversion Rates, Landing Page Reports, Time on Site, Engagement Rate, etc, etc.
I know there’s no way to make a “view” in GA4 (RIP universal), and I loathe the idea of needing to manually add a filter to reports every time I load a page or operating exclusively out of Explorations.
I coooouuuulllld recreate our most used GA4 reports in Looker Studio and apply a filter there, but then we’d hit the quota very quickly, and there’s always a chance that something is not configured properly.
I’m exploring options on how to import data to a dataLake and then into BigQuery and isolate the murky water, but need some time.
I’d really prefer to avoid setting up an entirely new GA4 property, but could do so and then utilize Looker Studio for any kind of Year over Year comparison, but this feels very heavy handed, especially because we have years of data in our Property.
I know we cannot “Call Google” and say “look at all this fraud data. please help”, so we’re essentially on our own here.
I found another thread from back in June where a store owner said that they were getting a surge in views from Germany: https://community.shopify.com/post/2628523. I’ve reached out to see if they had a similar experience. Hoping that there’s some kind of relationship and that we could get more insight to the cause/ discover a fix.
Shopify replied this morning and just let me know that they are continuing to investigate. I gave them the link to this thread, so I’m hoping that helps.
We are having the exact same thing. I have been able to add filters (source <> “(not set)” AND medium <> “(not set)”) to our report/data pulls. I have also been having a back and forth with Google support and they said it was misfiring tag. I doubt that all of us would have a tag go bad on the same date and do the same thing. The latest is that they want me to send them test payment information (would need to be a live card…not happening) so they can test that our conversion tracking is working. I asked if they could check the IP address and block it as it is probably the same. We have also stopped using GA4 due to this and just use Shopify for on-the-fly reporting. Hoping Google comes back with something better than a tag issue. If so, I will share it here.
Perhaps there is a Shopify app using a web pixel that is somehow misfiring? Would anyone feel comfortable listing out their apps to see if there is a commonality we can narrow down?
