1695236 - Explore allowing users to send a metric in all pings

Status: RESOLVED INCOMPLETE

(Data Platform and Tools :: Glean: SDK, defect, P3)

Description

[Michael Droettboom [:mdroettboom]]

I'm starting to wonder if this is a discussion worth having.

For the "distribution_id" use case in Fenix, the Fenix devs have a few options:

1. Work with the glean team on added a new core metric, which is kinda-sorta application specific in that how it would work for Fenix would be pretty closely tied to how Fenix is distributed, even if the concept of a "distribution channel" is fairly generic.
2. Add a new metric to only the metrics ping (this is what they did)
3. Add a new metric, listing all the pings explicitly (this is relatively easy, but would need to stay up to date as new custom or built-in pings are added)
4. Reusing "channel", which (maybe) doesn't map neatly onto this other dimension of distribution.

Providing an option for a user to add a metric to every ping may get most of the advantage of (1), while still being self-serve.

The obvious downside (and I think the reason we haven't allowed this so far) is that it could easily lead to all pings getting bloated if it's over-used. Additionally, the feature that pings aren't sent if they are empty would break (though perhaps we could treat "send on all pings" metrics specially in that case).

Just creating a bug to collect thoughts and see if it's worthy of a proposal.

Comment 1

[Jeff Klukas [:klukas] (UTC-4)]

Note that this "distribution_id" problem is one of the things that the short-term app-specific clients_last_seen ETL proposal is aiming to patch over. distribution_id is one of the string-type dimensions where we'd capture the latest value seen per client in metrics pings, and then join that to usage aggregates from baseline pings.

It would definitely be cleaner to have this in baseline pings, and be able to calculate usage aggregates grouped by distribution_id from baseline pings alone.

Comment 2

[Jan-Erik Rediger [:janerik]]

Attachment: Doc: [Glean] Experiment API Proposal

The proposal initially contained only changes to the experiments API, but it evolved into essentially what we need to support all-pings.