Re: [RFC] PHP.net analytics

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.