Add disabled_addon_ids from 'payload->addonDetails' to the Main Summary

RESOLVED FIXED

Status

Data Platform and Tools
Datasets: Main Summary
P1
normal
RESOLVED FIXED
11 months ago
10 months ago

People

(Reporter: Dexter, Assigned: Dexter)

Tracking

Details

Attachments

(2 attachments)

(Assignee)

Description

11 months ago
Starting from Firefox 57, legacy addons will be deactivated and won't be reported anymore in the Environment->activeAddons section [1]. We need the information about installed (but inactive) legacy addons to suggest similar addons to the users using TAAR.

For this reason, we'd like to add the "Payload->addonDetails" [2] section to the main summary table. We're really just interested in the GUIDs for each addon, not the content of each addon block.

> "addonDetails": {
>   "XPI": {
>     "adbhelper@mozilla.org": {
>       ... data
>     },
>     "other@mozilla.org": {
>       ... data
>     },    ...
>   },
>   ...
> }

We just want ["adbhelper@mozilla.org", "other@mozilla.org"] to be in "addon_details" column.

[1] - https://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/environment.html#activeaddons
[2] - https://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/main-ping.html#addondetails
(Assignee)

Updated

11 months ago
Blocks: 1380737
Priority: -- → P1

Comment 1

11 months ago
+1 on the above reasoning. The TAAR project team is aiming to deploy a shield study in mid September to evaluate the efficacy of personalized web extension recommendations based on a combined feature space derived from telelemtry information and installed addon information. 

It is essential that all information sources used in the shield study model are available in main_summary so that (if results are positive) that recommendation model can be updated as the addon ecosystem changes.
We want to remove addonDetails in favor of the environment in the future.
To avoid having more dependencies on this field, lets try to add only the minimal data points you need to the datasets.
E.g. can you limit this to adding a field with, say, only the ids of inactive addons?

How long into the future do you expect to use this?
(Assignee)

Comment 3

11 months ago
(In reply to Georg Fritzsche [:gfritzsche] from comment #2)
> We want to remove addonDetails in favor of the environment in the future.
> To avoid having more dependencies on this field, lets try to add only the
> minimal data points you need to the datasets.
> E.g. can you limit this to adding a field with, say, only the ids of
> inactive addons?

Yes, this shouldn't be a problem.

> How long into the future do you expect to use this?

I would expect this to be used just for FF 57-58.
(Assignee)

Updated

11 months ago
Assignee: nobody → alessio.placitelli
(Assignee)

Comment 4

11 months ago
Created attachment 8904198 [details] [review]
Main summary PR

This takes care of adding the list of inactive addon ids to the main summary, with a clear commit message/comment about the purpose and a note that it should not be used for stuff other than TAAR.
(Assignee)

Updated

11 months ago
Blocks: 1396543
Summary: Add the 'payload->addonDetails' to the Main Summary → Add disabled_addon_ids from 'payload->addonDetails' to the Main Summary
(Assignee)

Comment 5

10 months ago
Created attachment 8908504 [details] [review]
Docs PR
(Assignee)

Comment 6

10 months ago
The job is up and running and all the PR were merged. Documentation for the main summary was updated as well.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → FIXED
(Assignee)

Updated

10 months ago
Depends on: 1402000
You need to log in before you can comment on or make changes to this bug.