I am wondering, is there a way to segment the web baseline by accounts created via mobile web or desktop?

Yes, we can get the platform info by joining the tables. Please create a ticket for it. It should be a quick task, and I can likely prioritize it on Friday or next week.

Hi.@HNordeenWMF , After changing the definition to 7 days, the percentage increased slightly: 64% of new accounts were classified as new readers.

From a data tracking perspective, users will continue to be tracked by their Edge Unique ID once they are initially bucketed. Because we plan to enable the performer_is_logged_in and performer_is_temp fields, we can exclude such users from the analysis by filtering on those fields.

I've drafted the measurement plan and instrumentation spec for Custom Reading Lists. Please review the following and let me know if you have any questions.

• User flow
• Instrumentation spec
• Measurement plan

The plan and spec are finalized.

Please find the per wiki data in the tab [[ https://docs.google.com/spreadsheets/d/1FIUP26Zasms3wfZJCmg9lVcEhwr3x2m8X-zjdlvGMGs/edit?usp=sharing | per_wiki_data in the google sheet ]].

I have updated the min min spec and measurement plan based the discussions with the engineer and PM. The major changes include: (1) the metric categorization, (2) how we track edits, (3) track watch instead of account creation, and (4) some of the event names. These changes are highlighted in blue. Please review and let me know if they make sense.

Estimate annual pageviews from shared links if we deploy on all wikipedias or all wikis.

Status:
Have prepared SQL files to manually pull daily new reader accounts. The models have been tested successfully in the DBT environment. Now passed onto @Milimetric for
automation.

@jwang question: how easy would it be to automate this and start visualizing this data here? Do you need @Milimetric 's help?

Following a discussion with Jaz on Slack, we'd also established a monthly baseline that includes both web and app: https://phabricator.wikimedia.org/T426543#12060121

Following a discussion with Jaz on Slack, we'd also like to establish a monthly baseline that includes both web and app. Here it is.

After discussing this with @HFan-WMF, we also wanted to establish baselines on a monthly basis. The table below shows the monthly new reader account counts for FY2025 Q1 and Q2 using the definition above.

Analysis summary

Pageviews from shares

From 2026/5/19 to 2026/6/20,

• 3,581 pageviews were recorded from shared links.
• The share-to-pageview ratio was 0.65 (3581/5546) pageviews per share.

@HFan-WMF, The quarterly baseline using the new definition has been posted at: https://phabricator.wikimedia.org/T426543#12042220
Do we also need to establish a weekly baseline?

After discussion, we revised our previous definition. Specifically, we changed the observation window used to classify users as editors or readers from 30 days to 7 days in order to reduce the reporting lag of this metric. The rationale and final decision are documented in the Google Doc.

I've set up the dashboard for the Reading List account creation CTA: https://growthbook.wikimedia.org/experiment/exp_10ipnmqbj1zeo#results

Status:

• Analyzed a subgroup of users in the 1-4 edits and 5-99 edits groups. We observed a clear positive relationship between editing activity and retention among logged-in users. Users with more edits have higher retention rate across all three retention definitions,
• Started to draft the report and worked on visualizations.
• Walked through the results with the PM.

Exp platform team has setup the dashboard in growth book for us: https://growthbook.wikimedia.org/experiment/exp_zvrnmpwoh6si#results

@amastilovic is there an easy way to selectively run modified dbt jobs in production for backfilling like what we might need above?

For rounds 8–10, I can manually snapshot the data into my database tables: jiawang_web.retention_logged_out_cross_wiki and jiawang_web.retention_logged_out_per_wiki.
Would it be easier for you if I did that and then you write the data into the destination schema?

The mediawiki.database was added back since May 15. Between 4/29 and 5/14, the field is NULL.

@tchin , I discovered a few instrumentation limitations for Rounds 4–10 that could affect the accuracy of the baseline metrics. Just wanted to keep you posted.
Rounds 4–7
The performer_is_logged_in field was not enabled between April 1 and April 15, so we cannot distinguish logged-in page visits from logged-out page visits during that period.
There was also a transition from the page_visited event name to page_visit, which may introduce inconsistencies.

Status:

• Explored the trends on desktop and mobile web separately. Observed a clear weekly cycle, similar to logged-out users.
• Analyzed a sub group of users who visited on both desktop and mobile. They have a higher retention rate.

• FY25–26 Q1
  • 316,868 new reader accounts did not make any edits within 30 days of registration.
  • A total of 502,691 new accounts were created in Q1. Of these, 63.0% were classified as new reader accounts.
• FY25–26 Q2
  • 356,662 new reader accounts did not make any edits within 30 days of registration.
  • A total of 544,095 new accounts were created in Q2. Of these, 65.6% were classified as new reader accounts.

Notes:

• The baseline includes accounts from Desktop, Mobile Web, and App platforms.
• The baseline includes only Wikipedia projects.

Hi @Snwachukwu, thanks for the update! The SQL for the retention window logic looks good to me. However, I have a question about the run_dt and end_date logic in the query.

{% set run_dt = var(
    'run_date',
    (dt.date.today() - dt.timedelta(days=6)).strftime("%Y-%m-%d")
) %}
{% set end_date = (dt.date.fromisoformat(run_dt) + dt.timedelta(days=6)).strftime("%Y-%m-%d") %}

HI @Jdrewniak , I’ve completed the instrumentation spec and measurement plan. Now pass them to engineers for review.

SQL location (@stat1010): /home/jiawang/share/dbt-jobs/models/web_reader

The dashboard is live in superset: https://superset.wikimedia.org/superset/dashboard/p/ZEXOPgzerKb/

Status

• Explored the cumulative retention conversion trend. The data suggests that the convergence trend is similar to that of logged-out users, with the curve remaining relatively flat beyond 20 days. I would recommend using the same cumulative retention definition as logged-out users: the 21-day cumulative retention rate. To be specific, the percentage of logged-out users who return at least once by the end of day 21 after their first visit within a given 7-day cohort week.
• The baseline for logged-in reader 2nd week retention rate: 46%. SD: 0.9%. Data source: 1st logged-in AA test in April, 2026.

Next steps:

• Explore the trends on desktop and mobile web separately.

Hi, thank you very much for working on the automation and dashboard. I noticed that the retention definition here is different from the definitions currently used for the logged-out users, the app users, and the A/B testing. Could we schedule some time to discuss how to align these definitions?
The main difference is in how the return window is defined. Here is a SQL example that the logged-out and app are currently using.

• Have QA-ed the data. Noticed that the event name switched from 'page-visited' to 'page_visit' around April 17. It won't impact the analysis.
• Have pulled the retention rate across wikis and platforms.

Status

• The data for logged-out-retention-round3 has been pulled and stored in the jiawang_web.retention_logged_out_cross_wiki and jiawang_web.retention_logged_out_per_wiki tables.
• The data for rounds 4–7 has an instrumentation issue: we currently cannot distinguish logged-out from logged-in page visits. ( slack discussion)
• The next usable dataset will mature in about 10 days with round 8.

Request 1: Splits by article and/or lead section length (Hypothesis: if the article lead section is really long, then ToC is more helpful. Did we log this? Can use the first article someone landed on to simplify.)
We didn’t log page-level information, and all current events come from articles, so we can’t break them down further for analysis.

Have pushed the config files. Now it's under review.

Data QA summary of logged-in retention instrument
Table: event.mediawiki_product_metrics_reader_retention_logged_in

I’ve reviewed and revised the measurement plan and spec for article preview. The major changes are:

1. Metrics and their categorization, based on the discussion with Sherry
2. Stream and event names, updated to follow the experiment platform team’s guidelines

I have added my comments and updates in the share feature measurement plan and instrumentation spec. A few open questions:

@SherryYang-WMF , Just to confirm, are we planning to measure Session length? It’s not mentioned in the measurement plan but is listed in the ticket. If so, what do we expect to see?

For documentation purposes, we ultimately decided to set up the dashboard in GrowthBook with support from the Experiment Platform team. Here is the dashboard link: https://growthbook.wikimedia.org/experiment/exp_6v4betpmmnu69x2#results

Here is the measurement plan and instrumentation spec for the account creation Reading List CTA. Please review and feel free to add your input.

@HFan-WMF , The list includes the top wikis other than enwiki, and looks good to me. One thing to note is that ptwiki requires users to be logged in to edit, so its registration rate may differ from others. It’s worth reviewing the results separately.

Please find the draft analysis of the second baseline. It is ready for review.

Does this include temp accounts? I see performer_is_temp in the spec as a contextual attributes.

We want to analyze users with logged_in = true and performer_is_temp = false. It’s unclear whether temporary accounts will be bucketed into the experiment. If they are, we will filter them out in the analysis using the performer_is_temp field.

Sorry for the confusion. To clarify:
For the Analytics_sampling:
Sample_unit: performer_session_id
Sample rate: 100%

If we use test kitcken, the Sample unit should be wm-user , not  session .

Here is the draft of the instrumentation spec. Pass it to the engineer for review.

Here is the draft of the analysis report , ready for review.

Status update:
Here are the Mobile Web ToC Measurement Plan and Instrumentation Spec. Ready for product team review.

Both skin preference and global preference reflect the status as of the data collection date, which is January 28, 2026.

Status update:
Here is the initial draft of the image browsing usage analysis. Have shared with the team for review.

• Defined metrics in metrics_catalog.yaml

Have defined retention metrics for desktop web using the same definition as mobile web retention. They passed the test in local notebook.
Merge request link.

It has been completed in T406013 and T410794.