Page MenuHomePhabricator

[Parent task] Transition reading list experimental instrumentation and tracking to permanent
Closed, ResolvedPublic5 Estimated Story Points

Description

Background

During the reading list experiment, we created desktop and mobile instrumentation to track usage of the feature. We need to transition them to permanent instrumentation in order to track usage trends as a beta feature.

The experimentation platform team has created some documentation around how to do so, although some of the strings still say "xLab" when it's possible that this needs to be updated to the newest name: test kitchen.

NOTE: this will encompass switching the custom stream we created to the web stream as we can now select custom contextual attributes via the UI with the instrument workflow

Remaining work as I understand it:

  • confirm with Jennifer whether the redundant metrics identified in T418289 are sufficient, given discrepancies in sampling/contextual attributes
  • follow the above documentation, substituting xlab for test kitchen, on relevant metrics
  • switch the custom stream to use web base stream, and decommission the now-unused custom stream

Design requirements

Add design requirements or link to design files.


Requirements

  • All events are logged as documented under the "Instrumentation long-term" tab of the instrumentation spec here. This does not include the grayed out sections.
  • all events are tracked via the ReadingList instrument and not pulled from other instruments, even with redundancy we want to keep all the tracking together under one instrument.
  • remove page_load for init events.
  • remove article_count from action_context.
  • instrumentation is for all logged in users using reading lists
  • the mediawiki.product_metrics.reading_list stream is removed from mediawiki-config

Acceptance criteria

BDD

  • For QA engineer to fill out.

Test Steps

  • For QA engineer to fill out.

Communication criteria

Add if this needs an announcement or discussion.

Rollback plan

Describe the rollback plan in production for this task if something goes wrong.

This task was created by Version 1.0.0 of the Reader Experience team task template using phabulous.

Event Timeline

Sneha renamed this task from Transition reading list experimental instrumentation and tracking to permanent to [Parent task] Transition reading list experimental instrumentation and tracking to permanent.Feb 4 2026, 6:19 PM
Sneha moved this task from Needs refinement to Ready for sprint on the Reader Experience Team board.

@HFan-WMF Could we get an updated spec for the instrumentation that we want to have going forward, similar to the experiment instrumentation spec? and discuss what we need and what is feasible to include in the metrics?

It would be best from a technical perspective if we can omit article_count from the "save page" bookmark button and the "Saved pages" item in the user menu (linking to the special page).

Also given that we are showing all items from all reading lists (including custom lists), it gets more complex to include this with events.

Jennifer and I discussed which of the metrics from the reading list experiment would be useful to transition to long-term tracking to help understand how users are using the feature. We went through the experimentation instrumentation list, and her recommendation is that we should include all the events under "Engagement metrics" except:

  • article count (as we've discussed in https://phabricator.wikimedia.org/T418013 )
  • user page load (as this is likely already tracked within web_ui_actions
  • we should check whether there are other events in this list that are redundant/duplicates of what's already captured in web_ui_actions

She did say that in the future, when we start working on features that might require tracking to be associated with user_id, we might want to create a new table and get legal's guidance on it through data and privacy review. For this current beta, however, we can likely just use the existing web_ui_actions table. Do you have any thoughts or recommendations on this approach? @aude @SToyofuku-WMF ?

That seems reasonable to me - as long as we're sure we'll have time pre-GA, beta feature seems like the right place for us to strengthen the foundations and make sure we're "doing things the right way" (for now we can use the data wherever it is available)

I think everything under engagement is okay, except user page load and article count, which we agree to remove.

features that might require tracking to be associated with user_id, we might want to create a new table and get legal's guidance on it through data and privacy review.

I am not sure what type of features require this? For reading lists, we can also query the database analytics replicas and get some metrics that way,

SToyofuku-WMF set the point value for this task to 5.Mar 2 2026, 6:30 PM

Steph to work on updating the description a bit to reflect what's needed

LMora-WMF changed the task status from Open to In Progress.Mar 11 2026, 5:45 PM
LMora-WMF claimed this task.

Change #1251505 had a related patch set uploaded (by LorenMora; author: LorenMora):

[mediawiki/extensions/WikimediaEvents@master] Transition reading list experiment to instrument

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

Change #1251507 had a related patch set uploaded (by LorenMora; author: LorenMora):

[mediawiki/extensions/ReadingLists@master] Transition reading list experiment to instrument

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

This comment was removed by LMora-WMF.

From slack discussion we talked about setting the following for the instrument in test Kitchen:

  • Machine-readable name: reading-list-engagement
  • Stream name: product_metrics.web_base
  • Sample unit: session
  • start/end date: asap and end date years into future (still need some clarity here)
  • Wikis and sampling rate: all wikis set to same as for mediawiki.web_ui_actions, which is 20% with the exception for enwiki which is set to 1%

Unanswered questions / things to consider:
Is there's a way to not have an end date? Test Kitchen UI currently requires it.
Is there is a way to put in all wikis bc you currently have to add each one separately within Test Kitchen UI?
Is our desired sample rate too high to start with? Documentation states: "It is recommended to start with a smaller sampling rate when you first go live with your instrument on real wikis - 10% of sessions or even 1% of sessions if the instrument is expected to produce a lot of events per sessions (i.e. sessionTick) so that the instrument owner doesn’t accidentally DDoS WMF."
Is it possible to set different sample rates for logged-in vs logged-out users? Can we sample 100% of logged in users?

LMora-WMF updated the task description. (Show Details)

Change #1259249 had a related patch set uploaded (by LorenMora; author: LorenMora):

[mediawiki/extensions/ReadingLists@master] Transition reading list experiment to instrument

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

Change #1259251 had a related patch set uploaded (by LorenMora; author: LorenMora):

[operations/mediawiki-config@master] Transition reading list experiment to instrument

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

Change #1259249 merged by jenkins-bot:

[mediawiki/extensions/ReadingLists@master] Transition reading list experiment to instrument

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

aude added a subscriber: LMora-WMF.

Steph is reviewing (although it seems like @aude is too)

Change #1251505 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Transition reading list experiment to instrument

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

meeting notes: To be verified by an engineer in superset.

With this query in superset of presto_analytics_hive, I see some instrument events:

SELECT dt, mediawiki."database", performer."edit_count_bucket"
FROM product_metrics_web_base
WHERE year=2026 and month =4
AND instrument_name = 'reading-list-engagement'
LIMIT 10

Not sure if there is a further step to setup a dashboard in Superset or something else?

HFan-WMF claimed this task.
HFan-WMF added a subscriber: jwang.

Sounds like we have verified that events are being properly logged in as ongoing product health metrics! I'm going to resolve this for now, and follow up with @jwang on whether we want to create a dashboard in Superset where we can view beta users' article saving activity on an ongoing basis.