GA4 Purchase Event being spoofed?

[westportbigtall]

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.

[Josh_Uebergang]

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.

[JohnTucker]

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:
  • /checkouts/cn/Z2NwLWV1cm9wZS13ZXN0MTpSYTFZZWhPSHJpMjZYTDJVWHl4a2lFZWFi
  • /checkouts/cn/Z2NwLWV1cm9wZS13ZXN0MTo0dm5HdXp4RTl0WDNvWVBHaUVYNkJmbG0y
  • /checkouts/cn/Z2NwLWV1cm9wZS13ZXN0MTpsTWRJb1VXSnVKU1pETnVvMnBpek1nbTBH
    • 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.

[natmurray]

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. 

We see many similarities as you said:

- Traffic and sales from Germany

- 0 engaged sessions, 1 avg session duration

- Product names are messed up, as mentioned.

[JohnTucker]

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.

[natmurray]

Thank you for letting me know what you hear back! I believe this client is
just connected to GA4 with the Shopify integration.--










Nathan Murray
Founder
Murray Marketing Services




(308) 440-8920

info@murraymarketingservices.com

murraymarketingservices.com

[Andrew24510]

Any luck here? I've been running into the same issue.

[westportbigtall]

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. 

[JohnTucker]

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.

[natmurray]

Thank you, John! Still nothing new from my side, either.

[Jesse_Meyers]

One of the shops I work with is seeing the same thing as you have described except that after the first few days of spam purchases with no transaction ids on the checkout URLs similar to what you've shown the spam purchases switched to using transaction ids that being with T_ (e.g. T_00386) and the page location for the event changed to /thank_you. Each event is being recorded 3 times with the same transaction id and with item quantities in tens of thousands and revenue in the tens of millions. Adding event modifications in GA4 does not appear to work to block these as they kept coming through unmodified. We have tickets open with Shopify, Elevar, and Google. Will update if anyone comes up with a solution. For the last couple days the spam events have stopped but not sure if that means it is over or not as they stopped a couple days before and started back up.

[fsualum]

I have seen that as well.  I have seen it stop for a day and then start back up.  Monday was correct for us, but I don't know about yesterday because GA4 hasn't updated yet.  Hopefully, it has stopped and we can move on from BD.

Check out this informative video about GA4 which I think we all would like.  It sums um my overall sentiment.  It's a good laugh when we all need one.

https://www.youtube.com/watch?v=92tmV4IMM7c

[JohnTucker]

Are these hitting a payment processor? Are they appearing in the Shopify purchase table? One of my bigger fears on this is that a store is going to start getting hit in such a way that the payment processors or fraud prevention services are going to see these "transactions" and start charging their fees, which are based on a percentage of the purchase value, and at these volumes would be pretty catastrophic.

also LOL @fsualum...

[Jesse_Meyers]

No, they do not show in Shopify reports and they are not real transactions. They only show as purchase events in Google Analytics 4. 

[JohnTucker]

Ok good- that's a relief. With what I know about the events themselves and Shopify, I don't believe that there is a method in which they could trigger an actual native Shopify purchase event, only hit tracking scripts that are monitoring a dataLayer, but when you mentioned the inclusion of a transaction identifier, I got a bit worried.

[ravele17]

All of the findings above are correct. Unfortunately, there is no current solution for these spam events, but it may be worth trying to add a tool that can identify and block suspicious users on the site to help prevent them in the future.

[Kubby]

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.

[moderntribe]

I'm also experiencing this issue. Please help us fix this Google/Shopify!

[Kubby]

Up to 7.8k transactions today according to GA4. Not sure why Shopify can't address these types of issues with more of a priority.

[Paul_West]

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.

[Kubby]

Just chiming in to say we are experiencing the same thing, where it's only 3 products, which have titles formatted differently.

[JohnTucker]

Updates on my end:

1. 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.
2. I am still looking for the most effective way to exclude ALL of the data associated to these purchase events in GA4.
   1. 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.
   2. 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.
   3. 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.
   4. 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.
   5. 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.
   6. I know we cannot "Call Google" and say "look at all this fraud data. please help", so we're essentially on our own here.
3. 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/c/shopify-discussions/sudden-surge-in-europe-views/m-p/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.
4. 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.

Thanks everyone

[fsualum]

Hi,

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.

Thanks

[Andrew24510]

Interesting, so if correct this would be an issue with Google Tag Manager? I had just assumed this was bot spam.

[Paul_West]

I'm doubtful of a mis-firing tag or whatever. That would mean it should be affecting a ton of people all at once if it was e.g. a bug in some google script. AFAIK the data flows from shopify to GA in a built-in way that isn't even something user-controllable, so would have to be some kind of shopify or google bug, but that would then likely affect a ton of sites. I have no idea how widespread this is but you'd think if it was affecting like 1000's of stores that way they'd be on it like a hot potato.

I think it more likely that it's some kind of traffic from these other countries. It does seem to show for us at least that it was huge traffic spikes sourced in germany.

For the past couple of days though we've had almost none of this traffic. Fingers crossed maybe it stopped.

Or maybe it was AI waking up to take over the world and now it went to sleep.

[Kubby]

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?

[fsualum]

Great idea.  Here are the apps I think are relevant.

Wunderkind

Elevar Conversion Tracking

Yotpo Rewards

Yotpo Reviews

Bizrate

Facebook & Instagram

[Kubby]

The apps we're using that use the new web pixels are:

• Collabs
• Facebook & Instagram
• Intelligems
• Searchanise
• Snapchat Ads
• TikTok

[JohnTucker]

Possibly- I was chasing some info about an app that seems to have the ability to create dataLayer events that we have integrated to both of the sites  we're seeing the purchase events happening on, and also happens to appear on westportbigtall, but now I'm not seeing it in any of the lists below so I guess that rules that out.

- Of the apps I've seen listed out so far, I can almost immediately (I'm like 90%+ confident) say that this has nothing to do with Elevar, because they use their own dataLayer for events, and their events in GTM all use "dl_" prefixes. The purchases also do not appear in Elevar's records.

Another of my working theories is that this is somehow related to/ has something to do with Shopify's Checkout Extensibility. Keep in mind that the purchase events are all taking place on URL paths that contain /checkouts/cn/[random hash] , NOT the /thank-you/ url that indicates a purchase, so something is inserting an event in the checkout workflow. Also keep in mind that because the URL doesn't also include the /information, /shipping, /payment suffix after the hashed portion of the URL, which means that it is matching the URL structure used by a Single-Page Checkout Profile.  Single-Page Checkout is not compatible with checkout.liquid, which means that the store must be updated to Checkout Extensibility. Granted, at least one of the stores on which I'm seeing this is still using the Three-Page Checkout workflow, but they have still been updated to Checkout Extensibility for some time. Obviously we're all at some level of adoption of CE on our stores now that we're past the August 14th.

Thanks everyone for chiming in so quickly.

[fsualum]

One thing to add is that I was able to track the cart link to one customer.  I found that the bogus data in GA4 was tweaking the cart link and using the first 31 characters of the link (after the /cn/).  

[JohnTucker]

Could you elaborate on that? "I was able to track the cart link to one customer." GA4's User Explorer shows that all of the purchase events on the two sites I'm monitoring are coming from different users, and every single one of them have a session with JUST the purchase event (no page_load, session_start, add_to_cart, click events, begin_checkout, etc). So the theory is that the "user" is entering and hammering the /checkout/cn/ page directly. 

That said- each purchase has a referrer URL of a product page, which is typically the same one in their purchase event.

[fsualum]

Sure.  I looked in GA4 and got the full referring URL and downloaded them all.   I did a comparison to all of our abandoned cart links to see if I could find any similarities.  I did this by doing a character comparison template in Excel.  It checks the first 1 characters, then the first 2, and so on.  I did this and found that matching stopped at 31 characters for this traffic.  I then traced it to a specific customer who received an abandoned cart email (with link...this is the link that matched the first 31 characters).

[JohnTucker]

Oh this is suUUUUUUUuuuper interesting.

• Links in an Abandoned Cart email have a parameter that rebuilds the user's cart, so that they land on the site (likely on a page with /checkout/cn/[hash] in the URL) to complete their purchase.
• As I've learned from previous investigations on "why Cart-Transfer links from referral sources aren't preserving attribution," I can tell you that Shopify's cart/ checkout page does not preserve UTM parameters (and therefore source/ medium attribution), so traffic would appear as "Direct".

How many characters were there in the URL beyond the 31st? As ridiculous and unlikely as it might be, this could be a bit of a false positive. URLs appearing in GA4 for my two sites had the first 22 characters matching, but it added another 34 characters beyond that.

Does your email platform have any kind of customer tracking like Klaviyo? Is there any kind of matching dimension to the user to those in the purchase events such as location, time of day, etc?  Did the user who received that email open any links in the email? Do the links have any kind of UTM parameters?

[fsualum]

I am not sure how many, but it was quite a few...like 50 to 100.  The link is what you see in Orders -> Abandoned Checkouts.

Also, we use Cordial and these events are not being tracked there likely because they are fake. 

From what I can find, it is "ghost traffic".  We have all probably seen it in GA.  It is traffic with a source of "(not set)".  When you see this, it does not necessarily mean "direct" traffic.  That is how I always treated it until BD ("Billions Day") when this mess started.  Normally, I would see a few sessions with a source "(not set)" where it made a fraction of a percent of our sessions.  This all changed on BD.  I now remove them from all of my reporting.  My thought was that the customer whose cart this was had been hacked, but now knowing that other people are having the exact same issue, I don't think that is likely.

[westportbigtall]

I'm still using the liquid version of Thank You and Order Status. I have the integration apps for FB/IG and Google, and the only other apps I can see that might fire on Checkout are Stamped, Bad Customer, Avalara, Blockify, Fraud Filter, PostPilot, & Klaviyo.

Possibly related: I'm having an influx of hotmail email addresses being added to my Klaviyo account. Klaviyo support said it's a known issue that they're working on called "List Bombing", but basically Klaviyo is picking up all these email addresses that aren't getting added to lists. They're all hotmail addresses formatted as FirstNameMiddleInitialLastName @ hotmail.com. It just seems weird to have all this bot activity happening from Shopify all at once. 

[Paul_West]

Just FWIW we are I think on the newer one page checkout and dont do any customization of the checkout I don't think customization is even possible unless you're paying a higher monthly plan which we're not. We have no checkout apps.

[JohnTucker]

Hey all- Sorry to get so quiet on this issue. Call me crazy, but I felt like I was noticing that as we posted updates here, the events were evolving to address each of our methods of isolating them. For example a couple days after we posted that the Purchase events did not include a Transaction ID and that they were taking place on /checkouts/cn/ pages, purchase events started coming through with a prefix of "T_" and taking place on the /thank-you/ page, so I thought it best to stop feeding whoever/ whatever ammunition on how to evolve to better spoof events. Again- I may be over thinking it and being crazy, but I didn't want to mess with it any further. It does seem like the events have died down as of August 23rd for us. Not sure how anyone else is faring at the moment.

In picking up the pieces and moving forward, I've been working on ways to remove the events in Looker Studio so that I can use our month of August for reporting in any meaningful way and it is proving to be a bit of a challenge. Any input is appreciated that you might have had success with would be appreciated. I've been able to isolate the count of real transactions and revenue for our sites in Looker Studio, but need to isolate these events to remove them from other metrics like Sessions and Users since each rogue purchase was essentially +1 user and session. I'll post any of my methods I devise here once I can verify that they're working, too.

[fsualum]

Hey, I agree with that a bit.  I did notice the transaction numbers before it was posted here.  I have noticed it stopping for more than a week as well.  I am filtering it out in my reporting and have directed our users to be careful with standard reports and we mostly use Shopify now.  Feel to PM me if there are any questions as to how to filter it out of reporting...you can't filter the events.

[Helixian]

I wanted to add some additional context I didn't see mentioned yet to the thread.  While troubleshooting this exact issue with a number of our clients, we did some testing by creating a new GA4 property and simultaneously sending events to the old GA4 property (with the billions of revenue issue) and the new one we've just created.  The new GA4 property has never experienced the reporting issues, while the old property has had periods of time where reporting seems accurate, followed by days or weeks of incorrect reporting again.  The most recent incorrect reporting that we were seeing was on August 23rd, hoping it doesn't come back.

This is to say, it seems the issue is not always impacting our client stores, but when it does, obviously their reporting is skewed into the billions.  The new property, which is collecting data in exactly the same way (Shopify web pixels, only difference is property ID), has never experienced the issue.

This really feels to me like a security issue with checkout extensibility.  I would love to get a more detailed technical response from Shopify on this.