Both eventlogging_HomepageModule and mediawiki.product_metrics.homepage_module_interaction are now removed from stream config and all producer code has been removed from GrowthExperiments. There's still one change cleanup: remove deprecated stream fixture pending review but not producing any traffic.

This should be testable in any wiki using the JS SDK override mechanism: mw.testKitchen.overrideExperimentGroup( 'we-1-8-tempuser-post-edit', 'treatment'). In this experiment, the query param mpo won't work, as there are two page loads involved and a redirect to Special:CentralLogin and we haven't spent the time to pass the parameter along these. The cookie mechanism used by mw.testKitchen.overrideExperimentGroup should be enough though since there's no cross-domain traversal.

Summary report:

I run the script in normal mode (P94280, P94281), the execution went well until viwiki which has a couple of mentors to migrate and returned the error:

In T409170#12024716, @Urbanecm_WMF wrote:

@Sgs and I discussed this during our 1:1. The problem was that the script was returning LoggedUpdateOutcome::COMPLETE even on dry-run, meaning it got logged as finished in updatelog. I removed all records of its execution again (logs are available at P94199). I also uploaded a patch that changes the script's behavior to always return SIMULATED on dry-runs.

I run the script again in dry-mode (logs P94276) and it did run for all wikis this time, none was marked as already logged. Thank you for helping with this operation. The hang suspicion was also my bad, looking at non-terminating tail -f, so nothing to worry on script termination.

The only remaining change to deploy is waiting on wmf.7 to progress to all wikis so no more data is collected through the HomepageModule stream. At that point we won't have access anymore to fine grained homepage module interaction data, eg: render mode, browser family, client IP. Which was one of the points of performing this task. Fwiw I have taken a snapshot of the last three months of browser families and render modes, may be relevant for T264992:

During Growth team's demo session two problems were surfaced:

This can now be tested in testwiki wmf.7 auto-creating a temporary account through an anonymous edit. The experiment group can be overridden using mw.testKitchen.overrideExperimentGroup('we-1-8-tempuser-post-edit', 'treatment'). Steps for happy path:

I run the script again today with dry-mode and the output (P94151) was unexpected in two ways:

Following discussion from T424205: Post-publish account creation nudge for temp accounts, it seems supporting an NCS edge-unique setup we require some extra work:

In T424595#12018389, @Trizek-WMF wrote:

Was it deployed?

Yes, this was deployed last Wednesday 10 to group0 and group1 and it promoted to group2 on Thursday.

A lookup in codesearch for eventlogging_HomepageModule shows 4 results in non-Growth owned repositories, Wikipedia Android App and repos/data-engineering/metrics-platform. I'm not very familiar with these, the android app code that holds the stream config seems to come from a test kitchen package and repos/data-engineering/metrics-platform is an archived project (?) Could someone from Wikimedia Apps and Experiment Platform confirm how we should proceed with these. Is it ok to remove all occurrences of eventlogging_HomepageModule in those repos? cc @Dbrant @phuedx

In T426193#12004559, @ekrem wrote:

In T426193#12004417, @Sgs wrote:

@ekrem could you elaborate what is the test: with the --line-height-medium styling disabled via devtools trying to validate?

mb, it was supposed to demonstrate the situation «before the fix» (or «if the fix wasn't present»)

@ekrem could you elaborate what is the test: with the --line-height-medium styling disabled via devtools trying to validate?

A simple way to make the experience for both groups not alter the response would be to stop sending the thank-you-edit notification for temporary users. Can we stop sending these, not just the one for the first edit but all, 1, 10, 100... cc @AAlhazwani-WMF @KStoller-WMF

In T424205#11989885, @phuedx wrote:

In T424205#11989590, @Michael wrote:

The main challenge here is: we need to run this as an edge-unique experiment, so that the subject id does not change when the user id does change (temp->named account).

Agreed.

But at the same time we have to vary server-side behavior (not send the notification).

I'm assuming that your looking at setting up the experiment as an NCS experiment as the actions that you're experimenting on are rare enough to warrant going above the traffic allocation cap. However, as you know, you can't vary server-side behaviour with an NCS experiment.

I started working on this and have some questions:

The instrumentation cleanup in WikimediaEvents has already been merged and I have turned off the experiment in test-kitchen's dashboard. The only remaining bit of this task is the consolidation of the language for the call to actions, CtaDrawer: change sign up translation which is waiting to the 18th of June when the Account Creation Reading List CTA experiment finalizes, T420238.

This is now testable in Beta cluster, it is particularly tricky to test end-to-end because of the lack of entry-point links to the Create account page on mobile/Minerva.

The state of need may have changed over time and I have been having recent discussions with engineers from Moderator-Tools-Team about how handy would come to have vue router available in core for the development of Extension:PersonalDashboard. Also in recent design explorations by the Growth-Team we're hitting the "wizard" features with multi-step flows that @egardner is mentioning, for example in T425768: [Spike] WelcomeSurvey redesign exploration. So the current status quo is there are already 2 extensions using it, (Extension:DonationInterface, Extension:ContentTranslation as mentioned by Jdlrobson). And two potential adopters: GrowthExperiments & PersonalDashboard.

This is not testable until a new Codex release is created. I'm on the process of getting the right provisioning to do so, until then moving to blocked.

In T414020#11924959, @GGoncalves-WMF wrote:

So I guess the workaround would be like:

• Find the pages edited by the user in the last 60 days, and the edit dates.
• For each page, call /pageviews/ starting at the date of the user's edit to get the pageviews count.
• Compute the page ranking locally.

Does that sound about right?

This sounds like it would work. There's an important question to clarify, what is the meaning of locally here, but that's probably a separate conversation. If we need to do an ad-hoc data aggregation for honoring the since you edited premise, we'd probably want to cache it somewhere, be it DB table like currently happens or in some client/device storage. Otoh if product/design would be fine loosening the premise to something like pageviews in the last 60 days in an article you've edited sometime in the last 60 days we could avoid having custom aggregations for this module. cc @KStoller-WMF

Just for double-check, this is the interface that's still showing Sign up instead of Create account:

With all the validation issues fixed I was able to run some manual analysis with the reworked CTR instrumentation. The new added metrics and queries can be reviewed in [[ https://gitlab.wikimedia.org/sgimeno/experiment-analytics-configs/-/commit/447df61105300655954712a972183bfdcf0b903b | [DNM] Logged-out anon warning: add re-worked CTRs ]]. I used a query checker template with the following metrics and look at a day snapshot of today, (start 2026-05-14, end 2026-05-15); these where the results:

Impact module displays page views based on edit history on the target wiki. All AQS endpoints that could be relevant to use in Growth's impact module lack some sort of filtering or parameters in the request spec to fit the current module outcome. The next section elaborates on this highlighting the problems on each endpoint

I can confirm in logstasg these have stopped after 1.47.0-wmf.2 train release.

In T419401#11916340, @AAlhazwani-WMF wrote:

@Sgs i tested things on a real device - a iphone 13 mini running ios/safari 24.6.2 and this is what i've found

❌ AC4 - Taken state (warning)

In T415261#11902939, @Michael wrote:

Ok, so I looked into this, and I think in practice the actual changes are almost only related to tests?

The upgrade changes what the API returns in the additionalData field if there is a validation issue. However, crucially, I could not find any users of that field! (code search, none of the other uses seem to refer to the CommunityConfiguration api.)
That makes somewhat sense, as that field introduced as "intentionally undocumented" in Introduce ValidationStatus.

Still, it would be great if someone could verify that it is indeed unused.

This can be tested in all wikis including testwiki. Needs to use the experiment override param: Special:CreateAccount&mpo=we-1-8-account-creation-form-v2%3Atreatment

The requests are being blocked because of the thumbnail size not matching any standard size in

This seems to be happening since the beginning of the experiment, which started on March 31 and the relevant code hit enwiki on April 2nd (see last 90 days). This happens if for some yet unknown reason GrowthExperiments considers the user to be in the treatment group in FeatureManager.php#63 and to be in the control group or unenrolled in TaskTypesAbFilter.js#87. Given these are very few hits across ~300K subjects in the experiment from an analysis pov it doesn't seem relevant. The bad think is that users are getting a broken task card which fails to load the image and description and won't trigger a revise tone task flow.

Waiting on T425604: mediawiki.product_metrics.contributors.experiments - '.action_context' should be string to analyze data.