How a Tracking Migration Uncovered Bot Traffic Across Shopify Stores

An ETA view is what we record each time a shopper sees a delivery estimate on a product page — it’s how we measure whether ArrivesBy is actually being shown, and it feeds into the usage stats merchants see in their dashboard.

A few weeks ago we changed the way we track them.

Previously, we relied on a browser-side beacon — a small signal that fires when a shopper’s browser loads a delivery estimate. We moved to a server-side signal instead, tied directly to the ETA request itself. More reliable, simpler to reason about.

It was a routine infrastructure change. But when we started comparing the old numbers against the new ones, something was off.

---

The numbers didn’t match

For most stores, the two systems agreed within a few percent of each other. That’s expected — no two tracking methods are perfectly identical, and browser beacons occasionally get dropped on slow connections or quick page navigations.

But for a small group of stores, the new server-side counter was running 2x, 5x, even 8x higher than the old browser-side one.

That kind of gap doesn’t come from dropped beacons. The math on both sides checked out; bugs weren’t the explanation. This didn’t look like shopper traffic — these ETA requests were coming from something else.

---

Diving deeper

We pulled the raw request logs for the most affected stores.

The pattern was immediately strange. Traffic was coming in around the clock — flat and steady, even at 3am UTC. Real shopping traffic has shape to it: it spikes during evenings, drops overnight, picks up on weekends. This had none of that. Just a constant, even drumbeat of product page requests.

And it was thorough. Hundreds of distinct product variants, visited one by one. Every combination. No purchases, no cart additions, no checkout. Just methodical product page views, over and over.

---

What it actually was

ArrivesBy already does basic bot filtering. The major crawlers — Google, Bing, SEMrush, Ahrefs — announce themselves in their user agent strings, and those get filtered out. This traffic looked nothing like that.

The requests carried clean Chrome browser fingerprints with realistic headers, including the browser hints that modern Chrome sends. Nothing in the user agent raised a flag, and Cloudflare’s bot scoring gave them a clean bill of health.

What gave it away was that these requests were hitting the ETA endpoint directly, without executing JavaScript. A real shopper’s browser runs the JavaScript, fetches the ETA, and fires the beacon. These requests fetched the ETA but never triggered the beacon — because there was no browser. That asymmetry is the only reason we caught it. We happened to be running two independent counters at once, and they disagreed.

There was one more signal: every inflating request had a referrer containing Shopify’s product recommendation parameters — the kind of URL that only appears when you navigate via “you might also like” links. This wasn’t random crawling. It was using Shopify’s own recommendation graph to traverse stores in a way that looks like organic behavior.

---

Where the traffic came from

All of it traced back to IP ranges operated by Tencent Cloud out of a datacenter in Singapore — not a mix of residential addresses or a distributed network, just a datacenter.

It turns out this is a known and widespread problem across Shopify. This thread in the Shopify Community forums has merchants describing the same pattern — analytics polluted for months, ad attribution skewed, paid tools inflated. It’s not specific to ArrivesBy; it affects any app or storefront that counts views.

---

What we did

As a solo developer, I’m not in the business of bot detection. It’s a complicated and rapidly changing space, and Cloudflare and Shopify have entire teams that are better equipped for it than I’ll ever be.

The good news is the old tracking system was inadvertently bot-proof — at least for this kind of traffic. The browser-side beacon only fires when real JavaScript executes in a real browser, so bots hitting the endpoint directly never trigger it. The server-side counter we’d switched to had no way to make that distinction. So we’re going back to the old system and sticking with it.

This problem also isn’t specific to ArrivesBy. Any usage-based billing, any analytics, any view counting on Shopify is potentially being distorted by traffic like this. I’m writing this because these issues don’t only affect merchants — they affect app developers too.

If you’re a merchant dealing with this: I was never able to determine why only some stores were targeted. Traffic volume, catalog size, and store location didn’t seem to be factors. But there are steps you can take. This post in the Shopify Community thread explains how Cloudflare’s Orange-to-Orange (O2O) feature works. It lets merchants with their own Cloudflare zone route Shopify traffic through it, giving them access to proper bot management that Shopify’s default setup doesn’t provide. If you’re seeing unusual patterns in your analytics, it’s worth a read.