Is Google Analytics Blocked in China?

Is Google Analytics Blocked in China?

Most answers to this question are a single word, and the single word is wrong in both directions.

"Yes, Google is blocked in China" is the folk answer, and it leads people to assume their tag never fires and their Chinese traffic is simply invisible. "No, Analytics still works" is the vendor-adjacent answer, and it leads people to trust numbers that are quietly missing a slice of their audience.

The measurements say something more specific and more useful than either. The script that loads the tag is generally reachable from mainland China. Some of the endpoints that receive the data are not. That gap is where your Chinese traffic goes.

Is Google Analytics Blocked in China? The Direct Answer

Partly. Not the whole product, and not evenly.

GreatFire, a censorship-monitoring project that has been testing Chinese network access since 2011, reports that www.google-analytics.com is "100% blocked in mainland China", based on its last test on November 7, 2026, with recorded interference going back to October 22, 2012.

That is the headline. The detail underneath it matters more. At the domain level GreatFire's verdict for google-analytics.com is not "blocked" but "Mixed", with the summary line "Blocking varies across google-analytics.com: 10 blocked vs 39 accessible among tested hosts."

Pull that apart and the picture inverts in places:

• https://www.google-analytics.com/gtag.js — listed as not blocked
• https://www.google-analytics.com/g/collect?v=2, the GA4 collection path — listed as intermittent
• https://region1.google-analytics.com/g/collect, a regional collection endpoint — listed as blocked

And Google Tag Manager, which is how most sites actually load their Google tag, tests clean.

GreatFire's page for www.googletagmanager.com answers the question "Can you open it from mainland China?" with "Yes", noting "All 6 recent conclusive tests connected normally" as of October 25, 2026, and zero disruptions across the previous ninety days.

So the honest version is this: the tag usually loads. The hit sometimes does not arrive. Your Chinese visitors are not absent from your site — they are absent from your reports.

Not sure how much of your traffic your analytics is actually seeing? Get a free audit and find out what is missing before you plan around the numbers.

What Is Actually Blocked, and What Is Not

Three different things have to succeed for a pageview from Shanghai to appear in your GA4 property, and the Great Firewall treats them differently.

The loader

The Google tag arrives as a script from googletagmanager.com. On GreatFire's testing this host is consistently reachable, with a clean record across its recent test window. If your tag is installed the standard way, this first step is usually not your problem.

That also explains a confusing symptom site owners report: the page renders normally, the browser console shows no blocked-resource error, and the tag object exists. Everything looks healthy on the client, because the client side genuinely is.

The collection endpoint

This is where it breaks. GA4 sends its hits to a /g/collect path, and GreatFire's tests put the plain www.google-analytics.com version of that path at "intermittent" and the region1.google-analytics.com version at "blocked".

Intermittent is the word that causes the most damage, because intermittent failure does not look like failure. It looks like lower numbers. A hit that never lands does not raise an error anyone sees; it simply is not counted.

Everything behind the reporting interface

Separately from collection, the people who need to read the reports have their own problem. Wikipedia's list of sites blocked in mainland China records Google's main properties as blocked "2014–present (completely)".

If your Chinese colleagues cannot open the Analytics interface, that is the same firewall acting on a different domain, and no amount of tag configuration fixes it.

Worth noting what is not on that Wikipedia list: neither google-analytics.com nor googletagmanager.com appears in its table at all.

The page also carries a maintenance notice reading "This section needs to be updated.(July 2025)". It is a reasonable source for the shape of the blocking, not for the current status of any specific host.

What Google's Own Documentation Says About This

Nothing.

That is not a gap in the research — it is the finding. Google Analytics Help does not carry a page explaining that collection fails in mainland China, and the documentation does not warn you that a region of your audience will under-report.

There is no banner, no regional-limits note, no "markets where data collection may be affected" list.

The practical consequence is that your property gives you no signal at all. GA4 will not tell you it lost hits. It will show you a number, and the number will be confidently wrong by an amount you cannot see from inside the interface.

This is why the question gets asked in the first place. People notice the discrepancy from the outside — a campaign that clearly landed, a region that clearly converted, and a report that shows almost nothing — and go looking for an explanation the tool itself never offers.

Seeing numbers that do not match what you know happened? Get a free audit and we will tell you whether it is the tracking or the traffic.

How to Check Whether This Is Affecting You

You cannot diagnose this from your own browser, so stop trying. Here is what actually tells you something.

1. Compare analytics against a source the firewall does not touch. Server logs, your CDN's analytics, or your payment processor all record requests that never depended on reaching Google. If your server logs show meaningful mainland Chinese traffic and GA4 shows close to none, you have your answer in one comparison.
2. Look at the country report for the shape, not the number. Chinese traffic that is being partially collected does not vanish — it shrinks. A country that is plainly a real market for you but sits implausibly low, with a bounce rate and session duration that look nothing like your other regions, is a collection artifact rather than an audience insight.
3. Check which collection host your property uses. GA4 properties may send to a regional endpoint rather than the plain one. Since the regional host tested as blocked and the plain one as intermittent, two properties can behave differently in the same market for reasons that have nothing to do with your site.
4. Re-test rather than trusting any single report, including this one. GreatFire's verdicts carry a last-tested date for a reason. Blocking changes, and a result from three weeks ago is evidence about three weeks ago.
5. Ask someone actually there. A colleague or customer on a mainland connection, without a VPN, loading a page while you watch your realtime report is the cheapest conclusive test available.

None of these five steps requires a tooling change. They require one hour and a willingness to find out the number is wrong.

Want a second pair of eyes on whether your tracking is telling you the truth? Get a free audit and we will check it against what your server actually saw.

When This Actually Matters

For a great many sites, it does not. If mainland China is not a market you sell to, a slice of under-counted traffic changes nothing you would have decided differently.

It matters when any of these are true:

• You are evaluating China as a market. Under-reported traffic looks exactly like absent demand, and the decision you make from it is to not bother. That is the expensive version of this problem.
• You run paid campaigns that reach Chinese users. Spend is recorded accurately; conversions attributed through a blocked endpoint are not. The ratio between those two numbers drives budget decisions.
• Your totals are a reporting commitment. If a client or a board sees a traffic figure, a silently missing region is a credibility problem the moment anyone cross-checks it against server data.
• You have staff in mainland China. Their own visits may not register, and more importantly they may not be able to open the reports at all.

If none of those apply, the correct response is to know the limitation exists and move on.

Limitations: What You Cannot Fix From Your Side

Be clear-eyed about this, because a lot of advice on the subject oversells the remedies.

You cannot configure your way out of a network block. No GA4 setting, consent-mode adjustment or tag parameter makes a blocked endpoint reachable. The failure is between the visitor's browser and Google's servers, which is not territory your property controls.

Partial collection is worse than no collection. If nothing arrived, the gap would be obvious. Because some hits land, you get a plausible-looking small number instead of an obvious zero, and plausible-looking numbers get used.

Historical data cannot be repaired. Whatever was missed was missed. You can improve collection going forward; you cannot backfill sessions that never reached a server.

Measurement of the block is itself approximate. GreatFire is an independent monitoring project, not an official source, and it reports test results from specific vantage points rather than a guarantee about every network in the country. Treat "blocked", "intermittent" and "not blocked" as measurements with dates attached, which is exactly how the project presents them.

Latency is a separate issue from blocking. Even reachable Google-hosted resources can be slow from mainland China, which affects whether a tag fires before a visitor leaves. A host that is not blocked is not automatically fast.

Planning around traffic data you are not certain about? Get a free audit and start from numbers you can defend.

How This Compares to the Alternatives

If mainland China genuinely matters to your business, Google Analytics is not the only option, and the alternatives trade different things away.

Server-side collection. Routing hits through your own domain before forwarding them means the visitor's browser never has to reach a host that might be blocked. This is the most direct answer to the specific problem, and it is also the most work: it needs infrastructure, maintenance and someone who owns it.

A local analytics platform. Chinese analytics products are built for the market and do not fight the firewall. The cost is a second system, a second data model, and no clean way to compare its numbers against your global reporting.

Server logs and CDN analytics. Unglamorous and genuinely reliable, because the request reaches your infrastructure regardless of what Google's hosts are doing. You lose the event model, the attribution and the interface, and you gain a count you can trust.

Doing nothing, knowingly. For most sites this is the right call. The failure mode is not having a gap in your data; it is having a gap you do not know about. A one-line note in your reporting that Chinese traffic under-reports costs nothing and prevents the bad decision.

The pattern is familiar from other measurement gaps. Browser-level restrictions cause a comparable problem from a completely different direction, and the reasoning is much the same — see our guide to whether Safari blocks Google Analytics for the version of this that affects far more sites than the firewall ever will.

Final Thoughts

The accurate answer is that Google Analytics is partly blocked in mainland China, and the part that is blocked is the part that matters.

The script loads. Tag Manager is reachable. The collection endpoints are where it falls apart, with the plain GA4 path testing intermittent and a regional path testing blocked outright.

The result is not an empty report but an understated one, and Google's documentation says nothing to warn you.

So the thing to take away is not a workaround. It is a caveat: if mainland China is in your numbers, your numbers are low there, by an amount you cannot determine from inside Analytics.

Check against something the firewall never touched, write the limitation down next to the figure, and make the decision with the uncertainty visible rather than buried.