Add add-on data to main_summary view

RESOLVED FIXED

Status

defect
P2
normal
RESOLVED FIXED
3 years ago
6 months ago

People

(Reporter: rvitillo, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

User Story

We'd like to add the add-on data from UT pings into the main_summary dataset so that we can easily do analyses involving add-ons at 100%. There are a number of projects planned for add-ons this quarter, and this will support those efforts in two main ways:
- Quickly extracting add-on data from UT in conjunction with other session-level summary measures (eg. activity) to facilitate in-depth analyses
- Enabled easier and faster add-on reporting for the add-ons team

One of the main reasons for working with add-ons at 100% is the fact that the vast majority are extremely rare (the "long tail"), but we often want to report on specific add-ons.

Attachments

(1 attachment)

Comment hidden (empty)
Flags: needinfo?(dzeber)
I propose adding data that looks something like this:

|-- enabled_addons: array // an array of the currently enabled addons:
                         // environment.addons.activeAddons, converted to an array with the ID added to each element 
     |-- element: struct
          |-- id: string // addon ID: key in environment.addons.activeAddons dict
          |-- blocklisted: boolean
          |-- name: string
          |-- user_disabled: boolean // probably don't need these (assuming only enabled are reported in UT)
          |-- app_disabled: boolean // 
          |-- version: string
          |-- scope: integer
          |-- type: string // "extension"/"service"/...
          |-- foreign_install: boolean
          |-- has_binary_components: boolean
          |-- install_day: long // days since Unix epoch, like profile_creation_date
          |-- update_day: long // same
          |-- signed_state: integer
          |-- is_system: boolean
|-- active_theme: struct // the current active theme: environment.addons.theme
    |-- id: string
    |-- blocklisted: boolean
    |-- name: string
    |-- user_disabled: boolean // probably don't need these (assuming only enabled are reported in UT)
    |-- app_disabled: boolean // 
    |-- version: string
    |-- scope: integer
    |-- foreign_install: boolean
    |-- has_binary_components: boolean
    |-- install_day: long // days since Unix epoch, like profile_creation_date
    |-- update_day: long // same
|-- persona: string // id of the current persona: environment.addons.persona 
|-- blocklist_enabled: boolean // environment.settings.blocklistEnabled
|-- addon_compatibility_check_enabled: boolean // environment.settings.addonCompatibilityCheckEnabled
|-- telemetry_enabled: boolean // environment.settings.telemetryEnabled

The main changes from UT are to convert addons from an ID -> details mapping to an array of {ID, details}. Also, I think we can drop the text descriptions here since they are rarely used in analysis and can be looked up. However, I recommend keeping the name field.
User Story: (updated)
Flags: needinfo?(dzeber)

Updated

3 years ago
Points: --- → 2
Priority: -- → P2
Based on the discussion at [1], the 'persona' field (ID of the current persona) is something that can be determined from the current theme (active_theme.id) and hence is not needed.

If the current active theme is a persona, the active theme ID will be of the form <themeID>@personas.mozilla.org, and the persona ID will be <themeID>.

[1] https://mail.mozilla.org/pipermail/fhr-dev/2016-August/001015.html
See Also: → 1300224
This has been deployed, data beginning to be available on 2016-11-02
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

6 months ago
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.