Update Firefox Desktop Attribution docs (#13015)

This commit is contained in:
Alex Gibson 2023-05-04 15:26:23 +01:00 коммит произвёл GitHub
Родитель 211c9efd81
Коммит 1b843ec041
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: 4AEE18F83AFDEB23
3 изменённых файлов: 184 добавлений и 129 удалений

Просмотреть файл

@ -0,0 +1,183 @@
.. This Source Code Form is subject to the terms of the Mozilla Public
.. License, v. 2.0. If a copy of the MPL was not distributed with this
.. file, You can obtain one at https://mozilla.org/MPL/2.0/.
.. _firefox_desktop_attribution:
===========================
Firefox Desktop Attribution
===========================
Firefox Desktop Attribution (often referred to as Stub Attribution) is a system
that enables Mozilla to link website attributable referral data (including Google
Analytics data) to a user's Firefox profile. When a website visitor lands on
www.mozilla.org and clicks to download Firefox, we pass attribution data about
their visit to the Firefox installer for inclusion in `Telemetry`_. This is to
enable Mozilla to better understand how things like changes to our website and
different marketing campaigns can affect installation rates, as well as overall
product retention. The data also gives us an insight into how many installations
originate from www.mozilla.org, as opposed to elsewhere on the internet.
Scope and requirements
----------------------
- Attribution was originally only possible via the Firefox stub installer on Windows
(hence the name *stub attribution*), however it now also works on full installer
links, and across all Windows desktop release channels.
- Attribution is still limited to devices running a Windows OS. The flow does not
yet work for macOS and Linux users. It also does not work for Android or iOS
devices.
- Attribution will only be passed if a website visitor has their
`Do Not Track (DNT)`_ preference disabled in their browser. Visitors can opt-out
by enabling DNT. This is covered in our `privacy policy`_.
.. _Telemetry: https://telemetry.mozilla.org/
.. _Do Not Track (DNT): https://support.mozilla.org/kb/how-do-i-turn-do-not-track-feature
.. _privacy policy: https://www.mozilla.org/privacy/websites/
How does attribution work?
--------------------------
See the `Application Logic Flow Chart`_ for a more detailed visual representation
of the steps below (Mozilla access only).
#. A user visits a page on www.mozilla.org. On page load, a `JavaScript
function`_ collects referral and analytics data about from where their visit
originated (see the table below for a full list of attribution data we collect).
#. Once the attribution data is validated, bedrock then generates an attribution
session ID. This ID is included in the user's attribution data, and is also sent
to Google Analytics as a non-interaction event.
#. Next we send the attribution data to an authentication service that is part of
bedrock's back-end server. The data is validated again, then base64 encoded and
returned to the client together with an signed, encrypted signature to prove that
the data came from www.mozilla.org.
#. The encoded attribution data and signature are then stored as cookies in
the users web browser. The cookies have the IDs ``moz-stub-attribution-code``
(the attribution code) and ``moz-stub-attribution-sig`` (the encrypted signature).
Both cookies have a 24 hour expiry.
#. Once the user reaches a Firefox download page, bedrock then checks if both
attribution cookies exist, and if so appends the authenticated data to the
Firefox download link. The query parameters are labelled ``attribution_code``
and ``attribution_sig``.
#. When the user clicks the Firefox download link, another attribution service
hosted at ``download.mozilla.org`` then decrypts and validates the attribution
signature. If the secret matches, a unique download token is generated. The
service then stores both the attribution data (including the Google Analytics
client ID) and the download token in Mozilla's private server logs.
#. The service then passes the download token and attribution data (excluding the
GA client ID) into the installer being served to the user.
#. Once the user installs Firefox, the data that was passed to the installer is
then stored in the users' Telemetry profile.
#. During analysis, the download token can be used to join Telemetry data
with the corresponding GA data in the server logs.
.. _Application Logic Flow Chart: https://www.figma.com/file/q5mJpicWBpzAYuQ3fV00ix/Firefox-Stub-Attribution-Flow?node-id=0%3A1&t=EFe91WQzQ7cXHSiB-1
.. _JavaScript function: https://github.com/mozilla/bedrock/blob/main/media/js/base/stub-attribution.js
Attribution data
----------------
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| Name | Description | Example |
+============================+==========================================================================================+=================================+
| ``utm_source`` | Query param identifying the referring site which sent the visitor. | ``utm_source=google`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``utm_medium`` | Query param identifying the type of link, such as referral, cost per click, or email. | ``utm_medium=cpc`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``utm_campaign`` | Query param identifying the specific marketing campaign that was seen. | ``utm_campaign=fast`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``utm_content`` | Query param identifying the specific element that was clicked. | ``utm_content=getfirefox`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``referrer`` | The domain of the referring site when the link was clicked. | ``google.com`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``ua`` | Simplified browser name parsed from the visitor's User Agent string. | ``chrome`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``experiment`` | Query param identifying an experiment name that visitor was a cohort of. | ``taskbar`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``variation`` | Query param identifying the experiment variation that was seen by the visitor. | ``[a|b]`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``client_id`` | Google Analytics Client ID. | ``1715265578.1681917481`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``session_id`` | A random 10 digit string identifier used to associate attribution data with GA session. | ``9770365798`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
| ``dlsource`` | A hard-coded string ID used to distinguish mozorg downloads from archive downloads | ``mozorg`` |
+----------------------------+------------------------------------------------------------------------------------------+---------------------------------+
.. Note::
If any of the above values are not present then a default value of ``(not set)``
will be used.
Cookies
-------
The cookies created during the attribution flow are as follows:
+-------------------------------+----------------------------------------+-----------------------+-------+----------+
| Name | Value | Domain | Path | Expiry |
+===============================+========================================+=======================+=======+==========+
| ``moz-stub-attribution-code`` | Base64 encoded attribution string | ``www.mozilla.org`` | ``/`` | 24 hours |
+-------------------------------+----------------------------------------+-----------------------+-------+----------+
| ``moz-stub-attribution-sig`` | Base64 encoded signature | ``www.mozilla.org`` | ``/`` | 24 hours |
+-------------------------------+----------------------------------------+-----------------------+-------+----------+
Measuring campaigns and experiments
-----------------------------------
Firefox Desktop Attribution was originally designed for measuring the effectiveness of
marketing campaigns where the top of the funnel was outside the remit of www.mozilla.org.
For these types of campaigns, stub attribution requires zero configuration. It just works
in the background and passes along any attribution data that exists.
It is also possible to measure the effectiveness of experiments on installation rates and
retention. This is achieved by adding optional ``experiment`` and ``variation``
parameters to a page URL. Additionally, these values can also be set via JavaScript
using:
.. code-block:: javascript
Mozilla.StubAttribution.experimentName = 'experiment-name';
Mozilla.StubAttribution.experimentVariation = 'v1';
.. Note::
When setting a experiment parameters using JavaScript like in the example above,
it must be done prior to calling ``Mozilla.StubAttribution.init()``.
Return to addons.mozilla.org (RTAMO)
------------------------------------
`Return to AMO`_ (RTAMO) is a Firefox feature whereby a first-time installation onboarding
flow is initiated, that redirects a user to install the extension they have chosen whilst
browsing `AMO`_ using a different browser. RTAMO works by leveraging the existing stub
attribution flow, and checking for specific ``utm_`` parameters that were passed if the
referrer is from AMO.
Specifically, the RTAMO feature looks for a ``utm_content`` parameter that starts with ``rta:``,
followed by an ID specific to an extension. For example: ``utm_content=rta:dUJsb2NrMEByYXltb25kaGlsbC5uZXQ``.
The stub attribution code in bedrock also checks the referrer before passing this on, to
make sure the links originate from AMO. If RTAMO data comes from a domain other than AMO,
then the attribution data is dropped.
RTAMO initially worked for only a limited subset of addons recommended by Mozilla. This
functionality was recently expanded by the AMO team to cover all publically listed addons,
under a project called `Extended RTAMO (ERTAMO)`.
.. _AMO: https://addons.mozilla.org/firefox/
.. _Return to AMO: https://wiki.mozilla.org/Add-ons/QA/Testplan/Return_to_AMO
Local testing
-------------
For stub attribution to work locally or on a demo instance, a value for the HMAC key
that is used to sign the attribution code must be set via an environment variable e.g.
.. code-block:: html
STUB_ATTRIBUTION_HMAC_KEY=thedude
.. Note::
This value can be anything if all you need to do is test the bedrock functionality.
It only needs to match the value used to verify data passed to the stub installer
for full end-to-end testing via Telemetry.

Просмотреть файл

@ -1,128 +0,0 @@
.. This Source Code Form is subject to the terms of the Mozilla Public
.. License, v. 2.0. If a copy of the MPL was not distributed with this
.. file, You can obtain one at https://mozilla.org/MPL/2.0/.
.. _firefox_stub_attribution:
========================
Firefox Stub Attribution
========================
Stub Attribution is a process that enables the construction and transmission
of marketing attribution code for Firefox desktop on www.mozilla.org. When a user
visits a mozilla.org download page, the website constructs an attribution code,
which is then passed to download.mozilla.org via a URL parameter. This attribution
code is then passed to the Windows stub installer, where it finally gets passed to
Firefox for use in Telemetry. This attribution funnel enables Mozilla to better
understand how different marketing campaigns effect overall retention in Firefox.
How does it work in bedrock?
----------------------------
The base template in bedrock contains a stub attribution script that runs on every
page of the website. The script only runs on Windows (since the stub installer is a
Windows feature) and if cookies are enabled. The script also respects Do Not Track,
so it will not run if the user agent has this flag set.
The stub attribution script looks for ``utm_*`` params on the page URL, as well
``document.referrer`` and various other values, and then creates a hash of that
data by passing it to an authentication service in bedrock. This hash is then
accompanied by a signed, encrypted signature to prove that the data came from a
trusted source. Both pieces of authenticated data are then stored in a cookie with
a 24 hour expiry.
The full list of data values we pass to stub attribution is as follows:
- ``utm_source`` (``?utm_source=`` query parameter)
- ``utm_medium`` (``?utm_medium=`` query parameter)
- ``utm_campaign`` (``?utm_campaign=`` query parameter)
- ``utm_content`` (``?utm_content=`` query parameter)
- ``referrer`` (``document.referrer``)
- ``ua`` (simplified browser name parsed from UA string, e.g. ``chrome``, ``safari``, ``firefox``).
- ``experiment`` (``?experiment=`` query parameter)
- ``variation`` (``?variation=`` query parameter)
- ``client_id`` (``clientId`` client ID from Google Analytics (GA))
- ``session_id`` (random 10 digit string identifier used to associate Telemetry data with GA session).
- ``dlsource=mozorg`` (used to distinguish mozorg downloads from archive downloads)
.. Note::
If any of the above values are not present then a default value of ``(not set)``
will be used.
The cookies created during the stub attribution flow are called:
- ``moz-stub-attribution-code`` (base64 encoded attribution data string)
- ``moz-stub-attribution-sig`` (encrypted signature)
Once the user reaches the download page, bedrock then checks if the cookie exists,
and if so appends the authenticated data to the download URL. The query parameters
added to the download URLs are labeled as:
- ``attribution_code`` (value of ``moz-stub-attribution-code``)
- ``attribution_sig`` (value of ``moz-stub-attribution-sig``)
Once a visitor clicks the download link, the rest of the process is handled by the
download service and stub installer.
Local testing
-------------
For stub attribution to work locally or on a demo instance, a value for the HMAC key
that is used to sign the attribution code must be set via an environment variable e.g.
.. code-block:: html
STUB_ATTRIBUTION_HMAC_KEY=thedude
.. Note::
This value can be anything if all you need to do is test the bedrock functionality.
It only needs to match the value used to verify data passed to the stub installer
for full end-to-end testing via Telemetry.
Measuring campaigns and experiments
-----------------------------------
Stub Attribution was originally designed for measuring the effectiveness of marketing
campaigns where the top of the funnel was outside the remit of www.mozilla.org. For
these types of campaigns, stub attribution requires zero configuration. It just works
(as configured in ``/media/js/base/stub-attribution.js``) in the background and passes
along any attribution data that exists.
More recently, the ability to measure the effectiveness of experiments was also added
as a feature. This is achieved by adding optional ``experiment`` and ``variation``
parameters to a page URL. Additionally, these values can also be set via JavaScript
using:
.. code-block:: javascript
Mozilla.StubAttribution.experimentName = 'experiment-name';
Mozilla.StubAttribution.experimentVariation = 'v1';
.. Note::
When setting a experiment parameters using JavaScript like in the example above,
it must be done prior to calling ``Mozilla.StubAttribution.init()``.
Return to addons.mozilla.org (RTAMO)
------------------------------------
`Return to AMO`_ (RTAMO) is a Firefox feature whereby a first-time installation onboarding
flow is initiated, that redirects a user to install the extension they have chosen whilst
browsing `AMO`_ using a different browser. RTAMO works by leveraging the existing stub
attribution flow, and checking for specific ``utm_`` parameters that were passed if the
referrer is from AMO.
Specifically, the RTAMO feature looks for a ``utm_content`` parameter that starts with ``rta:``,
followed by an ID specific to an extension. For example: ``utm_content=rta:dUJsb2NrMEByYXltb25kaGlsbC5uZXQ``.
The stub attribution code in bedrock also checks the referrer before passing this on, to
make sure the links originate from AMO. If RTAMO data comes from a domain other than AMO, then the
attribution data is dropped.
RTAMO initially worked for only a limited subset of addons recommended by Mozilla. This
functionality was recently expanded by the AMO team to cover all publically listed addons,
under a project called `Extended RTAMO (ERTAMO)`.
.. _AMO: https://addons.mozilla.org/firefox/
.. _Return to AMO: https://wiki.mozilla.org/Add-ons/QA/Testplan/Return_to_AMO

Просмотреть файл

@ -41,7 +41,7 @@ Contents
funnelcake
abtest
analytics
firefox-stub-attribution
firefox-desktop-attribution
vpn-affiliate-attribution
architectural-decisions
browser-support