Page MenuHomePhabricator

[Community Updates module] Migrate experiments fragment
Closed, ResolvedPublic3 Estimated Story Points

Description

Description

As a part of the ongoing work regarding xLab, and specifically because of T389995: Experiment membership tracking schema fragment, the current experiments schema fragment is being deprecated and superseded by a new one called experiment (in singular).

There is currently some temporary code in the JS client library that allows growthExperiments to add, directly, experiments details as interaction data. That work was done as a part of T381849: Community Updates module impressions lack experiment and variant information. Now, as a part of the mentioned deprecation process, the Community Updates module should migrate from the deprecated experiments schema fragment to the experiment one to allow the JS client library to be updated to use the new experiment fragment there.

Technical notes

Note that the new experiment fragment has the same assigned and enrolled properties we are using so far so we could say and, technically speaking, the purpose of those properties is the same for the new experiment schema fragment. In addition to this we are working in a new property called coordinator that will be use to indicate if the enrollment details have been filled by the client library or, on the contrary, they were filled by some custom code (like it's happening here). In this case the right value for this property would be custom to mean that the enrollment details has been added to the event by a custom node instead of the client library. Take a look at T390207: Add coordinator property to experiment fragment for details about that new property.

Acceptance criteria

  • [Growth Team] Community Updates module has been migrated and it's using the new experiment schema fragment to fill enrolled and assigned properties
  • [Growth Team] Community Updates module sets the new experiment.coordinator property to custom to mean that the enrollment details haven't been filled by the client library
  • [Experiment Platform Team] The JS client library temporary code has been updated to work with the new experiment schema fragment

Notes

  • This task will be a blocker for the deprecation process of the experiments schema fragment

Event Timeline

Sfaci renamed this task from Migrate to [Community Updates module] Migrate experiments fragment .Mar 28 2025, 4:33 PM
KStoller-WMF moved this task from Inbox to Estimated tasks backlog on the Growth-Team board.
KStoller-WMF subscribed.

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

[mediawiki/extensions/GrowthExperiments@master] analytics: update instruments using product_metrics/web/base/1.4.1

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

The Community Updates module instrumentation data is not being actively analyzed so I've made the change (1132666) to stop using "experiments" in favor of "experiment". For the Surfacing structured tasks experiment (T377098) the "experiments" property is being actively used for analysis so I've left it intact and added "experiment". From the Growth pov there aren't any blockers for deprecating experiments as we will keep on using /analytics/product_metrics/web/base/1.4.1 until the end of the experiment. cc @Sfaci

Looking at the new schema, it seems assigned and enrolled have also changed its meaning and purpose. Is the fact that these two properties have changed from being an Object and array respectively that there no multi-experiment support anymore? If the other_assigned property is meant to hold "the other experiments". How can one tell which is "the main" experiment vs "the other" experiments? cc @Sfaci

Change #1132666 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] analytics: update instruments using product_metrics/web/base/1.4.1

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

Looking at the new schema, it seems assigned and enrolled have also changed its meaning and purpose. Is the fact that these two properties have changed from being an Object and array respectively that there no multi-experiment support anymore? If the other_assigned property is meant to hold "the other experiments". How can one tell which is "the main" experiment vs "the other" experiments? cc @Sfaci

I'm sorry but I didn't see this comment before! I did see the one you posted in the change that was pretty similar. Not sure if that one worked for you. Just tell me if you need some additional clarification. I mentioned there that:

The purpose of the enrolled property is to mean that the event is related to some specific experiment and the other_assigned one exists for metrics platform client libraries to put there all the other experiments where the user is enrolled but are not related to the event that is going to be submitted.

That means that there are multi-experiment support for xLab experiments but there isn't for other "coordinators". At this time we are not considering to support "custom" coordinators sending details about their other experiments. The client libraries are the ones that populates that other_enrolled property with the xLab experiments that are running. There is only support for the case covered in this ticket where client libraries will include details about the experiment you send as interaction data when submitting events.

Milimetric claimed this task.
Milimetric moved this task from Incoming to Backlog on the Test Kitchen board.
Milimetric set the point value for this task to 3.
Milimetric subscribed.

This looks like it was completed by ghosts