Extreme add to carts and checkout sessions

AI-generated summary

A Shopify merchant is experiencing extreme automated-looking add-to-cart, checkout, begin_checkout, and add_shipping_info activity across multiple stores, with thousands of events per hour and distorted analytics. Shopify support confirmed that real human checkout activity appears normal in a filtered report, while the abnormal sessions are being classified separately as automated traffic; abandoned checkouts did not show a corresponding spike.

The merchant previously tried Cloudflare and custom blocking rules. Some suspicious search traffic was blocked, but legitimate sales appeared to drop, so the domain was moved back to Shopify DNS; real orders resumed, but fake cart/checkout events continued.

Key advice focused on distinguishing actual storefront objects from tracking noise: compare Shopify sessions, real carts/checkouts, GA4 events, Meta events, referrers, countries, landing pages, and Shopify’s “Human or bot session” filter. Others warned against broad Cloudflare bot blocking because it can block real customers.

No final technical solution was reached. Suggested next steps include using human-session filtering for reporting, segmenting GA4, checking ad-platform optimization signals, and escalating with evidence if the same bot pattern appears across all stores.

I have a shopify store and have been running fine for years

Since last 1 month I have been fighting to know what is causing enormous amount of add to carts like 1000s every hour and same with checkout page visits and same with Event name begin_checkout and add_shipping_info events

I dont understand how and why is this happening

I joined cloud flare in order to monitor traffic as when this all started there were a lot of people accessing search page in 1000s and now its add to carts and checkouts events in excessive I am sure this is some one trying to mess up what should I do as cloud flare when I switched my domain to cloudflare things actually got messed up as blocking bots was also blocking many customers it was a total mess with cloud flare so I moved back my domain and how after 10 days I have this issue of add to carts and checkouts any help will be much appreciated some one who has resolved this kind of issue please if you can step out to help please.

Looking forward to it.

Hello @MBHK

Before you blame a bot, check where the sessions are coming from. In Shopify admin, open Analytics > Reports and look at sessions by referrer and by country. If the spike is one country, one referrer, or a flood of checkouts with no orders behind them, it’s almost certainly bot traffic and not shoppers. In GA4, check add_to_cart and begin_checkout by traffic source and city for the same pattern.

Also check whether the events are firing twice. A second tracking setup (an app plus a GTM tag, say) that both send begin_checkout will inflate the numbers with no extra traffic at all.

Once you know which it is, block that source with a narrow Cloudflare rule so real customers don’t get caught again.

If this helped, please mark it a solution :slight_smile:

On Cloudflare: it likely failed for a documented reason, and it’s still the right layer if set up differently.

If you switched on the free Bot Fight Mode, that alone explains the burned customers — and note you won’t find Super Bot Fight Mode on a Free zone, it’s a paid-plan feature. Cloudflare’s docs describe the free toggle as single, domain-wide, with no tuning — and critically, no WAF rule can exempt traffic from it; Skip and Allow actions have no effect on it. So the moment it misclassified real visitors — which Cloudflare openly admits happens: “legitimate human traffic incorrectly challenged or blocked” — your only move was turning the whole thing off. A full domain move adds more foot-guns: Flexible SSL breaks checkout, “Always Use HTTPS” silently breaks Shopify’s certificate renewal weeks later, Rocket Loader breaks theme JavaScript.

Done right, it’s the one layer that stops what apps can’t: requests blocked at the edge never reach Shopify. The documented setup is Orange-to-Orange — a proxied CNAME to shops.myshopify.com instead of moving the domain over — SSL mode Full (never Flexible), “Always Use HTTPS” off (Shopify renews certs over plain HTTP; redirecting that path kills renewal), no HTML caching and no Rocket Loader on your zone. For enforcement, the tools on O2O’s confirmed-compatible list are WAF custom rules and rate limiting: narrow rules on /cart/* and /checkouts/* (challenge or block the offending country/ASN, rate-limit the cart endpoints), product pages untouched.

One caution from Cloudflare’s own table: rules matching the O2O hostname “may block or interfere” with visitors — and the bot-specific toggles aren’t on the confirmed list at all — so after setup, check Security → Events actually shows the rules engaging before trusting them, and its recommended to get a developer to do all of this.

Two honest caveats: Shopify officially doesn’t support proxy setups (their support will ask you to turn it off first), and edge relief can be temporary — bots adapt, so should your rules.

If you’d rather not touch DNS: the app route

Full disclosure: we built Filtrex for exactly this kind of problem. It checks every storefront visit and logs what it found and why — start with zero blocking rules and it’s pure observation, nothing blocked, everything recorded; then add rules targeting only what your own data shows is junk. With Pixel Firewall on, a blocked visitor’s pixels never fire either, including Shopify’s own, so blocked bots stop being counted too.

One platform limit: a bot that goes straight to checkout without loading a storefront page can’t be stopped by any app, including ours.

We’re taking on 10 stores for a beta - with lifetime Premium free (normally $19.99/month): we go through your traffic with you, help you target only the bot traffic, and what we learn goes into the app. Details and join here: beta thread

Before changing DNS or putting Cloudflare back in front of the store, I would first figure out whether you’re dealing with actual automated requests or an analytics/tracking problem.

Where exactly are you seeing these thousands of add-to-cart and checkout events?

If Shopify Analytics itself is showing thousands of checkout sessions/add-to-carts while your actual orders remain normal, then bot/automated traffic becomes much more likely.

But if Shopify looks relatively normal and you’re primarily seeing “begin_checkout”, “add_shipping_info”, etc. exploding in GA4, I would check your pixels, GTM setup, apps, and any recent theme changes first. A duplicate or incorrectly firing event can make the numbers look like massive bot activity when the underlying Shopify activity isn’t actually happening at that volume.

The fact that you previously saw thousands of requests hitting search does make automated traffic worth investigating, but I wouldn’t assume the GA4 event counts alone prove it.

I also wouldn’t turn broad Cloudflare bot blocking back on until you know what you’re trying to block. As you’ve already experienced, broad rules can catch legitimate customers too.

First thing I’d compare is:

Shopify’s actual add-to-cart/checkout activity vs. GA4’s event counts.

If those numbers are wildly different, that’s a very useful clue.

thank you for your response.

i got in touch with shopify too and they also checked and there response is below which also confirms that this bots adding to cart is happening but shopify says they are handling it but the problem i have is that this is completely messing up our records for analytics, the data is unanimous between shopify analytics and google analytics

Hey , thanks for your patience! I’ve had a good look through your analytics now and I have some reassuring news.

When I filter your checkout conversion report by session type, here’s what it shows for the last 30 days: 619 sessions from real human visitors reached checkout, with 4 completed purchases. That’s a normal, healthy picture for your store. The sessions with no completed checkouts are being classified separately as automated traffic by Shopify, and they showcompleted checkouts, exactly as you’d expect.

So the short version is: Shopify is already identifying and separating that automated traffic from your real customer data. It’s not slipping through undetected, and it’s not blocking real shoppers from buying.

The spike you saw in your Sidekick data is real in the sense that automated sessions did hit your cart and checkout pages, but Shopify’s built-in Cloudflare protection and bot detection are doing their job. There’s nothing broken and no further action needed on your end.

I also checked your abandoned checkouts, and there’s no spike there either. The most recent entries are from real customers in the usual regions, with normal cart values. Automated traffic typically doesn’t leave abandoned checkout records, so that lines up with what the analytics are showing. Everything looks consistent and as expected on your store.

Message for every one in response to the answers i have recieved which i really appreciate all the help.

The setup was done correctly. The DNS, CNAME records and everything else were configured properly and the website was working fine in cloudflare but now we are no longer on cloudflare just to clarify..

After that, I manually enabled additional blocking/security rules because I wanted to test how much of this suspicious traffic could actually be stopped. A significant amount of traffic was successfully blocked, particularly through the search endpoints, but at the same time a large number of suspicious visits were still getting through.

The important point is that just because traffic was still appearing through the search endpoints does not mean nothing was being blocked. A lot of requests were being blocked, but many others were still passing through.

Today the situation became significantly worse. No matter what Cloudflare settings or security rules I tried, the abnormal traffic would not stop. At the same time, our sales completely dropped. This website normally receives orders every day, so seeing this amount of activity while having virtually no genuine sales was extremely concerning.

Eventually, I decided to move the domain back to Shopify’s own DNS. Shortly after doing this, genuine orders started coming through again. However, the abnormal cart and checkout activity is still continuing, with numerous visits and events being recorded.

This is the actual problem I am trying to resolve.

I understand that everyone commenting here is trying to help, and I appreciate the responses, but most of the suggestions so far are focused on identifying whether the traffic is bot traffic or genuine customer traffic. That is useful as a first step, but that part has already effectively been identified.

Shopify Analytics is recording the abnormal activity. Google Analytics is also showing the abnormal activity. Our live chat analytics and monitoring tools are showing the same thing. We monitor customers entering the website, adding products to cart and reaching checkout, and we also use live chat to engage with customers. The behaviour we are seeing is clearly not normal customer behaviour.

So this is not simply a case of relying on one Shopify report.

The bigger issue is that all of this artificial activity is completely destroying the accuracy of our analytics. When there are hundreds or thousands of fake sessions, cart additions and checkout events mixed together with genuine customers, it becomes extremely difficult to identify actual customer behaviour, genuine conversion rates, abandoned carts and the real performance of the website.

Shopify says that its infrastructure already uses Cloudflare and that bot traffic is regularly blocked. However, clearly a substantial amount of automated traffic is still reaching the storefront and triggering customer actions such as add-to-cart and checkout events.

What I am looking for now is not another explanation of how to identify bot traffic. I am looking for an actual technical solution to stop, rate-limit or isolate this activity before it contaminates the storefront analytics.

I have four websites, and although this particular website is currently my main and highest-volume store, I am seeing similar behaviour across the others as well.

This is becoming a serious issue. Shopify merchants should not have to accept massively distorted analytics, fake cart activity and fake checkout activity without having an effective way of controlling it.

I am not on Shopify’s lowest plan, nor am I on Shopify Plus. I am on a mid-level Shopify plan, and I would expect there to be some practical protection or escalation route available for this type of problem.

If anyone has dealt with this exact issue and has found a genuine solution — particularly something that stops the automated add-to-cart and checkout activity rather than simply identifying it afterwards — I would really appreciate hearing what worked.

i have installed it and since than its started showing abandones carts and checkouts but when i click on them to see there is no data there to see what the abandoned cart and checkouts are for or the specifics its the main screen data only which i am getting.

This really does sound like automated traffic, especially if you’re seeing thousands of add-to-carts and checkout events per hour without anything remotely comparable in actual orders.

Before putting Cloudflare back in front of the store, I’d do some digging in Shopify itself. Shopify recently added better bot identification to Analytics. Go into Analytics > Reports and look for the Human or bot session dimension/filter. See whether Shopify is identifying any of this traffic as bots, and then start breaking it down by things like landing page, country, device, referrer, etc.

I’d also compare the numbers carefully. If you have 5,000 add-to-cart events but only a relatively small number of actual sessions/customers, that tells you something very different from suddenly having 5,000 additional visitors. Likewise, see whether actual abandoned checkouts are being created or whether you’re primarily seeing analytics events such as add_to_cart, begin_checkout and add_shipping_info.

I wouldn’t assume somebody is specifically trying to attack your store yet. Bots can hammer search, cart and checkout endpoints for a lot of reasons, and the fact that they moved from search activity to cart/checkout activity doesn’t necessarily mean somebody is personally targeting you.

I’d also be cautious about putting aggressive Cloudflare blocking rules back in place. Shopify already sits behind Cloudflare and has its own bot/DDoS protections. If your previous Cloudflare setup started blocking legitimate customers, you can easily cause yourself more damage trying to stop the bots than the bot traffic itself is causing.

The first thing I’d want to establish is:

Are these thousands of events coming from thousands of sessions, or is a much smaller number of automated sessions generating huge numbers of events?

And are you seeing thousands of actual Shopify carts/checkouts being created, or primarily thousands of analytics events?

Those answers would narrow this down considerably before you start blocking anything.

One angle that hasn’t come up yet, since your real orders look normal: are you running Meta or Google ads that optimize for Add to Cart or Initiate Checkout, or use them as conversion events?

If these bot sessions load your storefront, your pixels fire for them too, so the ad platforms are getting thousands of fake “high-intent” signals. That’s the part that can actually cost money, not just mess up your reports. Quick check: in Meta Events Manager, compare daily AddToCart / InitiateCheckout counts with the spike you see in Shopify. If they follow the same curve, I’d switch campaign optimization to Purchase until this is under control.

@MBHK One thing I’d try before changing more settings is to separate “bot traffic” from “bot-generated ecommerce events.”

For a short controlled window, compare:

  • Shopify sessions
  • actual carts / checkouts created
  • GA4 add_to_cart / begin_checkout
  • Meta checkout events

If you’re seeing thousands of analytics events but only a small number of actual carts/checkouts being created, the problem is probably happening in the tracking layer rather than in the storefront itself.

If the cart/checkout objects themselves are also being created at the same scale, then you’re dealing with a different problem and blocking/filtering becomes much more relevant.

I wouldn’t change Cloudflare or tracking yet until you know which of those two is happening.

Do the spikes in GA4 line up with actual checkouts being created in Shopify, or are the Shopify checkout numbers much lower?

@MBHK one number in the Shopify support reply is worth a second look before you decide how much of this is noise: 619 human sessions reached checkout and only 4 completed. If that was measured over the full 30 days, it includes the stretch where Cloudflare was challenging real customers and your sales dropped, so the figure is probably dragged down by that window. Re-run the same checkout conversion report with the Human session filter, only for the period after you moved DNS back, and compare it with a month from before this started. If human checkout-to-order rate is back to normal there, your real funnel is fine and this is a reporting problem. If it is still low, the bot volume is hiding a genuine conversion drop, and that deserves its own investigation.

For keeping the noise out of your decisions while you work on an edge fix:

1. In Shopify, make the Human session filter your default view for funnel reports, and judge the store on orders, revenue and human checkout completion rate, not on raw add-to-cart or begin_checkout counts.

2. In GA4, add annotations for the date the spike started and the dates you moved DNS in and out, then build an Exploration segment that drops sessions with zero engagement time and break the funnel down by country and landing page. GA4 cannot be cleaned retroactively, so you want a repeatable segment rather than a one-off cleanup.

3. Check your other three stores for the same landing pages, countries and timing. If the pattern is identical, it is one scraper hitting all of them, and that comparison is strong evidence if you escalate to Shopify support again.