Why your GA4 is full of traffic from China and Singapore — and why you can't filter it

July 12, 2026

If your GA4 property suddenly shows a wave of sessions from Lanzhou, China, or a data-center IP in Singapore, and none of them convert or scroll, you're not being discovered — you're being spammed. This is "ghost traffic," and through late 2025 and into 2026 it hit thousands of GA4 properties at once. The frustrating part isn't the spam. It's that once you go to filter it out, you find you mostly can't.

Here's the short answer, because it's the part every "add a hostname filter" tutorial skips: ghost hits never touch your website. They're fabricated events sent directly to Google's collection endpoint using the Measurement ID that sits in plain sight in your page source. Your server never sees the request. Your CDN never sees it. Your Cloudflare WAF never sees it. By the time the hit exists, it's already inside Google's data. That's why the usual defenses — IP blocks, firewall rules, bot filters — are structurally unable to stop it, and why the problem keeps coming back.

What ghost traffic actually is

Real analytics traffic works like this: a browser loads your page, your tracking snippet runs, and it reports the visit. The visit is real because a person (or at least a real browser) actually requested your page from your server.

Ghost traffic skips the page entirely. A script somewhere else on the internet reads your GA4 Measurement ID — the G-XXXXXXX string that is, by design, visible to anyone who views source on your site — and POSTs made-up hits to the very same Google collection endpoint your own tracking snippet posts to (/g/collect), which accepts a hit keyed on nothing more than that public Measurement ID. No page load. No browser on your site. No request your infrastructure could log, rate-limit, or reject. The hit is manufactured out of nothing and delivered to Google directly, and Google records it against your property.

(This is the browser-facing collection path the gtag snippet uses. Google's authenticated Measurement Protocol — the /mp/collect endpoint meant for server-side hits — additionally requires an api_secret that isn't in your page source. The ghost-spam wave rides the unauthenticated gtag path instead, which is exactly why the public Measurement ID is enough.)

The traffic tends to cluster around a few tells: cities like Lanzhou, or routing hubs like Singapore where a lot of automated tooling is hosted; near-zero engagement time; a bounce rate that looks like a wall; and sudden real-time spikes of hundreds of "users" doing nothing. It inflates your session counts and it quietly wrecks every rate you calculate from them — engagement, conversion, bounce — because the denominator is now full of things that were never there.

Why GA4's own filters can't stop it

This is the crux, and it's worth stating precisely rather than through the fog of a dozen "10 ways to block spam" posts.

Every anti-spam control GA4 hands you operates after the fabricated hit has already been accepted, and most of the fields those controls inspect can be forged by the same script that sent the hit:

The common thread: your Measurement ID is public and the collector belongs to Google, not to you. You cannot put a bouncer in front of a door that is in someone else's building. The best most teams can do is create GA4 filters or explorations that hide the junk after the fact — cosmetic cleanup that leaves your raw data permanently polluted and has to be re-tuned every time the spam pattern shifts.

What a first-party, edge-ingested tracker does differently

Now the honest contrast — and I'm going to be careful here, because the dishonest version of this pitch ("our tool is unspoofable!") is exactly the kind of claim this blog exists to avoid.

Simplytics is not immune to spoofing. Our site token is public too — it has to be; it ships in the tracking script. A determined attacker with a large pool of IP addresses could still send hits that count. Anyone who tells you their client-side analytics can't be faked is selling you something.

The difference isn't immunity. It's structure. With a first-party tracker, there is exactly one place a hit can enter — your analytics provider's own endpoint — and that endpoint is one you control, so it can apply real checks before anything is recorded, rather than cosmetic filters after. In Simplytics' case, every incoming hit passes through a single edge endpoint that:

• Rate-limits per IP at the Cloudflare edge, so one source can't flood you.
• Rejects known bot user-agents server-side (returns a 400, nothing is stored).
• Validates the timestamp — hits claiming a time more than an hour off from the server clock are dropped.
• Requires the site token to match the domain it claims to be reporting for, so a hit can only ever affect that one site's numbers, never be injected into an arbitrary third party's.
• Derives the country from Cloudflare's CF-IPCountry edge header, not from the request body. This is the big one for ghost-traffic geography: the client doesn't get to assert it came from a particular place. The geo is whatever the connecting IP actually resolves to at the edge. A spammer can't paint themselves as clean US traffic; they show up as exactly where they are.

None of these is a silver bullet, and I won't pretend otherwise. But notice what's different: these are checks run by infrastructure you control, on hits that have to come through it — the exact thing GA4 can't offer, because the fabricated hit reaches Google without ever passing through anything of yours.

The part that limits the blast radius: nothing is kept raw

There's a second structural difference, and it's about damage rather than prevention. GA4 keeps user-level and event-level records, so a spoofed hit doesn't just spike today's chart — it becomes a permanent row you'll be re-slicing for months, and the cleanup is forever.

Simplytics discards raw visit records nightly and keeps only anonymous aggregates. Repeat hits from the same source collapse into a single daily visitor before that, and the raw rows are wiped within roughly a day regardless. So even a hit that gets through can't accrete into a poisoned, re-sliceable dataset you're stuck scrubbing. A bad day is a bad day; it isn't a permanent stain on your history.

And there's a broader point here that connects to how GA4's collection pipeline actually works: the same open endpoint that lets you send server-side hits is the one that lets a spammer send fabricated ones. Openness to your own server and openness to a spoofer are the same door. A tool that only accepts hits through its own front-door, checks them there, and throws away the raw records afterward simply has a smaller attack surface to begin with.

So what should you actually do about ghost traffic in GA4?

If you're stuck on GA4, the realistic playbook is damage-control, not prevention: set up a data filter or a "known bots" segment to exclude the obvious patterns from your reports, keep a clean Measurement ID separate from any you've ever exposed in test tools, and treat your headline numbers as noisy until you've filtered. Just go in knowing it's cleanup, not a wall — the hits keep arriving, and the pattern will change.

The deeper fix is architectural, and it's the honest reason first-party matters here: the fewer places a hit can enter, and the more of that entry path you actually control, the less of this you have to fight. That's not a GA4 setting you're missing. It's a property of where the data is collected.

The bottom line: GA4 ghost traffic from China and Singapore is fabricated hits sent straight to Google's servers using your public Measurement ID, which is precisely why your WAF, IP blocks, and hostname filters can't stop it — they're never in the path. A first-party, cookie-less tracker like Simplytics isn't magically spoof-proof, but it collects every hit through one edge endpoint it controls, derives geography the client can't fake, and throws the raw data away nightly — a smaller, more defensible surface, for a lot less money at $1/month versus the $9–15/month competitors.