Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125915
Message-ID: <3963499a-c9ac-4cbe-b40d-44d62a9240d2@jnvsor.net>
Date: Tue, 5 Nov 2024 22:46:02 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] PHP.net analytics
To: internals@lists.php.net
References: <55320aad-758a-4d06-b1bd-3eac2b5a5f71@app.fastmail.com>
 <AM8P250MB0170E88F2B19CA8C91786F66E2562@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <af567362-efd0-4e4a-9869-2f379f85e0ff@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <af567362-efd0-4e4a-9869-2f379f85e0ff@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-mijn.host-Spamfilter-Domain: mijn.host
X-mijn.host-Spamfilter-Username: 2a03:5180:7:2:f264:726d:beae:1/112
Authentication-Results: mijn.host; auth=pass smtp.auth=2a03:5180:7:2:f264:726d:beae:1/112@mijn.host
X-mijn.host-Spamfilter-Outgoing-Class: ham
X-mijn.host-Spamfilter-Outgoing-Evidence: Combined (0.27)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/Ve1LT1qmR+NfGUGiOnaRDPUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5ysVpdc69k5cRExqclQnUjJ0xCugIxICoR4SK4EpYmU4+fH
 zJ6mVE7ewsipSVIfs4ZdmeyuE52Rk3nk/CGlHxC7ABHVTw1lV42ob3hDgXVUNd9a53XVj4zauHkA
 5dPfA2liT1v1qMyQrE//74nL7QExz1TPCdlThZkNV1D/EuiBxwRo87oeATC+hGtbNyLqD79d1FgH
 UTYLOfKNI261jSzBP06AR5g2UA3HqsYlcMd+kU3FrKlNunbw3GCGM2ilT87d7j7SBq6MwVj6lFM1
 1vq969CCDfOKd5FAllGsCCg+XysEJGdAAQBUErof8jiNd96dw+XGlIW1bb6iLQaqIs5B5d+hLlId
 aCW6xwdNo4OxtwDY4SpTbUhcsSYcTjOB+M5x3dBtceKX2dWiEm+7oHm9xBEeGmns8QeFADnQDTrf
 rserYKXCRGR18OfTWrHpf6kV0xJ411PPMPVAmEodS0dereVcnHDGPTHJJ/+YucHWLMPH12Bh87aa
 4YfZs104p87OifVovUq7COge14oi3y0trSOIPpeqwlm2NDGXIJ2x7Gb/A04ajlC35kGJDTNemOAU
 F4b5hgtV0zUlyPQZsB4RgiPi/ksa+HGUTIc6OyqqhZLNR5od3ShJ8IN9+FxNq9uxaEK0IU2UoAQ9
 iXTmfYh79hnDZXV2CQwQLTmDKYV0FD8YVhEYJh8avNsxASq4s5/DEd6Yplvh+oay7O24oTPnqe0q
 vr5yub6t9+RpDpmA6DFgqFPE6oH+gQdOP9ZXUa7jug5nmpYBfk+Sa7HfYDoFK64ACHgDGgV8xhn+
 dv9OLzZezKBI0p6sXqxigCqRZAiRTstqUvqmSxmBUyP+qDtppB6tCrNkGUFkTXJE/eyznchqeebK
 PhN7F0BXe0tvbxD1H/aAwarQpYDOYx/6JtUOcvGmWjM+n/ZxPLGfNEFyQjyvnjtVkDRQWv9qTHUR
 C+0yXiXZiygtp/+aJr13nBiZGVghYeoeFQXaLJLUHBeObsxUYDzS31QKbDU3aba2yHym0mEV/20k
 j9ngPxZH4PAZ
X-Report-Abuse-To: spam@filter101.mijn.host
From: jnv@jnvsor.net (Jonathan Vollebregt)

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.