Right now, I can find installation.first_seen events for only about half of the new_profile pings that I see on Windows: query. This ticket tracks including this valuable information in our new_profile pings, helping us trace installation through to new profile creation.

Max and I looked into this a few days ago and it's more complicated than I realized.

• there is support for scalars in the new-profile ping (added in https://bugzilla.mozilla.org/show_bug.cgi?id=1570652), but it doesn't seem to have been used again
• the scalar used there is set very early during startup; the scalars in this ticket would need to block the ping
• perhaps the best approach is to kick off a promise for them when scheduling the ping (https://searchfox.org/mozilla-central/rev/edccfac5746704da49c1551aed8b79f57003bd68/toolkit/components/telemetry/app/TelemetryControllerParent.sys.mjs#1215) and await that promise before sending the ping (https://searchfox.org/mozilla-central/rev/edccfac5746704da49c1551aed8b79f57003bd68/toolkit/components/telemetry/app/TelemetryControllerParent.sys.mjs#1237)
• it's not clear that the new-profile ping testing would work unaltered
• but maybe these details should be cached and added to the environment? Generally we're trying to avoid adding to the environment.
• extracting the functionality from https://searchfox.org/mozilla-central/rev/edccfac5746704da49c1551aed8b79f57003bd68/browser/modules/BrowserUsageTelemetry.jsm#1244 into an async collection method for re-use shouldn't be hard.
• we'd also need to add quite a few scalars since we can't include arbitrary objects, AFAIK. (But maybe we can? That would be convenient.)

:chutten, can you advise on whether adding such scalars to this ping is acceptable? If it is, can you comment on a good approach to schedule collection before we send the ping? (Or redirect if somebody else is better positioned to advise.)

Thanks!

1. I see you've already noticed that Events in Custom Pings isn't something that's supported by Legacy Telemetry (This is not the last time I will recommend you consider Glean for this collection)
2. The delay in sending a "new-profile" ping was added to ensure we didn't send something before the user had a chance to opt out of data upload. Now we delete previously-sent data on data upload opt-out, so we can be a little more flexible about things like that.
3. "new-profile" ping supporting Scalars means if you shape the new collections as Scalars you don't need to hand-edit the schema to add them. You could add arbitrary JSON... and then write the schema for how that'll work when it hits the pipeline. (Or you can use Glean and take advantage of many fine metrics types (including events))
4. You would definitely need to update the tests, if only to add new ones to cover your added instrumentation. (Testing is friendlier with Glean)
5. Please don't add anything to the Environment unless you really need them to be included in almost every ping that Legacy Telemetry sends.
6. Alas, I'm the only person positioned near Legacy Telemetry just now (Jan-Erik's on PTO, and Alessio's priority is manager things). The ownership of the "new-profile" ping could live with its instrumenting team (but that's Alessio and me as the final survivors there (see bug 1120370) and we're no longer under Firefox, which is where the work request came from)... but anyhoo. It's me.

This collection: it's not a datetime is it? checks Oh, it's a bunch of cool stuff. Why isn't this its own (Glean, obv) Custom Ping? I mean, you'd be starting from scratch for history, but from the sounds of things you're anticipating needing to do that anyway?

Overall, if my oh-so-subtle nudges towards The Better Data Collection System aren't swaying you, then yes: I'd recommend going with Scalars in the "new-profile" ping. I can help consult on any problems you run into on the instrumentation and testing front, but I don't expect your array of Promises and scheduling would negatively interact with any existing guarantees. But we'll still want to allocate effort for validating from the data-side after landing that the changes don't interfere with the normal operation of the ping. (Maybe couch them behind a Nimbus feature so we can turn it on/off remotely?)

Oh, I guess I should sum up what :nalexander and I chatted about yesterday. This is seeming to be a "Scalars in the "new-profile" ping" sort of thing, the change in scheduling to ensure that the first_seen extras are present could induce some odd changes for "new-profile" pings with reason "shutdown" but nothing I'm worried about, and we should definitely make sure these changes are validated (and I maintain a Nimbus experiment+rollout is a good way to work it).

As always, I'm here to consult if you have any questions.

Depends on D176495

Depends on D176496

Max: I applied your work and started fixing up the test, which was tricky because of pre-existing issues that prevented using .only(). I haven't tried this on Windows and obviously I've not tested the Telemetry events yet, so I'm not sure where the patch stands. But hopefully this is helpful!

The following patch is waiting for review from an inactive reviewer:

:mpohle, could you please find another reviewer?

For more information, please visit BugBot documentation.