On 11/5/24 6:29 PM, Larry Garfield wrote:
Overall I feel like the signal we can get from using a JS tracker
specifically is comparatively low to the point it's not actually worth it.
Some more things a client-side tracker could do that logs cannot:
* How many people are accessing the site from a desktop vs mobile?
* What speed connection do people have?
* How many people are using the in-browser Wasm code runner that is currently
being worked on? cf: https://github.com/php/web-php/pull/1097
For the first there's a user agent (Again, matomo-php-tracker) as well
as media queries for transparent tracking with <link /> or CSS
Even if someone wanted to block it, meh. We'd still be getting enough signal
to make informed decisions.
Firefox famously keeps killing features thinking no-one uses them
because the people who use them are savvy enough to turn off tracking.
Even if you do use client side tracking that's a good argument to have
server side tracking anyway as a fallback.
Transparency is a big deal. Server side analytics are ok because PHP
devs know what goes into an HTTP request. (And it's fairly limited in
scope by definition) We don't know what goes into a request sent from a
black box blob of minified JS.
If your JS just consisted of `if(wasm) fetch()` I would be fine with
that, but it's actually a 66kb minified JS file.
Perhaps you could just start with server side tracking and see how it
goes? I'd be much happier with client side tracking in future if it's
voted on one metric at a time rather than a big opaque file.
