Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125895
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 02 Nov 2024 14:12:00 +0100
To: internals@lists.php.net
Message-ID: <513d98d2-3cb8-40d9-a428-664f153fa3bd@app.fastmail.com>
In-Reply-To: <2011a2ec-e7e1-41b3-b429-8b39b5437355@jnvsor.net>
References: <55320aad-758a-4d06-b1bd-3eac2b5a5f71@app.fastmail.com>
 <AM8P250MB0170E88F2B19CA8C91786F66E2562@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <2011a2ec-e7e1-41b3-b429-8b39b5437355@jnvsor.net>
Subject: Re: [PHP-DEV] [RFC] PHP.net analytics
Content-Type: multipart/alternative;
 boundary=cc83e26f164e432c9ab738621148a9f3
From: rob@bottled.codes ("Rob Landers")

--cc83e26f164e432c9ab738621148a9f3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 2, 2024, at 00:54, Jonathan Vollebregt wrote:
> On 11/2/24 12:10 AM, Bob Weinand wrote:
> >      What percentage of users get to the docs through direct links v=
s=20
> > the home page
> >=20
> > That's something you can generally infer from server logs - was the =
home=20
> > page accessed from that IP right before another page was opened? It'=
s=20
> > not as accurate, but for a general understanding of orders of magnit=
ude=20
> > it's good enough.
>=20
> Even better: If we're talking about internal navigation you can check=20
> the referrer header and know for sure, since the docs don't add=20
> rel=3Dnoreferrer on links or anything.
>=20
> You shouldn't need server logs _or_ client side JS. A lot of this=20
> tracking stuff could be done by just putting down a proxy or shim that=20
> checks request headers. It looks like matomo offers exactly this via=20
> matomo/matomo-php-tracker.
>=20
> I second bob's general sentiment: There's no need for client side trac=
king.
>=20

Further, most (all?) devs I know generally tend to use pi-holes and othe=
r tracking blockers. Devs are notoriously hard people to track via clien=
t-side analytics. If we went with a client side solution, I would hope t=
hat we use a dedicated domain for ingestion so that this tracking can be=
 easily blocked. It will still be blocked, but some people would rather =
block the entire domain (e.g., go to other mirrors/sites with the docume=
ntation) than be tracked.

For the case of whether comments are viewed via server-side, you could a=
lways load the comments div async once the scroll position goes past a c=
ertain point, and inject them into the dom (see: htmx). This has really =
crappy usability, but works and might create a faster page load for page=
s with lots of comments. For people not using javascript, a simple butto=
n to reload the page with comments (`?comments=3D1`?) should be enough a=
nd provide the desired analytics as well.

=E2=80=94 Rob
--cc83e26f164e432c9ab738621148a9f3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Nov 2, =
2024, at 00:54, Jonathan Vollebregt wrote:<br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><div>On 11/2/24 12:10 AM, Bob Weinand wrote:<=
br></div><div>&gt;&nbsp; &nbsp;&nbsp;&nbsp; What percentage of users get=
 to the docs through direct links vs&nbsp;<br></div><div>&gt; the home p=
age<br></div><div>&gt;&nbsp;<br></div><div>&gt; That's something you can=
 generally infer from server logs - was the home&nbsp;<br></div><div>&gt=
; page accessed from that IP right before another page was opened? It's&=
nbsp;<br></div><div>&gt; not as accurate, but for a general understandin=
g of orders of magnitude&nbsp;<br></div><div>&gt; it's good enough.<br><=
/div><div><br></div><div>Even better: If we're talking about internal na=
vigation you can check&nbsp;<br></div><div>the referrer header and know =
for sure, since the docs don't add&nbsp;<br></div><div>rel=3Dnoreferrer =
on links or anything.<br></div><div><br></div><div>You shouldn't need se=
rver logs _or_ client side JS. A lot of this&nbsp;<br></div><div>trackin=
g stuff could be done by just putting down a proxy or shim that&nbsp;<br=
></div><div>checks request headers. It looks like matomo offers exactly =
this via&nbsp;<br></div><div>matomo/matomo-php-tracker.<br></div><div><b=
r></div><div>I second bob's general sentiment: There's no need for clien=
t side tracking.<br></div><div><br></div></blockquote><div><br></div><di=
v>Further, most (all?) devs I know generally tend to use pi-holes and ot=
her tracking blockers. Devs are notoriously hard people to track via cli=
ent-side analytics. If we went with a client side solution, I would hope=
 that we use a dedicated domain for ingestion so that this tracking can =
be easily blocked. It will still be blocked, but some people would rathe=
r block the entire domain (e.g., go to other mirrors/sites with the docu=
mentation) than be tracked.<br></div><div><br></div><div>For the case of=
 whether comments are viewed via server-side, you could always load the =
comments div async once the scroll position goes past a certain point, a=
nd inject them into the dom (see: htmx). This has really crappy usabilit=
y, but works and might create a faster page load for pages with lots of =
comments. For people not using javascript, a simple button to reload the=
 page with comments (`?comments=3D1`?) should be enough and provide the =
desired analytics as well.<br></div><div><br></div><div id=3D"sig1212291=
52">=E2=80=94 Rob<br></div></body></html>
--cc83e26f164e432c9ab738621148a9f3--