This is the most common question we get, and it has an honest answer rather than a reassuring one.
Your TrueStat numbers are usually lower than Google Analytics', and the gap is mostly real traffic that neither tool measured perfectly. Here are the causes, ordered by how much of a typical gap each explains.
1. Ad blockers — usually most of it
A visitor running uBlock Origin, Brave's shields, Pi-hole or a blocking DNS
resolver never sends us an event. The request to truestat.io is stopped in
their browser.
This affects both tools, unequally. google-analytics.com and
googletagmanager.com are on every blocklist ever written, so GA loses this
traffic too — often more of it. But GA has other paths: it is frequently loaded
through a first-party tag manager, through server-side GTM, or through a
consent tool that proxies it. Those routes are common enough to close much of the
gap for GA and not for us.
What to do about it:
Serve the script from your own domain. Once t.js and
/api/events come from your own hostname, blockers have nothing to match, and
most of this traffic comes back. It is the single largest recoverable chunk.
Expect a step up in your numbers when you do it. That is the previously invisible traffic appearing, not growth.
2. "Unique visitors" means something different
Not a measurement error. A definitional difference, and the direction depends on your identity mode.
| Your mode | Compared to GA |
| First-party cookie (default) | Comparable. Both recognise a browser across days. |
| Rotating hash | Higher over long ranges — the same person is recounted each day |
| Strict cookieless | Lower — visitors on a shared network merge into one |
So on the cookieless modes your unique visitor count is not wrong; it is answering a different question. See How visitors are counted.
Page views are directly comparable. If you are trying to reconcile two tools, compare views, not visitors — the definitions actually match there.
3. Consent banners
If your site has a consent banner and TrueStat is blocked until consent is given, you lose every visit from someone who declines or ignores it — and the first page view of everyone who accepts, because the script was not present when that page loaded.
Consent rates below 50% are common in Europe.
What to do: switch that site to a cookieless mode, which stores nothing on the device and so does not need a consent gate at all. You get the first page view back and every declining visitor's traffic.
4. Bot filtering, in both directions
With the default "Hide bots" on, your TrueStat numbers exclude crawler traffic. GA filters bots differently — from its own list, applied differently — so the two exclusions do not agree.
Turn "Hide bots" off in TrueStat and your numbers go up, sometimes a lot. That is the crawler traffic other tools discarded before you could see it.
If you are comparing totals, be sure both sides are on the same footing about bots. They are usually not.
5. Browser grouping
Some tools fold Mobile Safari into Safari. We do not. So a browser-by-browser comparison never matches even when the totals do.
This one is small but it makes a per-browser reconciliation look broken when it is not.
6. Single-page navigation
If your site is a SPA, both tools should count route changes. If the other one is misconfigured to count only full page loads, its numbers will be lower on this axis, not ours.
Worth checking before you assume the gap runs one way.
7. Your own visits
If you excluded yourself from TrueStat and not from GA, you are comparing your visitors against your visitors plus you. On a low-traffic site that is a noticeable share. See My own visits are being counted.
8. Timezones and range boundaries
TrueStat's presets resolve in your browser's local timezone. If the other tool is set to a property timezone that differs, "yesterday" is a different 24 hours in each and the daily figures will never agree.
For a like-for-like comparison, use an explicit multi-day range in both.
How to actually reconcile two tools
Compare page views, not visitors. The definitions match.
Use the same explicit date range, several days long, not a preset.
Match the bot policy. Same setting on both sides.
Compare one page, not the whole site. Fewer variables.
Expect 10–40% lower before you proxy, and much closer after.
If the gap survives all of that, or if it is not 10–40% but 90%, something is actually wrong — see No events are showing up.
The honest summary
Neither number is the truth. Every client-side analytics tool measures the traffic that reached it, and something is always lost. TrueStat's number is usually a bit lower before proxying because we have fewer ways around a blocker, and closer after because proxying is the way around a blocker.
What TrueStat gives you that the comparison hides: the crawler traffic the other tool discarded on arrival and can never show you. See AI visibility.