On 1.11.2024 22:41:29, Larry Garfield wrote:
In a similar vein to approving the use of software, Roman Pronskiy asked for my
help putting together an RFC on collecting analytics for PHP.net.
https://wiki.php.net/rfc/phpnet-analytics
Of particular note:
* This is self-hosted, first-party only. No third parties get data, so no
third parties can do evil things with it.
* There is no plan to collect any PII.
* The goal is to figure how how to most efficiently spend Foundation money
improving php.net, something that is sorely needed.
Ideally we'd have this in place by the 8.4 release or shortly thereafter,
though I realize that's a little tight on the timeline.
Hey Larry,
I have a couple concerns and questions:
Is there a way to track analytics with only transient data? As in, data
actually stored is always already anonymized enough that it would be
unproblematic to share it with everyone?
Or possibly, is there a retention period for the raw data after which
only anonymized data remains?
Do you actually have a plan what to use that data for? The RFC mostly
talks about "high traffic". But does that mean anything? I do look at a
documentation page, because I need to look something specific up (what
was the order of arguments of strpos again?). I may only look shortly at
it. Maybe even often. But it has absolutely zero signal on whether the
documentation page is good enough. In that case I don't look at the
comments either. Comments are something you rarely look at, mostly the
first time you want to even use a function.
Also, I don't buy the argument none of that can be derived from server
logs. Let's see what the RFC names:
Time-on-page
Whether they read the whole page or just a part
Whether they even saw comments
Yes, these need a client side tracker. But I doubt the usefulness of the
signal. You don't know who reads that. Is it someone who is already
familiar with PHP and searches a detail? He'll quickly just find one
part. Is it someone who is new to PHP and tries to understand PHP. He
may well read the whole page. But you don't know that.
Quality of documentation is measured in whether it's possible to grasp
the information easily. Not in how long or how completely a page is
being read.
What percentage of users get to the docs through direct links vs
the home page
That's something you can generally infer from server logs - was the home
page accessed from that IP right before another page was opened? It's
not as accurate, but for a general understanding of orders of magnitude
it's good enough.
If users are hitting a single page per browser window or navigating
through the site, and if the latter, how?
Number of windows needs a client side tracker too. Knowing whether the
cross-referencing links (e.g. "See also") are used is possibly relevant.
And also "what functions are looked up after this function".
How much are users using the search function? Is it finding what
they want, or is it just a crutch?
How much is probably greppable from the server logs as well. Whether
they find what they want - I'm not sure how you'd determine that. I
search something ... and possibly open a page. If that's not what I
wanted, I'll leave the site and e.g. use google. If that's what I
wanted, I'll also stop looking after that page.
Do people use the translations alone, or do they use both the
English site and other languages in tandem?
Does anyone use multiple translations?
That's likely also determinable by server logs.
And yeah, server logs are more locked down. But that's something you can
fix. I hope that the raw analytics data is just as locked down as the
server logs...
I get that "cached by another proxy" is a possible problem, but it's a
strawman I think. You don't need to be able to track all users, but just
many.
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.
Bob
