Change Details

== Description With the proposed updates to the experiment membership tracking schema (fragment proposed in T389995), we will need to update the javascript client library to supplements events i.e. be able to read and populate fields for the new `experiment` data object (to supercede the previously defined `experiments` data object) Proposed payload to be added to all events: ``` experiment: { enrolled: "2025-hoverlinks-blue-3", assigned: "a_group_name", subject_id: "0000001badb00200000ff1ce1badb002000000ff1ce0000000ff1ce0000000", sampling_unit: "mw-user", other_assigned: { "experiment_name_2": "control", "experiment_name_3": "any_group" } } ``` Additionally, the xLab SDK will house the experiment manager API such that all current experiment-related methods will be removed from the EventLogging ResourceLoader module and moved into a new xLab ResourceLoader module ({T390089}). We can also take the opportunity to improve [[https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/blob/main/js/src/MetricsClient.js?ref_type=heads#L461|the way we are checking if the schema title supports experimentation]]. This feature was added for the web base schema 1.3.0 and, at this time, we are just checking the exact name and the version to be sure that the needed `experiments` fragment schema is there to fill the enrollment details. We should find a better way. In fact, the web base schema has been already updated a couple of times and the current way of doing that won't work properly. We could say something like the following: ``` if ( schemaID === '/analytics/product_metrics/web/base' && version(schemaID) >= 1.3.0 ) ``` == Acceptance Criteria [] Remove `mw.eventLog.isCurrentUserEnrolled()` [] Update `mw.eventLog.getCurrentUserExperiments()` to read experiment details from `wgMetricsPlatformUserExperiments` and prepare them according to the `experiment` schema fragment [] Decorate events with `enrolled`, `assigned`, `subject_id`, `sampling_unit` keys for experiment-related events, and `other_assigned` for all events. [] The way we check if the schema title supports experimentation has been improved/updated

== Description With the proposed updates to the experiment membership tracking schema (fragment proposed in T389995), we will need to update the javascript client library to supplements events i.e. be able to read and populate fields for the new `experiment` data object (to supercede the previously defined `experiments` data object) Proposed payload to be added to all events: ``` experiment: { enrolled: "2025-hoverlinks-blue-3", assigned: "a_group_name", subject_id: "0000001badb00200000ff1ce1badb002000000ff1ce0000000ff1ce0000000", sampling_unit: "mw-user", other_assigned: { "experiment_name_2": "control", "experiment_name_3": "any_group" } } ``` Additionally, the xLab SDK will house the experiment manager API such that all current experiment-related methods will be removed from the EventLogging ResourceLoader module and moved into a new xLab ResourceLoader module ({T390089}). We can also take the opportunity to improve [[https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/blob/main/js/src/MetricsClient.js?ref_type=heads#L461|the way we are checking if the schema title supports experimentation]]. This feature was added for the web base schema 1.3.0 and, at this time, we are just checking the exact name and the version to be sure that the needed `experiments` fragment schema is there to fill the enrollment details. We should find a better way. In fact, the web base schema has been already updated a couple of times and the current way of doing that won't work properly. We could say something like the following: ``` if ( schemaID === '/analytics/product_metrics/web/base' && version(schemaID) >= 1.3.0 ) ``` == Acceptance Criteria [] Remove `mw.eventLog.isCurrentUserEnrolled()` [] Update `mw.eventLog.getCurrentUserExperiments()` to read experiment details from `wgMetricsPlatformUserExperiments` and prepare them according to the `experiment` schema fragment [] Decorate events with `enrolled`, `assigned`, `subject_id`, `sampling_unit` keys for experiment-related events, and `other_assigned` for all events as long as `coordinator` is set to `xlab` - [] Leave enrollment details as they are when `coordinator` is set to `custom`. `sampling_unit`, `subject_ids` and `other_assigned` won't be filled and we will assume that `enrolled` and `assigned` were filled by the custom coordinator - [] `coordinator` will be set to `forced` when the assigned group for the `enrolled` experiment has been overriden [] The way we check if the schema title supports experimentation has been improved/updated

== Description With the proposed updates to the experiment membership tracking schema (fragment proposed in T389995), we will need to update the javascript client library to supplements events i.e. be able to read and populate fields for the new `experiment` data object (to supercede the previously defined `experiments` data object) Proposed payload to be added to all events: ``` experiment: { enrolled: "2025-hoverlinks-blue-3", assigned: "a_group_name", subject_id: "0000001badb00200000ff1ce1badb002000000ff1ce0000000ff1ce0000000", sampling_unit: "mw-user", other_assigned: { "experiment_name_2": "control", "experiment_name_3": "any_group" } } ``` Additionally, the xLab SDK will house the experiment manager API such that all current experiment-related methods will be removed from the EventLogging ResourceLoader module and moved into a new xLab ResourceLoader module ({T390089}). We can also take the opportunity to improve [[https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/blob/main/js/src/MetricsClient.js?ref_type=heads#L461|the way we are checking if the schema title supports experimentation]]. This feature was added for the web base schema 1.3.0 and, at this time, we are just checking the exact name and the version to be sure that the needed `experiments` fragment schema is there to fill the enrollment details. We should find a better way. In fact, the web base schema has been already updated a couple of times and the current way of doing that won't work properly. We could say something like the following: ``` if ( schemaID === '/analytics/product_metrics/web/base' && version(schemaID) >= 1.3.0 ) ``` == Acceptance Criteria [] Remove `mw.eventLog.isCurrentUserEnrolled()` [] Update `mw.eventLog.getCurrentUserExperiments()` to read experiment details from `wgMetricsPlatformUserExperiments` and prepare them according to the `experiment` schema fragment [] Decorate events with `enrolled`, `assigned`, `subject_id`, `sampling_unit` keys for experiment-related events, and `other_assigned` for all events. as long as `coordinator` is set to `xlab` - [] Leave enrollment details as they are when `coordinator` is set to `custom`. `sampling_unit`, `subject_ids` and `other_assigned` won't be filled and we will assume that `enrolled` and `assigned` were filled by the custom coordinator - [] `coordinator` will be set to `forced` when the assigned group for the `enrolled` experiment has been overriden [] The way we check if the schema title supports experimentation has been improved/updated