Attribution service should handle the UA string data

NEW
Unassigned

Status

enhancement
2 years ago
3 months ago

People

(Reporter: RT, Unassigned)

Tracking

(Blocks 2 bugs)

Development/Staging
Dependency tree / graph

Firefox Tracking Flags

(firefox57 wontfix)

Details

User Story

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.
Comment hidden (empty)
(Reporter)

Updated

2 years ago
(Reporter)

Updated

2 years ago
User Story: (updated)
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.
Severity: normal → enhancement
(Reporter)

Updated

2 years ago
Summary: Add browser details to stub attribution data → Attribution service should handle the UA string data
(Reporter)

Updated

2 years ago
Blocks: 1414258
(Reporter)

Updated

2 years ago
Component: General → General
Product: Firefox → www.mozilla.org
Version: unspecified → Development/Staging
(Reporter)

Updated

2 years ago
User Story: (updated)
Julien, do you have an opinion on this?
Flags: needinfo?(jvehent)
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?
Flags: needinfo?(jvehent)
(Reporter)

Comment 4

2 years ago
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).
Flags: needinfo?(jvehent)
Flags: needinfo?(jvehent)
You need to log in before you can comment on or make changes to this bug.