Closed
Bug 1290181
Opened 8 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•8 years ago
|
Flags: needinfo?(dzeber)
Comment 1•8 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•8 years ago
|
Points: --- → 2
Priority: -- → P2
Comment 2•8 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
•