I wish we could just go back to "analytics" being an moderately complicated awk invocation on whatever logs your webserver produces.
As for CloudFlare, all the requests will go through CloudFlare's server for caching, so some request won't reach your server.
Only for static files, they don't cache HTML and dynamic contents. So you can still make sense of unique visitors to your site.
It's not a perfect comparison but I am still on the lookout for the cheapest way to host a static site while retaining access to access logs.
We could go back to the days of talking about "hits" on a website, but for most things where you'd care about these types of metrics, it's a pretty crap metric.
Of course, that does mean you have to track all the user's online activity....
If you're processing personal data to detect bots to prevent let's say card fraud, fair enough. If you're processing personal data to detect bots for analytics purposes, this might not fly.
Of course, this assumes someone actually gives a shit about enforcing the GDPR, which is currently not the case.
Of course, you can do that with server side logs, so in this case client side is less accurate:)
Unfortunately a few sites unfairly throttled me to 1 request/hour despite the cost of my requests being fuck-all. So a couple of years ago I had to randomize those variable names, distribute requests over 64 IPs, and screw up all their analytics numbers in the process. I hope it was worth saving $0.01 for them.
It doesn't matter.
> how do you detect them serverside?
Instead of trying to detect whether something isn't human you should be trying to detect whether something is malicious.
While people who use frontend logging/tracking just search the user ID and see what went wrong.