> But in their case it seems they are not even trying to filter bots
We try very hard in fact :) We just have some work ahead to surface this better in our analytics UI.
For more detail: we actually assign a "bot score" to each request. Customers customers of our Bot Management product can use this information to block bots at the edge. We are working right now to show the distribution of Bot traffic in the UI so that anyone can see how we are classifying traffic.
There's a 'dead-zone' between the page loading and the analytics script executing, any visitor who leaves during this period won't be counted.
When there's more than one analytics script one will execute before the other so there are abound to be mismatches
GA events have an optional field called "non-interaction", which defaults to false if not present[1].
Pageviews are considered interactive hits. GA's technical definition of a bounce is any visit with only a single interactive hit, leading to the layman definition of bounce rate being "people who viewed two or more pages".
Events though, are also interactive events by default (non-interaction = false being a double negative). So the moment you implement event tracking, if you don't explicitly control that parameter, the definition of "bounce rate" expands to include "the number of people that triggered my event tracking" and your bounce rate will become next to worthless the more liberal or trigger happy your event tracking becomes.
A general rule of thumb is to make "passive" event tracking non-interactive, so that it doesn't impact bounce rate. Things like scroll tracking, timers, etc. Those are all all subject to passive behaviors such as background-ed tabs, impulse scrolling when you first get to a site, etc. And not necessarily representative of active engagement with your site/content.
Then make "active" event tracking (such as clicks tracking on interactive elements or outbound links) interactive. That way bounce rate becomes more representative of active engagement from users. Then optionally, and deliberately, make certain passive tracking events interactive for the express purpose of impacting/influencing bounce rate. For example, a website with lots of long form content but few interactive elements may want to make their passive "30 second" timer event an interactive event, based on business logic that someone spending 30 seconds on an article is considered engaged with it and, having hit that threshold of passive engagement with the page, should. no longer be considered a bounced visit. But every other timer would be set to non-interactive, and scroll tracking would be set to non-interactive (so you don't get false positives from people that scroll all the way to the bottom immediately).
Sending non-interactive events continues to increment the duration, so you still get that value from sending the non-interactive events. But without it skewing your bounce metric.
That said, you rarely see that much care (or understanding) put into it in practice. Familiarity with how implementation impacts interpretation tends to be relatively rare, and a "bad" implementation leads to juiced metrics. So few analytics/marketing teams are even aware they can actively define business rules around what is a bounced visit and what isn't, so most don't and take whatever the system spits out as gospel, implicitly leaving it as "undefined behavior" subject to the whims of however it's implemented.
And even if you educate those teams on such things, no one wants to eat the hit to their vanity metrics that result from truing up an existing implementation that has such issues. So even broaching the subject tends to just lead to consternation and continuation of the status quo[2].
[1] https://support.google.com/analytics/answer/1033068#NonInter...
[2] The bitter grumblings of someone that pokes this hornets nest on a frequent basis, and potentially a skewed perspective rather than objective fact.
The biggest thing to realize is that you can control that particular calculated metric in the first place. At which point, you can decide subjectively what constitutes a bounce for your business/site, and explicitly match your implementation to that business definition. Which may even fluctuate between sections of a site, but rarely aligns with what you'll get out of the box leaving everything with Google's defaults.
FWIW, this isn't an issue for server-side (or in our case, "edge-side") analytics.
Cloudflare Analytics is server side, we all know that server side analytics is good to get number of GET requests but is almost unusable for anything else. But in their case it seems they are not even trying to filter bots
Page views is always the biggest complains people have when they change analytics tool, "why you have 100k more/less pages views than GA, adobe Analytics?" -> "We don't count pageviews the same way" The reality is everyone is filtering bots a different way and nobody is really doing it well, as a result anyone numbers are wrong. The raw number of pageviews usually doesn't mean anything, that's better to look at difference