1626372 - A metric type which supports recording non-negative integers (including 0)

Status: RESOLVED FIXED

(Data Platform and Tools Graveyard :: Glean Metric Types, enhancement, P1)

Description

[:Grisha Kruglov]

Proposal for changing an existing or adding a new Glean metric type

Who is the individual/team requesting this change?

Grisha Kruglov, on behalf of android-components and Fenix teams

Is this about changing an existing metric type or creating a new one?

Either loosening restrictions on the quantity metric, or introducing a new metric type which allows recording non-negative integers. That is, 0 must be a meaningful value that can be later queried.

Can you describe the data that needs to be recorded?

General question is "how many X is there, and do we have any at all?".
We've seen this in a few places by now, both in Fenix and in A-C - recording how many installed addons there are (and if user has any addons installed at all), how many pinned top sites there are (and if user has any pinned top sites), etc.

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)

How many addons user has installed, and is user using addons?
"not using addons" - 0
"using addons, with 1 installed" - 1
etc

What is the business question/use-case that requires the data to be recorded?

We need to be able to track usage data of our features that involve varying quantities.

How would the data be consumed?

We would like to see aggregated counts available on the GLAM dashboard (once it's available for mobile) and/or in redash queries.

Why existing metric types are not enough?

quantity appears to be exactly this, but it is restricted to a narrow (gecko) use case. boolean+counter combination serves this purpose, but it is cumbersome and non-obvious to people adding these metrics (e.g. we already shipped a bug as part of Fennec->Fenix nightly migrations where we'd fail to record absence of something, due to counter not supporting 0 values).
In code reviews, this needs to be called-out specifically because people miss the finer points of the counter metric type.

What is the timeline by which the data needs to be collected?

Metrics already shipping and being added currently that need to rely on counter+boolean workaround.

Comment 1

[Alessio Placitelli [:Dexter]]

Thanks for filing this. The process is currently on hold as we're waiting for the postmortem to happen after it was executed once on our first new metric type.

Comment 2

[Alessio Placitelli [:Dexter]]

For the specific use-case being highlighed here, the solution we're designing in bug 1631856 might work as well. We'll keep you in the review loop, Grisha.

Comment 4

[Alessio Placitelli [:Dexter]]

This is the proposal discussion document.

Mike, can you designate the group of people who should be working on the initial design for this?

Comment 5

[Alessio Placitelli [:Dexter]]

Hey Jan-Erik,

can you review this proposal from an SDK pov?

Comment 6

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Done!

Comment 7

[Alessio Placitelli [:Dexter]]

Hey folks,

the proposal document moved from design to comment stage. It is ready for one final look. Final feedback due by August 6th, 2020.

If that looks good to you, please sign off at the top of the document.

Comment 8

[Chris H-C :chutten]

Review complete, signed off.

Comment 9

[Chris [:wbeard] (EST)]

DS signed off.