Page MenuHomePhabricator

Do not call ExperimentUserManager::setVariant on all newly registered accounts
Closed, ResolvedPublic

Description

Since the introduction of conditional user options as the underlying mechanism for assigning an experiment variant (T376266), the existing code in GrowthExperiments that assigns a variant to newly created accounts (HomepageHooks.php#882) becomes redundant or "competing" with the conditionally default assignment. This task is to stop calling unconditionally setVariant/setOption when a new account is created in a wiki with GrowthExperiments.

Acceptance criteria

  • No variant is stored in the user_properties table for the preference growthexperiments-homepage-variant, except for forced via URL (acceptance criteria 2) or via ge.utils.setUserVariant()
  • geForceVariant parameter overrides the variant assigned via defaults

Event Timeline

Sgs edited projects, added Growth-Team (Current Sprint); removed Growth-Team.
Sgs moved this task from Incoming to Doing on the Growth-Team (Current Sprint) board.

Change #1082816 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] HomepageHooks: stop assigning variants on account creation

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

It's been brought up in code review that if we stop assigning a (different) variant than what conditional defaults already provides (T376266) to newly created accounts, it does not make sense to keep infrastructure (code and configuration) that backs it. Otoh if we do remove this mechanism, conditional defaults becomes our only way for setting up experiments. Per prior conversations with @nettrom_WMF and @KStoller-WMF I believe this is ok, but I'm looking for a confirmation. Looping @Iflorez and @Urbanecm_WMF as well.

The main difference is that we won't have the possibility to conduct an experiment "as we did in the past". Where this mainly means three aspects:

  • Users were only enrolled into experiments on account creation
  • Configuration allowed per-platform distribution (although it's been evaluated as a trick to do feature flagging on a non-ready platform)
  • Side effect: a percentage of newly created accounts occupies space in DB that later needs to be cleaned

I believe it is ok to move on with a system that does not differentiate between existing and new accounts, I believe filtering results by each of these groups of users can be done when doing the experiment analysis filtering by registration date, but confirmation from @nettrom_WMF or @Iflorez is appreciated.
The per-platform distribution configuration was used in the past to avoid enrolling users from an specific platform into the experiment because that feature had not yet been developed for the platform. Although this seems handy, one is not to expect any instrumentation data/traffic from a non-delivered feature so not sure how useful this is. It depends on how we count "things", if variant assignments are counted (they are in grafana dashboards) for something in the experiment analysis it could matter but otherwise, if we only count homepage visits from the platform we know the feature is in, it should not be a problem.

Change #1084181 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@wmf/1.44.0-wmf.1] HomepageHooks: do not store assigned variant on account creation

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

Change #1082816 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] HomepageHooks: do not store assigned variant on account creation

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

Change #1084181 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.44.0-wmf.1] HomepageHooks: do not store assigned variant on account creation

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

Change #1085346 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@wmf/1.43.0-wmf.28] HomepageHooks: do not store assigned variant on account creation

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

Change #1085346 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.43.0-wmf.28] HomepageHooks: do not store assigned variant on account creation

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

Mentioned in SAL (#wikimedia-operations) [2024-10-31T13:28:03Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1085342|Set username in user mock and reset state after test (T378573)]], [[gerrit:1085343|Fix and re-enable selenium test (T378581)]], [[gerrit:1085344|Fix selenium test loading the wrong talk page]], [[gerrit:1085346|HomepageHooks: do not store assigned variant on account creation (T377713)]], [[gerrit:1085347|SpecialHomepage: show community update

Mentioned in SAL (#wikimedia-operations) [2024-10-31T13:30:36Z] <urbanecm@deploy2002> hnowlan, sgimeno, urbanecm: Backport for [[gerrit:1085342|Set username in user mock and reset state after test (T378573)]], [[gerrit:1085343|Fix and re-enable selenium test (T378581)]], [[gerrit:1085344|Fix selenium test loading the wrong talk page]], [[gerrit:1085346|HomepageHooks: do not store assigned variant on account creation (T377713)]], [[gerrit:1085347|SpecialHomepage: show community upda

Mentioned in SAL (#wikimedia-operations) [2024-10-31T13:38:47Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1085342|Set username in user mock and reset state after test (T378573)]], [[gerrit:1085343|Fix and re-enable selenium test (T378581)]], [[gerrit:1085344|Fix selenium test loading the wrong talk page]], [[gerrit:1085346|HomepageHooks: do not store assigned variant on account creation (T377713)]], [[gerrit:1085347|SpecialHomepage: show community update

Etonkovidova updated the task description. (Show Details)