We should make sure we have action.1 and/or save.1/unsave.1 events for installing and uninstalling add-ons.
Maybe this is something the add-ons team would be interesting in adding. I wonder if they have any plans for similar telemetry for desktop, or if they just rely on install data from AMO.
Bouncing over to Rebecca
Flags: needinfo?(amckay) → needinfo?(rweiss)
This could fall under the new events API for UI telemetry. Asking Georg for input.
Flags: needinfo?(rweiss) → needinfo?(gfritzsche)
What is the time-frame here for getting that data? We want to do the design process for the new UI Telemetry events format over the next two weeks, after that we will formally kick off the work for this. So we are probably shipping this in Fx51 (maybe Fx50 with uplift). If this bug can wait a little bit, we could cover this under the new API. For desktop specifically though, we already start new subsessions (i.e. a new ping) on addon install/uninstall/enable/disable. We only throttle this to a maximum of one new subsession start every 5 minutes.
:andym :kev Is this for Firefox for Android or Desktop or both? We should push to put everything under the new API as possible IMO. This will also need data review before we begin instrumentation. I'm now performing data reviews so I will try and collect the necessary questions that need answers prior to any engineering work.
(In reply to Rebecca Weiss from comment #5) > :andym :kev Is this for Firefox for Android or Desktop or both? The bug is originally filed against Android, but we should try and get the same data for both platforms. Does something like this exist on Desktop already?
So far we have what i mentioned in comment 4. You can between subsession check for changes in the list of active addons. But what kind of questions exactly do you want to answer? Maybe we can use the existing data, histograms or other mechanisms.
Kev's the best person to answer those questions I think.
Will add this to discussion on 1302681. Georg, at this point should we close this particular bug off? Questions were (and are) around lifecycles of add-on extensions. Essentially looking at an events vs. state snapshots, to get an understanding of: - Typical lifecycle of an add-on install - Effects of blocklists, compatibility changes, and other external events that change the status of an extension - Telemetry on disabled add-ons as well as enabled, including themes - Reduction of reliance on compatbility pings for add-on status
We could cover event-oriented instrumentation using the existing event APIs or with the additions from bug 1302681. I've updated Ben about the new capabilities and can help drafting how to get you the instrumentation you need. I can't say if this particular bug is useful. Maybe it makes sense to talk through / draft a higher-level instrumentation plan first, then go into specific implementation bugs?
You need to log in before you can comment on or make changes to this bug.