Massive Chinese Bot Traffic Is Corrupting Shopify Analytics, Ad Attribution, and Paid Tools (Plus Merchants Affected)

I’m starting this thread to consolidate what is clearly a systemic issue affecting many Shopify merchants, including Shopify Plus stores, and to move the conversation beyond deflection and into actual mitigation.

Over the past several days, I’ve been doing deep analysis on traffic hitting my Shopify Plus store. The results are not subtle.

Roughly 50% of all sessions over recent days are bot traffic originating from China. Not sporadic. Not spikes. Sustained, automated traffic at scale.

This is not theoretical. It is measurable, repeatable, and materially damaging.

What this traffic looks like in practice

  1. Geography and volume
    Live analytics show thousands of daily sessions from China. This is traffic we do not market to, do not ship to, and do not have any legitimate customer base in. Many other merchants report the same pattern.

  2. URL structure strongly indicates scraping
    Bots are not just requesting clean product URLs. They are hitting product pages with stacked recommendation parameters that mimic internal Shopify recommendation flows.

Example pattern (real traffic):

/products/[product-handle]?pr_prod_strat=e5_desc&pr_rec_id=XXXX&pr_rec_pid=XXXXXXXXXXXX&pr_ref_pid=XXXXXXXXXXXX&pr_seq=uniform

Humans do not land on product pages this way. These parameters are normally injected by Shopify recommendation logic during in-session navigation. Bots are replaying or permuting these parameters to force distinct URLs, which explodes session counts and corrupts analytics.

  1. Analytics and marketing damage
    This traffic is not just “noise.”

It directly affects:

  • Shopify Analytics (sessions, conversion rate, funnels)

  • Facebook and Google pixels (false page views, polluted audiences)

  • Paid analytics tools like Matomo (which bill based on hits and sessions)

  • Internal monitoring and alerting systems

Filtering bots out of reports after the fact does not solve this. The damage is already done by the time the request hits the store.

  1. IP evidence
    We are seeing traffic from Chinese IP ranges such as 202.46.0.0/16 and similar blocks. These are not isolated IPs. They are ranges associated with data centers and automated activity. Merchants cannot block these at the edge because Shopify controls the CDN, WAF, and routing layer.

This is not an isolated complaint

There are already multiple Shopify Community threads describing the same issue:

In these threads, merchants consistently report:

  • Unusable analytics

  • Inflated session counts

  • Broken attribution

  • No effective platform-level mitigation

The common response from support is to recommend analytics filters or third-party apps. That does not address the root problem.

Why this is a Shopify platform issue

Merchants do not control:

  • The CDN

  • The WAF

  • IP filtering

  • Country-level blocking

  • Edge-level bot challenges

Only Shopify can mitigate this at the correct layer.

For Shopify Plus merchants in particular, the expectation is not perfection, but active platform-level mitigation when a systemic issue is clearly impacting merchant operations.

This traffic is being served HTML. It is executing pixels. It is triggering paid analytics. That means it is not being meaningfully challenged or blocked at the edge.

Public escalation

I have escalated this publicly because private support channels continue to frame this as either unavoidable or out of scope.

I have posted detailed threads on X directed to Tobi Lutke, documenting the issue, linking to community threads, and explaining the technical impact:

These are long, technical threads intended to marshal the right internal attention, not to sensationalize the issue.

Historically, when platform-level problems stall in support, this has been the only reliable way to get infrastructure and network teams involved.

What merchants are asking for

This is not a request for perfection or total bot elimination. It is a request for basic, reasonable platform defenses, such as:

  • Edge-level throttling or challenge rules for known scraping patterns

  • Detection of abusive parameter permutations

  • IP and ASN-based heuristics applied globally

  • Meaningful Plus escalation paths when traffic clearly degrades analytics and paid tooling

Analytics filters are not a solution. Apps that run after HTML is served are not a solution.

Why this matters

For many merchants, analytics integrity is not a “nice to have.” It directly informs ad spend, inventory planning, conversion optimization, and forecasting.

When half of traffic is fake, every downstream decision becomes unreliable.

This is already costing merchants real money.

Closing

I’m adding this post to centralize discussion and evidence so that Shopify cannot treat this as isolated merchant frustration.

If you are seeing similar patterns, please add:

  • Approximate percentage of bot traffic

  • Regions involved

  • Impacted tools (Shopify Analytics, Meta, Google, Matomo, etc.)

  • Whether you are on Plus

This needs to be addressed at the platform level.

Hi Jamie,

Thanks for your post on this - I wanted to also confirm we’re seeing the exact same issues on ‘regular’ Shopify and have been seeing these issues for the last 12 months or so, but they’ve significantly ramped up this December.

We’re now seeing c. 70% of our total daily traffic coming from ‘Direct’ from countries outside the UAE, which is where we operate and our busibness is located and where we market and deliver to.

We saw some aggressive spikes in ‘Direct’ traffic from China on the 4th, 9th and 16th of December, but since the 24th of December, we’ve seen daily ‘direct’ traffic inncrease and become stable from China, Unitied States, United Kingdom, Netherlands and Germany. This is 100% bot traffic and not genuine consumers, as we do zero marketing in these markets and even if we did, it would not transpire overnight into 1000s of daily ‘direct’ visits. As you said, quite apart from the annoyance of our analytics being completely skewed, this has bigger issues from a perfomance and broader marketing signal perspective. I also suspect it’s negatively impacting our SEO, as whilst ‘bounce-rate’ is not officially taken into account, 100% Google sees the signals from your own analytics and will take some inference from user engagement (or lack of), inferring some issue with your site.

The lack of controls within Shopify on this are extremely frustrating and I agree that country or IP filters on analytics are a completely moot point - we need the ability to either profile and add exclusions to this traffic ourselves or ideally Shopify should be the ones doing this - it’s clearly low quality, spam traffic and plainly obvsious in Google Analytics, so I can’t imagine it’s difficult for Shopify to identify this at a WAF/CDN level and exclude it on sight.

Would love to share more directly with you on this.

Thanks
Rob

Hello,

I’m adding myself to the list of stores affected by this scourge.

90% of my traffic comes from China, where I don’t sell, don’t ship, and don’t advertise.

I’m in France.

I’ve written to support several times, and they systematically dodge the issue by offering a paid solution that is, on top of that, ineffective.

Every month, I get the impression that this traffic doubles.

My hypothesis is the following:

Companies like TEMU use price comparison tools (to force their sellers to align prices) and probably scrape our stores.

But Amazon does the same thing, and I’ve never seen them attack stores so aggressively…

At a time when ecology is supposedly a real concern for large companies like Shopify, allowing stores to be bombarded with requests seems completely absurd.

We’re bordering on complicity here — because if it didn’t suit them, this problem could have been solved a long time ago.

Further update to this - I’ve just discovered a load of ‘John Doe’ First Name and Last Name records in our Klaviyo account, which are all using emails that are not subscribed to marketing and they all coincide with the bot traffic over the last few days, so I don’t know how they’re injecting emails into Klaviyo, but this is clearly bot traffic!

John Doe is a fraudulent credit card testing bot, Ive been dealing with it for months

Thanks @dingle-larry

Any advice on how to deal with it? This is 100% related to the bot traffic I’ve posted about hitting our site, so now it’s not just an analytics issue, but a fraud issue, so Shopify really should be doing something proactive to block this traffic!

@Jamie_Grove @Comptoir - FYI

The only update I’ve had so far from Shopify is that they’ve acknowledged the problem but said it isn’t a problem because they don’t prevent scraping. :slight_smile:

For the last 10 days I’ve been running my own homebrew blocker. I built it with Claude Code as a test and it works ok. it could be way smarter but Shopify does not expose enough information on the request object (so easy to do - why not?!)

Anyway, here is the code I dropped into our theme.liquid file. It wraps the regular content and there are a few flags inside for customization.

{%- comment -%}

================================================================================

BOT MITIGATION SCRIPT v1.2

================================================================================

Place at the VERY TOP of theme.liquid, before <!doctype html>




PURPOSE:

  Blocks automated scraping traffic that abuses Shopify's product recommendation

  system. These bots crawl recommendation URLs with stacked pr_* parameters,

  polluting analytics, wasting render cycles, and corrupting pixel data.




DETECTION STRATEGY:

  1. Primary: Detect all 5 pr_* recommendation parameters (catches ~70% of bots)

  2. Secondary: Detect China geo + any pr_* parameter (catches adapting bots)

  3. Aggressive: Detect China geo + content pages (product, collection, page, blog, article, search)

     - Allows: homepage, /pages/about-us, cart, customers, gift_card




CONFIGURATION:

  - botkiller_enabled: Master on/off switch

  - botkiller_aggressive: Enable/disable China product page blocking




NOTE ON LIMITATIONS:

  - request.user_agent returns empty in Shopify Liquid - UA detection not possible

  - IP addresses not exposed - must rely on Shopify's geo detection

  - Browser Accept-Language not exposed - localization.language is store-config only




AUTHOR: Mini Museum / Claude Code

DATE: 2025-12-28

UPDATED: 2025-12-28

================================================================================

{%- endcomment -%}




{%- liquid

  # ============================================================================

  # CONFIGURATION

  # ============================================================================




assign botkiller_version = "1.2.0"

assign botkiller_enabled = true




  # AGGRESSIVE MODE: Block China visitors on product pages

  # This catches bots that have adapted to avoid pr_* parameters.

  # Risk: May block legitimate Chinese customers viewing products.

  # They'll see a message with your contact email.

  # Set to false if you get customer complaints.

assign botkiller_aggressive = true




  # ============================================================================

  # EARLY EXIT IF DISABLED

  # ============================================================================




unless botkiller_enabled

break

endunless




  # ============================================================================

  # GATHER REQUEST DATA

  # ============================================================================

  # Note: Shopify Liquid doesn't expose query strings directly via request.*

  # but content_for_header contains the full URL including query params.

  #

  # request.user_agent returns empty - we cannot detect User-Agent in Liquid.

  # localization.country.iso_code gives us geo-detected country.




assign bk_cfh = content_for_header | downcase

assign bk_country = localization.country.iso_code | default: ""




  # ============================================================================

  # DETECTION: RECOMMENDATION PARAMETER ABUSE

  # ============================================================================

  # Shopify's recommendation engine uses these parameters. Bots systematically

  # crawl URLs with ALL parameters to scrape the entire product catalog.




assign bk_has_pr_stack = false




if bk_cfh contains "pr_prod_strat="

if bk_cfh contains "pr_rec_id="

if bk_cfh contains "pr_rec_pid="

if bk_cfh contains "pr_ref_pid="

if bk_cfh contains "pr_seq="

assign bk_has_pr_stack = true

endif

endif

endif

endif

endif




  # ============================================================================

  # DETECTION: PARTIAL PR PARAMS (for geo-combo detection)

  # ============================================================================




assign bk_has_any_pr = false

if bk_cfh contains "pr_prod_strat=" or bk_cfh contains "pr_rec_id=" or bk_cfh contains "pr_rec_pid=" or bk_cfh contains "pr_ref_pid=" or bk_cfh contains "pr_seq="

assign bk_has_any_pr = true

endif




  # ============================================================================

  # DETECTION: CHINA GEO + PR PARAMS

  # ============================================================================

  # Bots from China hitting recommendation URLs. Legitimate Chinese customers

  # browse normally and don't arrive via recommendation parameter links.




assign bk_china_with_pr = false

if bk_country == "CN" and bk_has_any_pr

assign bk_china_with_pr = true

endif




  # ============================================================================

  # DETECTION: CHINA GEO + CONTENT PAGES (Aggressive Mode)

  # ============================================================================

  # Bots have adapted to hit pages directly without pr_* params.

  # This blocks China traffic to most content pages.

  # Risk: False positives for legitimate Chinese customers.

  #

  # ALLOWED (not blocked):

  #   - index (homepage)

  #   - /pages/about-us (support/contact info)

  #   - cart, customers, gift_card, password, 404

  #

  # BLOCKED:

  #   - product, collection, page (except about-us)

  #   - blog, article, list-collections, search




assign bk_china_content = false

if botkiller_aggressive

if bk_country == "CN"

if request.page_type == "product"

assign bk_china_content = true

elsif request.page_type == "collection"

assign bk_china_content = true

elsif request.page_type == "list-collections"

assign bk_china_content = true

elsif request.page_type == "page"

unless request.path == "/pages/about-us"

assign bk_china_content = true

endunless

elsif request.page_type == "blog"

assign bk_china_content = true

elsif request.page_type == "article"

assign bk_china_content = true

elsif request.page_type == "search"

assign bk_china_content = true

endif

endif

endif




  # ============================================================================

  # BLOCK DECISION

  # ============================================================================




assign bk_should_block = false

assign bk_block_reason = ""




if bk_has_pr_stack

assign bk_should_block = true

assign bk_block_reason = "pr_stack"

elsif bk_china_with_pr

assign bk_should_block = true

assign bk_block_reason = "cn_pr"

elsif bk_china_content

assign bk_should_block = true

assign bk_block_reason = "cn_content"

endif

-%}




{%- if bk_should_block -%}

{%- layout none -%}

blocked:{{ bk_block_reason }} If you believe this is an error, please visit YOURSITE or email CUSTOMERSERVICEEMAIL

{%- else -%}

{%- comment -%}

================================================================================

YOUR NORMAL THEME.LIQUID CONTENT GOES HERE




Paste everything from your original theme.liquid below this comment.

The entire normal theme is wrapped in this {%- else -%} block so it

only renders when the request is NOT blocked.




START: Original theme.liquid content

================================================================================

{%- endcomment -%}

<!– THIS IS WHERE YOUR REGULAR theme.liquid goes –>

{%- comment -%}

================================================================================

END: Original theme.liquid content

================================================================================

{%- endcomment -%}

{%- endif -%}

try shopify fraud controll app with a rule to block checkout with JD emails

The JD bot is using about 700+ emails and i have them all blocked. unfortunately new emails are being used every few days so im always having to update the rules list.

And using flow.

1 Customer created

2 Condition - customer.displayName - is at least one of: John Doe

3 Delete customer

Unfortunately this homebrew blocker would not work as you expect for a number of reasons.

pr_ URL parameters are used to train recommended products engine and has no relation to bots. When someone clicks product card on the “recommended products” section, they follow this kind of link.

localization.country.iso_code is not a geolocation, but the country selected from your market/language/currency menu.
Shopify does provide some geolocation data, but it’s via JS API, not in liquid code.

Shopify does not provide more request data in Liquid because of the server-side cache to make your site faster.
Re-rendering your pages for each request will make it significantly slower.

Finally, bots do not need to interact with your theme at all.

There is a number of APIs which allow anyone to get a list of your products, select the cheapest ones and add them to cart/checkout without ever interacting with your theme code.

These APIs can not be disabled because they are needed for your store to function.

Hi, Tim.

Thanks so much for the reply.

I’m actually aware of all the limitations you mentioned. I built this script with the idea of what it should block. However, there are only a few things in here that actually work since Shopify’s request object is so woefully nerfed. I should have those out or at least commented them accordingly. Glad you read it though! :smiley:

Important point: This script is only out there to help me fix my stats (Shopify, Matomo, GA, and Meta) since that’s literally all we can do at this layer. Even that is a kludge at best though…

On the pr params, what I noticed in the logs is that the bots were using them in a specific way that was different from normal user traffic. I assume they just cached some hard links and patterns and then kept using them over and over, adapting them to other products. Blocking this pattern alone killed off +60% of the traffic. The other patterns that actually worked (/products, /collections) were added step by step while looking at bot traffic live through Matomo.

On localization.country.iso_code, I tested this extensively with curl from different geolocations. It returns “US” for US IPs, “CN” for Chinese IPs, etc. Yes, it’s also used for market selection, but apparently it does reflect Shopify’s geo-detection even if the documentation says otherwise. I’d be really interested to know if it isn’t working like that for other people.

That said, the API endpoints are also a great observation. Thanks for that because it’s going into my next round of business posts about Shopify on social media. Shopify actually needs to deal with this at the network edge layer. Without it, crazy homebrew solutions like mine or even paid apps are just masking an ongoing problem.

Jamie

P.S. If anyone is interested, I can put a more refined version of this script out that documents this info inline.

Ah, yes, you’re right about tracking pixels – if you do not render the page, they will not fire.

As for the localization and geolocation – it may happen if you have automatic redirection setup in Online Store=> Preferences: Automatic redirection.

Isn’t Klaviyo charge per customer profile for some services?
Then it’s a source of profit for them, not hit.

Maybe Klaviyo is behind these bot attacks? :slight_smile:

Yes Klaviyo charges on ‘Active Profiles’, which basically means any user you’ve sent an email to within the billing month, which is why this is such an issue.

At the moment, I’ve created a segment in Klaviyo and I’m supressing the profiles on a daily basis, but this is a real cost impact now. As I mentioned in my original response, this is 100% related to the timing of the bot traffic on Shopify and they’re all entereing Klaviyo with a unsubscribed marketing status, so it’s not our email form, as that’s auto opt in. As others have mentioned, I suspect this is due to the bots trying to enter these details in the checkout form, which is why the users’ email address are not opted into marketing.

Any advice on how to block these from entering Klaviyo in the first place? (Outside of Shopify actually bothering to address spam traffic?).

SEARCH first, use existing threads https://community.shopify.com/search?q=bots

All threads like this do is create more fragmentation, and make it harder to have a collective voice :roll_eyes: .
Join and contribute to existing topics <https://community.shopify.com/search?q=bots>
THEN crosslink to such posts upfront, don’t bury the lede(the cross links) when trying to “consolidate”.

Otherwise all your doing is yelling at clouds in tiny little diasporas making yourselves ignorable and forgettable.

Pretty sure that post was satire.
Even if it is, there’s always a possibility it has a point about a possible type of abuse that should be treated as a variable.
Ex: if platform X has revshare Y and bad actor 1 gets revshare Y from merchant A’s billing.
Then it is in bad actor 1’s interest to increase traffic.

There are either commonalities, variables, that can be detected and acted against or there aren’t.

@chlara68 No one is suggesting this is anything to do with Klaviyo. I was simply adding additional context that we’ve started to see ‘John Doe’ records being created in Klaviyo, at the same time we’ve seen bot traffic increase on our site, so my point was simply to reinforce the fact it is clearly bot traffic, which we can see further evidence of as it’s now impacting Klaviyo too as an indirect impact of the bot traffic to our Shopify store.

You’re absolutely correct, but this is the only thread I found specifically calling out this issue and I was hoping more people would post similar issues they’re facing here, so we can amass some broader evidence.

That would be true if I were trying to be part of the collective voice, but I’m not. The consolidation is a public place I can reference during higher level conversations with the company. Trust me, Paul. This is not yelling at clouds. Unlike 99% of rant threads in this forum, my post has actually been received.

Hello everyone,

I am based in Portugal and have been experiencing a significant spike in bot-generated traffic starting around November 1st, 2025.
The abnormal sessions initially originated from China, but have since expanded to include traffic from China, Japan, Singapore, Brazil, and the USA.

Below are the GA4 metrics that clearly indicate non-human, automated traffic:

China — 60,869 sessions (≈70% of total traffic)

  • Bounce rate: 99.5%

  • Average session duration: 0.35 seconds

  • Conversions: 0

  • Behavior fully consistent with high‑volume bot activity

Japan — 2,313 sessions

  • Bounce rate: 98.7%

  • Average duration: 2.6 seconds

  • Conversions: 0

Singapore — 1,294 sessions

  • Bounce rate: 99.8%

  • Average duration: 0.55 seconds

  • Conversions: 0

Brazil — 4,355 sessions

  • Bounce rate: 95.4%

  • Average duration: 8.2 seconds

  • Conversions: 0

USA — 2,088 sessions

  • Bounce rate: 92.9%

  • Average duration: 7.5 seconds

  • Conversions: 0

I do not sell to these markets, nor do I offer shipping options to any of these countries in Shopify, which makes this traffic clearly unrelated to legitimate users.

I am sharing this data so others can compare patterns, and I will continue to monitor the situation while awaiting an official fix or mitigation guidance for this type of bot traffic.

Thanks for sharing @Rufy_78 - we continue to face this problem on a daily basis. As I mentioned, I’m havinv to supress contacts with the First Name ‘John’ and Last Name ‘Doe’ on a daily basis, as an indirect impact of the bot traffic we’re receiving to our site.