As a product manager, I want to understand how onboarding activities impact users based on the browser type they downloaded the Firefox stub installer from, so I can optimize onboarding based on the browser users come from. As a marketing manager, I want to understand the relative value of new users (retention/engagement) based on the type of browsers they downloaded Firefox from, so I can optimizemarketing activities. Requirements: - Collect browser type and version from the user agent string exposed when initiating the stub installer download - Add browser type and version to the attribution data passed on to the stub installer - The browser details are added to the stub installer success ping attribution data and then to the unified telemetry activation ping - The browser data can be processed through the data pipeline and be made available through the Presto churn table (sample query of what is available today https://sql.telemetry.mozilla.org/queries/3841/source?p_start_date=20170118#table) Proposed implementation: - Having the attribution service or bouncer capture the UA string would avoid website changes since the requesting browser will have sent that header to the service.
Here are some examples of attribution data and a few options: Existing payload: attribution.source=www.google.com attribution.medium=cpc attribution.campaign=fast-browser attribution.content=fastest New proposed attribution fields: Option 1: parse the UA string on mozilla.org and just pass in the browser name and version. Two new additional fields: attribution.browsername=Trident attribution.browserversion=11.0 Option 2: pass in the entire UA string and it can be parse on the reporting side. attribution.ua=Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko The benefit to option 2 is that it doesn't destroy data and it doesn't require mozilla.org to have any additional logic.
Summary: Add browser details to stub attribution data → Attribution service should handle the UA string data
Component: General → General
Product: Firefox → www.mozilla.org
Version: unspecified → Development/Staging
Julien, do you have an opinion on this?
This removes input validation entirely. It is generally a bad idea to access and reuse input without any validation, but I'm not sure what the actual impact is in this case. How urgent is this request, and can we perform a code review beforehand?
We're hoping to have this in place for 59 (it seems to make sense to do this along with bug 1414265 that also adds data to the attribution field and bug 1414265 tries to ship in 59 along with bug Bug 1414258 (install an add-on with a new Firefox installation).
You need to log in before you can comment on or make changes to this bug.