Mozilla accounts attribution¶
For products such as Mozilla VPN, Relay, and Monitor, we use Mozilla account as an authentication and subscription service. In addition to Google Analytics for basic conversion tracking, we attribute web page visits and clicks and through to actual subscriptions and installs by passing a specific allow-list of known query parameters through to the subscription platform. This is accomplished by adding referral data as parameters to sign up links on product landing pages.
How does attribution work?¶
When using any of the Mozilla accounts helpers in bedrock, a default set of attribution parameters are added to each account sign-in / subscription link on a product landing page. Here’s what we set for Mozilla VPN, as an example:
Name |
Description |
Example value |
---|---|---|
|
Query param identifying the referring site which sent the visitor. |
|
|
Query param identifying the type of link, such as referral, cost per click, or email. |
|
|
Query param identifying the specific marketing campaign that was seen. |
|
|
ID for which page of the website the request originates from (used for funnel analysis). |
|
|
ID that correlates to the active device being used (used for funnel analysis). |
Alpha numeric string |
|
The flow identifier. A randomly-generated opaque ID (used for funnel analysis). |
Alpha numeric string |
|
The time at which a flow event occurred (used for funnel analysis). |
Timestamp |
|
Product ID used for data analysis in BigQuery (optional). |
Alpha numeric string |
When performing data analysis, the default UTM values above are what we equate to “direct” traffic (i.e. someone came to the landing page directly then subscribed. They did not arrive from a specific marketing campaign or other channel).
If we do detect that someone came from a marketing campaign or other form of referral, then we have logic in place that will replace the default UTM parameters on each link with more specific referral data, so that we can attribute subscriptions to individual campaigns.
We also support passing several other optional referral parameters:
Name |
Description |
Example value |
---|---|---|
|
A coupon code that can be automatically applied at checkout (case sensitive). |
|
|
Experiment name ID. |
Alpha numeric string |
|
Experiment variation ID |
Alpha numeric string |
Attribution logic¶
See the Application Logic Flow Chart for a visual representation of the steps below (Mozilla access only).
A website visitor loads a product landing page in their web browser.
A JavaScript function then checks for and validates attribution data via a list of known URL parameters (see tables above).
If there are UTM parameters in the referral data, then those are used to replace the default values in each sign up link. Additionally if
coupon
orentrypoint_experiment
params found, those are also appended.If no UTM params exist, but there is a referrer cookie set, then the cookie value is used for
utm_campaign
andutm_source
is set towww.mozilla.org
. This cookie is often set when we display a “Get Mozilla VPN” promo on another mozorg page, such as/whatsnew
.If there’s no referrer cookie, we next look at
document.referrer
to see if the visitor came from a search engine. If found, we setutm_medium
asorganic
andutm_source
as the search engine name.Next, an metrics function makes a flow API request to the Mozilla accounts authentication server. The request returns a series of metrics parameters that are used to track progress through the sign-up process. These “flow” parameters are also appended to each sign up link in addition to the existing attribution data.
When someone clicks through and completes the sign up process, attribution data we passed through is emitted as event logs. This data is then joined to a person’s Mozilla account data during the Data Science team’s ETL process (Extract, Transform, Load), where data is then brought together in Big Query.
Note
UTM parameters on sign up links will only be replaced if the page
URL contains both a valid utm_source
and utm_campaign
parameter. All other UTM parameters are considered optional,
but will still be passed through, as long as the required
parameters exist. This is to avoid mixing referral data from
different campaigns.
Flow metrics¶
Whilst UTM parameters are passed through to sign up links automatically for any page of the website, in order for flow metrics to be added to links, a specific JavaScript bundle needs to be manually run in the page that requires it. The reason why it’s separate is that depending on the situation, flow metrics need to get queried and added at specific times and conditions (more on that below).
To add flow metrics to links, a page’s respective JavaScript bundle
should import and initialize the FxaProductButton
script.
import FxaProductButton from './path/to/fxa-product-button.es6.js';
FxaProductButton.init();
The above JS is also available as a pre-compiled bundle, which can be included directly in a template:
{{ js_bundle('fxa_product_button') }}
When init() is called, flow metrics will automatically be added to add account sign up links on a page.
Important
Requests to metrics API endpoints should only be made when an associated CTA is visibly displayed on a page. For example, if a page contains both a Mozilla accounts sign-up form and a Mozilla Monitor button, but only one CTA is displayed at any one time, then only the metrics request associated with the visible CTA should occur.
Note
For links generated using the fxa_link_fragment
helper, you
will also need to manually add a CSS class of js-fxa-product-button
to trigger the script.
Google Analytics guidelines¶
For GTM datalayer
attribute values
in Mozilla account links, please use the analytics documentation.