There are a few legacy breakpoints remaining, but not many: Code search.

Other use cases:

• T319329: Expand navigation timing metrics to include user experience metrics and modernise navigation timing
• T327246: Record interaction to next paint

Relevant for our proposal: T263049: Avoid extra HTTPS connections for most Event Platform beacons

@Ottomata asked me to note that for Product Analytics it would be really helpful if the data was available in data lake and could be accessed/reported with Superset (which we know how to use).

ie. is it possible to show the number of "logout" clicks from logged in user that have a username starting with ~20?

No. Not with the existing schema. We do not log username for privacy reasons.

In T377590#10259253, @Jdlrobson wrote:

In T377590#10258766, @ovasileva wrote:

We would need events for:

• Log-in
• Exit session

This is not quite right. The issue isnt about adding events for clicks it is about distinguishing temporary accounts from logged in accounts.

The elements are tracked but events will appear with isAnon=false. While this allows us to identify the log in link (as no login link is shown to logged in users) it doesnt alllow us to distinguish "exit session" - as an event for that click will look identical to an event for "logout" for a logged in user.

If we only care about that link, yes we should change its event but that would likely need some other changes - they share code for good reasons. I wouldnt recommend this path.

However this goes deeper than those links - all events for temporary users will look like events for a logged in user so if you want information such as click through rate for temporary account or to compare clicks to say the random button (from s logged in vs temporary account user) you cant get that without an additional schema field.

In T377590#10258766, @ovasileva wrote:

We would need events for:

• Log-in
• Exit session

This might relate to https://docs.google.com/document/d/1egtrDC7lo8KtOw1spcnupByljdOCfRo5fWESRCu4XqA/edit?tab=t.0

We would need events for:

• Log-in
• Exit session

In T377590#10242914, @Jdlrobson wrote:

@ovasileva this came up in https://phabricator.wikimedia.org/T375712#10240244 - basically @RHo was asking if we could detect clicks to "Exit session" from users. We can but we can't distinguish between a logged in user logging out and a temporary user. Not sure how important this is and whether it should be a considered a blocker for filing a ticket (please also see my concern on T374942#10242904) - we potentially might need tickets for our other schemas if there are other product needs.

Local testing:

The previous MW configuration and JS code for this has been kept and maintained since 2022 and so is already in production:

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1082102 would also have fixed this problem (I +2'd it last night, but it failed to merge due to some unrelated error).

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1082102 would fix this as well

Change #1082471 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Unblock CI

https://gerrit.wikimedia.org/r/1082471

Change #1082471 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/WikimediaEvents@master] Unblock CI

https://gerrit.wikimedia.org/r/1082471

Yes, please.

so one more prometheus label domain: ["central"|"local"]?

@ovasileva this came up in https://phabricator.wikimedia.org/T375712#10240244 - basically @RHo was asking if we could detect clicks to "Exit session" from users. We can but we can't distinguish between a logged in user logging out and a temporary user. Not sure how important this is and whether it should be a considered a blocker for filing a ticket (please also see my concern on T374942#10242904) - we potentially might need tickets for our other schemas if there are other product needs.

In T355837#10230184, @gmodena wrote:

Will this add significant traffic volumes to eventgate-analytics-external?

Per https://turnilo.wikimedia.org/#webrequest_sampled_live/[...] the peak request rate for the /beacon/statsv path in the last 30 days was ~7,590,400 reqs/da or ~88 reqs/s. I think there's an opportunity to reduce this number by combining updates to counters and guages but I doubt this would have a massive impact.

Test Result - Prod