This message was deleted.

Hi Peter. I think this is a good suggestion. I think allowing people to define a "user population" source so that we know what "all users" consists of and then averaging over that population is a great option for the metrics page.

Is it a conscious decision to not use the set of all experimenters from all experiments to calculate the graphs in the metrics view?

Doing this as a default would be more expensive than just averaging the values in the conversion table, and the original intent of that view was to ensure that the metric was being defined correctly. We agree that adding more functionality to the metrics page would be valuable (e.g. the ability to merge with dimensions for dimensional slices, average over "all users").

Thanks for the answer! My best guess for your decision was efficiency and debugging purpose, too 😉 We found that people looking at the metrics page get confused by the choice of population size. If implementing a population size toggle feature takes a lots of resources, it can already help to communicate to users e.g. that this is not necessarily the metric values users see in the experiment. I didn’t find a hint on this in the documentation or GUI. We also observed that when people see the name of their favourite KPI and a graph, they tend to jump to using that graph in their argumentation and reasoning.

That makes sense! Thanks for your feedback 🙂