Page MenuHomePhabricator

xLab UI should generate link for viewing experiment results in Superset
Closed, ResolvedPublic5 Estimated Story Points

Description

User story

As owner of an experiment which has been analyzed automatically, I want to easily navigate to the report (https://superset.wikimedia.org/superset/dashboard/experiment-analytics/) to view the results of my experiment without needing to browse through all the analyzed experiments and select my specific one.

Solution

We'll provide links to Superset and xLab's documentation from 1) the Instrumentation Directory (table Actions Menu) and 2) the experiment's read view page. Messages and links will vary depending on whether the experiments have been registered or have started (please consult specs). We'll prompt users to register their experiments right after configuration.

Acceptance criteria

  • When viewing a configured experiment in xLab, if the experiment is active or has concluded then the page should have a custom link to Superset. The link should take the user to the experiment analytics Superset dashboard with the Experiment filter pre-filled.
  • The link is clearly marked that the experiment must have been registered for automated analysis for the results to be available in Superset.
  • For all user traffic (edge unique-based) experiments, maybe there should be 3 links – one for each user auth segment: All, Logged-out only, and Logged-out only
NOTE: It is okay if the experiment was not actually analyzed with the system. The experiments filter will be set to the name of the experiment, but the dashboard will just not have any results.

Implementation notes

From https://www.blef.fr/superset-filters-in-url/#i-want-to-preselect-my-native-filters:

In order to filter you will have to feed the native_filters param with the following (awful) pattern. The param uses the RISON format which is a JSON serialization more friendly for url params. In this pattern you will have to replace:

  • <id> — contains the native filter id. You can get the filter id when you edit your "Dashboard properties" in the advance part by looking at the JSON metadata.
  • <column> — the column you want to filter on. Be careful you have to use the column name and not the filter name.
  • <value> — the value you want to select. Depending on what you want to do you can change the operation, in the example I use a op:IN but it can be something else.
native_filters=(NATIVE_FILTER-<id>:(__cache:(label:'<value>',validateStatus:!f,value:!('<value>')),extraFormData:(filters:!((col:<column>,op:IN,val:!('<value>')))),filterState:(label:'<value>',validateStatus:!f,value:!('<value>')),id:NATIVE_FILTER-<id>,ownState:()))

Testing this in Python:

uri_template = "https://superset.wikimedia.org/superset/dashboard/experiment-analytics/?native_filters=({native_filters})"

native_filter_template = "NATIVE_FILTER-{id}:(__cache:(label:'{value}',validateStatus:!f,value:!('{value}')),extraFormData:(filters:!((col:{column},op:IN,val:!('{value}')))),filterState:(label:'{value}',validateStatus:!f,value:!('{value}')),id:NATIVE_FILTER-{id},ownState:())"

experiment_name_params = {
    "id": "Cff2AKkC8",
    "column": "experiment_name",
    "value": "[DEMO] Reading (Balanced, Very Large)"
}
experiment_name_filter = native_filter_template.format(**experiment_name_params)

user_auth_segment_params = {
    "id": "2jhAiaKCI",
    "column": "user_auth_segment",
    "value": "Logged-out only"
}
user_auth_segment_filter = native_filter_template.format(**user_auth_segment_params)

native_filters = ','.join([experiment_name_filter, user_auth_segment_filter])

print(uri_template.format(native_filters = native_filters))

Produces

https://superset.wikimedia.org/superset/dashboard/experiment-analytics/?native_filters=(NATIVE_FILTER-Cff2AKkC8:(__cache:(label:'[DEMO] Reading (Balanced, Very Large)',validateStatus:!f,value:!('[DEMO] Reading (Balanced, Very Large)')),extraFormData:(filters:!((col:experiment_name,op:IN,val:!('[DEMO] Reading (Balanced, Very Large)')))),filterState:(label:'[DEMO] Reading (Balanced, Very Large)',validateStatus:!f,value:!('[DEMO] Reading (Balanced, Very Large)')),id:NATIVE_FILTER-Cff2AKkC8,ownState:()),NATIVE_FILTER-2jhAiaKCI:(__cache:(label:'Logged-out only',validateStatus:!f,value:!('Logged-out only')),extraFormData:(filters:!((col:user_auth_segment,op:IN,val:!('Logged-out only')))),filterState:(label:'Logged-out only',validateStatus:!f,value:!('Logged-out only')),id:NATIVE_FILTER-2jhAiaKCI,ownState:()))

which should take you to directly to "[DEMO] Reading (Balanced, Very Large)" experiment, "Logged-out only" user auth segment results.

Event Timeline

mpopov added a subscriber: JVanderhoop-WMF.

@JVanderhoop-WMF: Feel free to refine AC

For all user traffic (edge unique-based) experiments, maybe there should be 3 links – one for each user auth segment: All, Logged-out only, and Logged-out only

So looking forward to providing this key missing piece in xLab! 🎉

Please allow me to clarify some assumptions I made while reading the task description:

  1. Registering experiments for automated analysis:

The link is clearly marked that the experiment must have been registered for automated analysis for the results to be available in Superset.

How does the registration process look like currently? My assumption is (and we could validate this with help from users) that the expectation might be to always be able to access analytics after setting up an experiment. So I was wondering whether there could be a way to automate registration in Superset, unless that can cause issues (e.g., performance?).

  1. User segment links

For all user traffic (edge unique-based) experiments, maybe there should be 3 links – one for each user auth segment

To simplify and provide a single point of entry, I'd say that it'd be acceptable to just link to the All users view, and rely on experiment owners to adjust the filters if needed. But this might be something else we might want to validate.

The link is clearly marked that the experiment must have been registered for automated analysis for the results to be available in Superset.

How does the registration process look like currently?

https://wikitech.wikimedia.org/wiki/Metrics_Platform/Automated_analysis_of_experiments#Register_experiment

My assumption is (and we could validate this with help from users) that the expectation might be to always be able to access analytics after setting up an experiment. So I was wondering whether there could be a way to automate registration in Superset, unless that can cause issues (e.g., performance?).

Superset dashboard is just for reporting – formatting and navigating the results. There's a potential hypothesis for next year to make xLab a one-stop-shop and integrate the automated analytics MVP into it, but we are far from that. For now we have this separation of systems.

For all user traffic (edge unique-based) experiments, maybe there should be 3 links – one for each user auth segment

To simplify and provide a single point of entry, I'd say that it'd be acceptable to just link to the All users view, and rely on experiment owners to adjust the filters if needed. But this might be something else we might want to validate.

I think I would actually make that 1 link to the "Logged-out only" results, similar to how I did on the metrics overview dashboard – https://wikitech.wikimedia.org/wiki/Metrics_Platform/Automated_analysis_of_experiments#View_metric_across_experiments

Because inherently "All" will be somewhat untrustworthy due to logged-in users potentially dipping in and out of the experiment. So maybe we can replicate the ruleset of that dashboard and preselect:

  • "Logged-in only" for experiments using mw_user_id identifier type (that's the only segment)
  • "Logged-out only" for experiments using edge_unique identifier type

For now we have this separation of systems.

My question was rather: would it make sense to integrate these separate systems a bit better and avoid the manual registration of experiments? Maybe there's a way to make xLab automatically add an entry to the experiments_registry.yaml when an experiment is created to simplify the users' flow?

So maybe we can replicate the ruleset of that dashboard and preselect:
"Logged-in only" for experiments using mw_user_id identifier type (that's the only segment)
"Logged-out only" for experiments using edge_unique identifier type

That makes total sense 😀

My question was rather: would it make sense to integrate these separate systems a bit better and avoid the manual registration of experiments? Maybe there's a way to make xLab automatically add an entry to the experiments_registry.yaml when an experiment is created to simplify the users' flow?

It would require xLab to be aware of what metrics are in the metrics catalog, since the manually maintained registry is what connects experiments' configuration in xLab with metrics in the metrics catalog.

(Both of which would represent a huge increase in scope to current UI work.)

JVanderhoop-WMF moved this task from READY TO GROOM to Backlog on the Test Kitchen board.
Milimetric set the point value for this task to 2.
Milimetric changed the point value for this task from 2 to 5.
Milimetric raised the priority of this task from Medium to High.Jun 12 2025, 3:55 PM
Design exploration

Sharing the details of the current design exploration that searches to 1) provide access points to Superset from xLab and 2) deliver information regarding the need to register experiments in order to access results. Feedback on flows, copy, and absolutely anything would be much appreciated 🙏🏻

Accessing Superset results from xLab

1. Access from Instrumentation Directory: Registered experiment

Given that a user has registered their experiment for automated analysis
When they open the Actions menu in the Experiments and instruments table
Then they’ll find an option to 'View results in Superset' [A]

Screenshot 2025-06-27 at 17.11.18.png (538×1 px, 96 KB)

2. Access from Instrumentation Directory: Non-registered experiment

Given that a user hasn’t registered their experiment for automated analysis
When they open the Actions menu in the Experiments and instruments table
Then they'll find that the option 'View results in Superset' is disabled
And they’ll find a clarifying description and a 'Learn more' [B] link that takes them to the support docs

Screenshot 2025-06-27 at 17.11.48.png (608×1 px, 106 KB)

3. Access from experiment's read view page: Registered experiment

Given that a user has registered their experiment for automated analysis
When they access the experiment's Read view page
Then they’ll find a 'Results' section, with an option to 'Access dashboard on Superset' [A]
And a 'Check the documentation' link to guiding information in case they experience any access issues [C]

Screenshot 2025-06-27 at 17.13.05.png (562×1 px, 75 KB)

4. Access from experiment's read view page: Non-registered experiment

Given that a user hasn't registered their experiment for automated analysis
When they access the experiment's Read view page
Then they’ll find a 'Results' section with a message explaining why results aren't available
And a 'register your experiment' [D] link that takes them to supporting documentation

Screenshot 2025-06-27 at 17.12.22.png (487×1 px, 59 KB)

Guidance

(Besides relying on documentation), how might we inform users of the fact that they need to register their experiments in order to access the results from xLab?

5. Include information in creation confirmation message

Given that a user has successfully configured a new A/B test
When they are redirected to the Instrumentation Directory
Then they’ll find a success message that includes a note about automated analysis and a 'Register your experiment' [D] link

Screenshot 2025-06-27 at 17.13.55.png (522×1 px, 80 KB)

Links and URLs

[ A ] The 'View results in Superset' and 'Access dashboard on Superset' links takes users to a dashboard where one of the following options are pre-selected based on the user identifier type: "Logged-in only" for experiments using mw-user identifier type (that's the only segment), and "Logged-out only" for experiments using edge-unique identifier type

[ B ] 'Learn more' link's URL: https://wikitech.wikimedia.org/wiki/Experimentation_Lab/Automated_analysis_of_experiments#

[ C ] 'Check the documentation' link's URL: https://wikitech.wikimedia.org/wiki/Experimentation_Lab/Automated_analysis_of_experiments#View_experiment_results

[ D ] 'Register your experiment' links' URL: https://wikitech.wikimedia.org/wiki/Experimentation_Lab/Automated_analysis_of_experiments#Register_experiment

@Sarai-WMF These are great! Thanks so much for doing this work!

Accessing Superset results from xLab

1. Access from Instrumentation Directory: Registered experiment

Given that a user has registered their experiment for automated analysis

3. Access from experiment's read view page: Registered experiment

Given that a user has registered their experiment for automated analysis

For both of these there is another given which is that: experiment has started.

If the experiment is registered for analysis but the experiment has not started yet, maybe the link should be disabled? And similar to how you have "This experiment is not registered for automated analysis." maybe this could say "This experiment is registered for analysis but has not started."

I don't think we need to check for whether the experiment is turned on, because then we might have a scenario where experiment was on for a little bit and was analyzed and those results are available but then the experiment was turned off while it was underway, so then we would disable the link. So we can probably just limit it to two conditions: (1) registered for analysis, (2) current time is after start time.

Otherwise no notes – copy and design look excellent!

Guidance

(Besides relaying on documentation), how might we inform users of the fact that they need to register their experiments in order to access the results from xLab?

5. Include information in creation confirmation message

Love this! Thank you for thinking of this challenge and proposing a solution.

Thanks so much for your comments, @mpopov ! I really appreciate your review 🙏🏻

Regarding...

If the experiment is registered for analysis but the experiment has not started yet, maybe the link should be disabled? And similar to how you have "This experiment is not registered for automated analysis." maybe this could say "This experiment is registered for analysis but has not started."

That sounds good! Nevertheless, I was wondering whether offering an active link as soon as an experiment has been registered could be helpful to validate that the set-up is working. So, even if the link navigates experiment owners to an empty Superset board, that early access could help them make sure that they can indeed view results (e.g., have the right access permissions, etc).

On another note, I'm trying to find ways to wrap up hypothesis SDS2.4.13, which is currently off-track. Now that we have some design direction for this effort, I would like to reexamine my initial suggestion and propose that we consider this task out of the scope of 2.4.13. Would that sound acceptable? Can we foresee any negative consequences of doing that?

could be helpful to validate that the set-up is working

This would have to be validated in staging (mpic-next), right? If both production and staging refer to the same source of truth for which experiments are registered for analysis, we can just configure some experiments for different conditions.

  • Registered, results available:
    • sds2-4-11-synth-aa-test
    • sds2-4-11-synth-aa-test-2
  • Registered, no results (have not been conducted yet):
    • synth-aa-test-mw-js
    • synth-aa-test-mw-php
    • donation-link-phase-2
    • fy24-25-we-1-7-rc-grouping-toggle

And then every other experiment configured in staging is not registered.

could be helpful to validate that the set-up is working

This would have to be validated in staging (mpic-next), right? If both production and staging refer to the same source of truth for which experiments are registered for analysis, we can just configure some experiments for different conditions.

Sorry, I think I wasn't very clear! I meant that providing an active link by default would be helpful to enable users to validate that their set-up is working. As an experiment owner, if I verify that I can access Superset after going through the registration (and potentially access request) process, that'd be reassuring. On the other hand, we could add that helpful note that you suggested to the copy while the experiment hasn't started, to explain why there aren't any results being displayed: "This experiment is registered for analysis but has not started"

Ah! Okay, yeah that makes sense.

Hm, maybe something like: "This experiment is registered for analysis but has not started. When it launches and is analyzed, experiments will be available in Superset."

Definitely too wordy for the quick menu on home page, but maybe in read view?

This task's parent Epic was resolved coinciding with the conclusion of hypothesis SDS2.4.13 at the end of FY24-25. This pending subtask can be considered foundational/essential work now, and until we may decide whether it should be housed under a particular KR.

Sarai-WMF updated the task description. (Show Details)

Change #1171319 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] xLab: Deploy v0.7.9 release to staging

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

Change #1171319 merged by jenkins-bot:

[operations/deployment-charts@master] xLab: Deploy v0.7.9 release to staging

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

Change #1174756 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] xLab: Deploy v0.8.0 release to staging

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

Change #1174756 merged by jenkins-bot:

[operations/deployment-charts@master] xLab: Deploy v0.8.0 release to staging

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

Re-opening this ticket for refactoring based on:

  1. It broke staging - T400226: xLab: broken promise breaks staging << so original solution was reverted
  1. Per discussion with DP SREs, requesting the experiment registry (which lives in a gitlab repo) is a bad idea because it is not persistently reliable and access to it should not be relied upon at runtime.

Suggested alternatives:

  1. Include the repo as a submodule and read the yaml file
    • Con: xLab would need to be rebuilt and deployed every time the list is updated.
    • Pro: we have precedence for this approach -- we include canonical-data as a submodule to parse domain names and wikis for the frontend dropdown menu for adding wikis for samping.
  2. integrate the experiment-registry with confd/etcd which is Data Platform's gold-standard configuration database to serve experiment config.
    • Pro: it would provide reliable, persistent, up-to-date access to the experiment registry (no need for submodule inclusion and no dependency on deployments for including recently added experiments to the registry)
    • Con: unsure if implementation is complicated - probable cross-team dependencies

Based on discussions with the team, we will go with the lo-fi approach of including the experiment registry as a git submodule. It will only be updated when new releases of xLab are deployed to production.

Of the two options you outline, I'd go with Option 1. It's consistent with how you did the wikis. And the key factor for me is that configuring experiments this way is very much temporary in Mikhail's mind. Long term we'd want to pull this into xLab or phase it out in favor of Growthbook. So no reason setting up something more permanent around it.

Change #1185172 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] xLab: Deploy v1.0.0 release to staging

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

Change #1185172 merged by jenkins-bot:

[operations/deployment-charts@master] xLab: Deploy v1.0.0 release to staging

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

Change #1186616 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] xLab: Deploy v1.0.2 release to production

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

Change #1187027 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] xLab: Deploy v1.0.3 release to production

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

Change #1186616 abandoned by Clare Ming:

[operations/deployment-charts@master] xLab: Deploy v1.0.2 release to production

Reason:

in lieu of Ia43f3317fee8fff6e90bcbbc5875e9861d3cae09

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

Change #1187027 merged by jenkins-bot:

[operations/deployment-charts@master] xLab: Deploy v1.0.3 release to production

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