The short answer: they throw the data away before it is stored.
What every other analytics product does
Bot traffic is noise if your product is about people. So the standard design is to detect a bot at the moment the event arrives and not record it. That keeps the visitor numbers clean, keeps the database small, and is the right call for a product that reports on humans.
The cost is permanent. A crawler hit that was never written cannot be reported later. There is no setting to switch on, no backfill, no export. The information did not survive collection.
What TrueStat does
Every event is stored, with a flag saying whether it was a crawler and which one. Nothing is discarded on arrival.
The filtering happens when you read, not when you write. Your dashboard's default "Hide bots" state applies at query time, so:
Your human numbers are as clean as anyone else's, because the same filter runs.
Turning the filter off shows crawler traffic including everything already collected, all the way back to your first event.
The AI panel simply ignores the filter, and reports the rows the human view hides.
The whole difference is when the filter is applied. Applied at collection, it is destructive. Applied at read, it is a view.
What that costs you
Two real costs, stated plainly, because they are the reason other products chose differently.
Crawler views count against your monthly event limit. They are stored, so they are counted. On a small site with a lot of crawler attention, that can be a noticeable share of your quota. See What counts as an event.
Your stored data is larger. That is our problem rather than yours, but it is why this is not free to offer.
We think it is the right trade. A crawler hit costs one row; the ability to answer "which assistants read my site" cannot be recovered at any price once it is gone.
What this does not give us
Being clear about the boundary, because "we keep the data others discard" is easy to over-read.
It does not let us see crawlers that never reached us. A crawler that fetches your raw HTML without running JavaScript never triggers our script, so there is no event to store or discard. Keeping everything only helps for traffic that arrived. See How reliable is it.
It does not make the identification more certain. A crawler is still identified by the user agent it chose to send, same as anywhere else.
So the accurate claim is narrower than "we see AI crawlers and they do not": we keep and report the crawler traffic that reaches us, where other products delete it. On the traffic that reaches both, we can answer questions they structurally cannot. On the traffic that reaches neither, nobody can.
Server logs
You can get some of this from your own server logs, if you have them, and if you are willing to parse user agents and keep the logs long enough. It is a real alternative and worth saying so.
What that does not give you: the classification maintained as new crawlers launch, the assistant-versus-training split, IP verification against operators' published ranges, or the same view sitting next to your human traffic in one range picker. And on a static host or a serverless platform you often do not have the logs at all.