Experimenter presents this very rich information as the following:
It's not very useful: the CTR, which is naturally a percentage, is truncated to 0.01. The (absolute) raw numbers are not displayed. (Maybe I didn't include the correct things in the secondary outcome.)
In some way, I want a better display of this valuable information. I shouldn't have to query from the BQ tables directly to visualize this.
In my opinion, configuring this display should be part of the data definitions in the Jetstream TOML defined in https://github.com/mozilla/metric-hub. But I don't know if that's supported by the existing architecture.
How can we make the Jetstream front-end better serve consumers?
In https://experimenter.services.mozilla.com/nimbus/backgroundtaskmessage-notification-release-4pct-en/results#notification_clicks I have a
notification_clicks
metric with three statistics:identity
,sum
,binomial
.identity
counts 1 for each client ID;sum
counts 1 for each notification click;binomial
gives a confidence interval ofsum
divided byidentity
: the click-through rate.Experimenter presents this very rich information as the following:
It's not very useful: the CTR, which is naturally a percentage, is truncated to 0.01. The (absolute) raw numbers are not displayed. (Maybe I didn't include the correct things in the secondary outcome.)
In some way, I want a better display of this valuable information. I shouldn't have to query from the BQ tables directly to visualize this.
In my opinion, configuring this display should be part of the data definitions in the Jetstream TOML defined in https://github.com/mozilla/metric-hub. But I don't know if that's supported by the existing architecture.
How can we make the Jetstream front-end better serve consumers?
┆Issue is synchronized with this Jira Task