Some clarifications regarding the proposed definition and measurement approaches:

KR Definition

Proportion of registered users with 100 or fewer edits who publish as least one constructive edit on mobile web (edit was not reverted within 48 hours) on a Wikipedia main namespace within the experiment (or defined timeframe).

• Numerator: Distinct permanent users with 100 or fewer edits that publish at least one constructive VE edit on a mobile web Wikipedia namespace .
  • Note: Decided to limit to VE edits on a Wikipedia main namespace as the KR metric is meant to evaluate the impact of the interventions designed to affect people editing in VE.
• Denominator: Distinct permanent users with 100 or fewer edits that visit a mobile page in a month. Within an experiment, this will be all users exposed to the experiment.

Measurement Approach

To track progress towards this KR, we recommend using the following approaches:
(1) Experiment-Based Tracking:

• What is measures: In the experiment, we will define the KR as the proportion of registered users with 100 or fewer edits who publish as least one constructive edit on mobile web within an experiment (where the denominator is based on experiment exposure (e.g. mobile web page visit)).
• Rationale: Relative rates are more statistically reliable than absolute counts for A/B testing. We can define the denominator of the rate based on experiment exposure.

(2) Long-Term Health Metric available in Supeset:

• What it measures: The absolute count of unique logged-in junior users who publish at least 1 constructive mobile edit per month. This could also be measured tracked weekly pending availability of incremental mediawiki history.
• Rationale: Since this doesn't rely on linking page visits to edits, this instrumentation is readily available and retained past 90 days. This metric will also allow us to evaluate longer-term absolute mobile editor growth driven by structured editing experiences.

Baseline Evaluation

Based on the definition and approaches described in T422743#12021938, here are the calculated [1] baselines for the experiment-based metric.

• Baseline (Excluding English Wikipedia): 0.64%
• Baseline (Including English Wikipedia): 0.40%

Baseline based on average of current monthly rates between March 2026 through April 2026.

Recommendation: I'd recommend adopting the 0.64% baseline (which excludes English Wikipedia) for setting the KR target. See current thinking below:

Rationale:
Including English Wikipedia signficantly decreases the baseline to 0.40%. This is because Mobile VE is currently not presented as the default editor to newcomers on English Wikipedia.

If the core focus of DE 1.1 is to evaluate the impact of new structured editing experiences—all of which are built into the VisualEditor interface—the baseline should reflect environments where VE is the default editor. Using the 0.64% rate ensures our baseline accurately matches the mobile editing experience of our pilot wikis.

However, If the scope of DE 1.1 includes efforts to roll out Mobile VE as the default editor on English Wikipedia, we should adopt the lower 0.40% baseline. This allows us to capture and credit the net impact of the default switch alongside our structured editing features.

Absolute Count Trends
Current Baseline: 12055.7 distinct monthly mobile web constructive editors.

There has been a downward trend in the distinct mobile web constructive editors over the past year.

Next up: I'll investigate more of these trends to propose a target for the KR

Per discussions with @ppelberg, we've decided to include English Wikipedia in the calculated baseline.

Rationale: DE1.1 will include the work of (hopefully) enabling VE by default at en.wiki.

With English Wikipedia included, the calculated baseline for WE 1.1. is 0.40%.

@ppelberg

Below are some recommended targets for the DE 1.1 KR. These are based on a review of trends in the metric from January 2025 through April 2026, current baselines (detailed in T422743#12021964) and a review of past inteventions impact on similar type metrics.

Let me know what target you'd like to proceed with or if you have any questions/additonal data points that would be helpful in that decision.

Proposed Targets for DE 1.1 KR

Targets based on overall baseline of 0.40%

Note: I'd recommend we use the relative target for the KR for a couple reasons:

• Since our current 0.40% baseline is an approximation, the control group might naturally run higher or lower once we deploy an experiment. A relative target (+20% or +70%) adjusts automatically to the control group
• It protects against top-of-funnel volatility and denominator dilution. A traffic surge can dramatically expand the mobile web visitor volume, which would artificially dilute any absolute changes. Evaluating relative lift against a control group isolates the true impact of our features.

Supporting Data

Historical Trends

• The rate has ranged only between 0.30% and 0.43% over the past year.
  • Because the denominator of this rate is so large, the absolute changes in this metric are fairly small. However, small absolute shifts translate to larger relative changes (e.g. +0.13 percentage point absolute increase equates to 43% relative increase).
• Despite the slight downward slope in recent months, the overall proportion of constructive editors has grown since April 2025. The rate was 0.39% in April 2026, compared to the 0.35% baseline observed in April 2025. This represents a +11.4% increase (+0.04 pp).
• Trends indicate some impacts due to seasonal factors. For example, there is a decrease in the Summer months, with the lowest rate observed in September 2025. This might be due to seasonal audience shifts (school year impacts) or an influx of more casual reader tracking that inflates the denominator.
• Recent YoY changes range from 11.4% to 19.4%.

Impact of making VE the default editor
DE 1.1 will include the work of (hopefully) enabling VE by default at en.wiki.

We can estimate the impact of this change be reviewing the change in baseline rate with and without English Wikipedia.

• Excluding EnWiki: 0.60%.
• Including Enwiki: 0.40%

(a relative 50% increase)

Forecasting Trends
I used Bayesian modeling to forecast future trends based on historical data and scaling factors to represent different scenarios (expected, conservative, balanced, and stretch). These scaling factors were estimated based on the context of the planned interventions and retention improvements we've been able to achieve in past interventions.

The projections represent possible targets we might achieve based on current baseline rates and historical trends (dashed blue line). I estimated scaling factors and resulting targets based on the context of planned interventions and retention increases we've obtained in past experiments. These can be adjusted as needed based on predicted scale and impact of planned interventions.

In T422743#12042412, @MNeisler wrote:

@ppelberg
Let me know what target you'd like to proceed with or if you have any questions/additional data points that would be helpful in that decision.

@MNeisler let's move forward with setting the improvement target to 50%. Further, the rationale you offered for using a relative target (rather than absolute) makes sense to me. Let's do that.

Bringing this all together, the finalized DE1.1 KR will read as follows:

DE1.1 FY 26/27 KR
By the end of Q2, achieve a 50% relative increase in the proportion of distinct registered users with ≤100 cumulative edits who publish at least one constructive edit on mobile web through controlled experiments, compared to editors in the control group.

See rationale below.

Before that: thank you for bringing all of the thinking and work you've done into what I find to be a helpfully clear, comprehensive, and comprehensible form. Wonderfully done, Megan.

Improvement target rationale

We're setting a relatively ambitious improvement target (50% relative increase) because we are optimistic that the work we have planned [1] will fundamentally reduce several core frictions people encounter when attempting to edit on a mobile device.[2]

Specifically, editing todays asks that newcomers understand what needs fixing, find things that need fixing, and figure out the precise steps to do make those fixes constructively.

Surfacing suggestions within Wikipedia articles, we think, will meaningfully reduce the effort involved with finding what needs fixing and defaulting newcomers into an evolved version of VE that that offers people a streamlined publishing path for suggestions will materially reduce the effort involved with figuring out the steps newcomers need to take to make changes that are constructive.

Taken together, we think a 50% improvement target is aligned with the magnitude of change we are striving to cause.

1. E.g. enabling VE by default at en.wiki (if, of course, volunteers agree), surfacing the presence of suggestions to logged-in editors on articles, and offering a more streamlined and intuitive publishing path for people who decide to act on suggestions.
2. Through T414710, we are learning people are often i) unsure about how to start an edit, worried about making a mistake, or curious about editing and not encountering a compelling way to start/try it out