Closed
Bug 1290181
Opened 9 years ago
Closed 8 years ago
Add add-on data to main_summary view
Categories
(Cloud Services Graveyard :: Metrics: Pipeline, defect, P2)
Cloud Services Graveyard
Metrics: Pipeline
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rvitillo, Unassigned)
References
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 file)
No description provided.
|
Reporter | |
Updated•9 years ago
|
Flags: needinfo?(dzeber)
|
||
Comment 1•9 years ago
|
||
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•9 years ago
|
Points: --- → 2
Priority: -- → P2
|
|
||
Comment 2•9 years ago
|
||
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
|
||
Comment 3•8 years ago
|
||
|
||
Comment 4•8 years ago
|
||
This has been deployed, data beginning to be available on 2016-11-02
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
|
||
Updated•6 years ago
|
Product: Cloud Services → Cloud Services Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•