New Metric Type: Percentage Distribution (including keyed)
Categories
(Data Platform and Tools :: Glean Metric Types, enhancement, P4)
Tracking
(Not tracked)
People
(Reporter: chutten, Unassigned)
Details
(Whiteboard: [telemetry-parity])
Proposal for changing an existing or adding a new Glean metric type
Who is the individual/team requesting this change?
:chutten, for Project FOG
Is this about changing an existing metric type or creating a new one?
Could be either, but I think this should probably be its own new one.
Can you describe the data that needs to be recorded?
Distribution of percentage data. See VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE as an example of a keyed version: https://mzl.la/33q4KYa
We also may wish to support higher or lower resolutions of percentages, like how PLACES_TAGGED_BOOKMARKS_PERC is actually only recording deciles, and how WEBRTC_VIDEO_DECODE_ERROR_TIME_PERMILLE is recording 10*percentage (permille).
We may also wish to support a positive/negative spread like MEMORY_DISTRIBUTION_AMONG_CONTENT which goes from -100% to +100%, or even wider ranges where we're recording something as a proportion of something else like the CONTENT_FRAME_TIME_* family of probes. (( but maybe we want to explicitly descope these sincerely weird ones ))
Can you provide a raw sample of the data that needs to be recorded (this is in the abstract, and not any particular implementation details about its representation in the payload or the database)
I think the examples above illustrate it quite well, don't you?
What is the business question/use-case that requires the data to be recorded?
Various.
How would the data be consumed?
Measurement Dashboard-like displays (looking at you, GLAM) are the most common analysis tool I expect for these distributions.
Why existing metric types are not enough?
Custom Distributions are the only other possibility here and there are enough of these (at least 35 in Histograms.json by my count) that they should warrant their own type to benefit from bounds checking and other built-in errors, higher level abstractions leading to better tooling, and all sorts of other fun stuff.
What is the timeline by which the data needs to be collected?
Q1 2021 (is when I expect we'll start migrating in earnest and need an answer)
|
||
Updated•3 years ago
|
|
|
||
Comment 1•3 years ago
|
||
|
|
||
Comment 2•3 years ago
|
||
Hey Chris, Jan-Erik and Bea, what do you think of this? See comment 1.
|
||
Comment 3•3 years ago
|
||
A bit confusing to read because the discarded solution takes up so much more space.
I left questions on the new "what if we don't" solution.
|
Reporter | |
Comment 4•3 years ago
|
||
Looks workable, though I still worry there are enough cases today to warrant a "proper" metric type. Comments inline.
|
||
Comment 5•3 years ago
|
||
I am fine with the solution. I do think that the proposal is a bit vague on the reasons why the new metric type solution was discarded. Comments on the document.
One specific nit: please change the usage of "language bindings" to "SDKs" :)
|
|
||
Comment 6•2 years ago
|
||
Untaking, we're unlikely to implement this before Uniffi anyway.
|
||
Comment 8•2 years ago
|
||
I'm interested in recording the battery percentage (the actual question I would try to answer is: how many users do we have that stop using Firefox when the battery becomes empty, and so who would use Firefox more if Firefox used less power?). The metric type proposed here might be a good fit for this use case.
Description
•