安装归因

安装归因是一个允许我们执行以下操作的系统

  • 衡量营销活动的效果

  • 确定(大致)用户运行的安装程序的来源

  • 支持返回 AMO 的工作流程。

我们通过向 Firefox 安装程序添加归因代码来实现这些操作,该代码通常包含 www.mozilla.org(Bedrock 和相关服务)提供的信息。Firefox 在安装期间和安装后读取此信息,并通过 Firefox 遥测将其发送回 Mozilla。

此系统支持以下信息

  • 传统的 UTM 参数sourcemediumcampaigncontent

  • 实验

  • 变体

  • ua

  • dltoken

  • dlsource

  • msstoresignedin

这些内容的描述可以在 遥测环境文档 中找到。

Firefox Windows 安装程序和 macOS DMGs

通过 Windows 桩或完整 NSIS 安装程序或 macOS DMGs 完成的安装能够进行归因。在创建这些软件包时,会为其提供初始归因数据dlsource=mozillaci。通过 www.mozilla.org 下载软件包的用户通常会覆盖此归因数据(除非他们启用了“请勿跟踪”(DNT)),使用dlsource=mozorgdltoken 和 Bedrock 认为合适的任何 UTM 参数。

这里还有一个额外的复杂因素是,归因系统用于(或滥用,取决于你的看法)支持返回 AMO 的工作流程——强制campaigncontent UTM 参数为特定值。

下图说明了上述情况的流程

flowchart TD subgraph Legend direction LR start1[ ] --->|"(1) Bedrock,启用请勿跟踪"| stop1[ ] start2[ ] --->|"(2) Bedrock,禁用请勿跟踪"| stop2[ ] start3[ ] --->|"(3) 通过搜索引擎访问 Bedrock"| stop3[ ] start4[ ] --->|"(4) 通过返回 AMO 流程访问 Bedrock"| stop4[ ] start5[ ] --->|"(5) 从 CDN 来源直接下载"| stop5[ ] start6[ ] --->|"常见路径"| stop6[ ] %% Legend colours linkStyle 0 stroke-width:2px,fill:none,stroke:blue; linkStyle 1 stroke-width:2px,fill:none,stroke:green; linkStyle 2 stroke-width:2px,fill:none,stroke:red; linkStyle 3 stroke-width:2px,fill:none,stroke:purple; linkStyle 4 stroke-width:2px,fill:none,stroke:pink; end subgraph 下载流程 用户([用户]) 搜索[搜索引擎] AMO[AMO<br>addons.mozilla.org] Bedrock[Bedrock<br>mozilla.org] Bouncer[Bouncer<br>download.mozilla.org] CDNOrigin[CDN 来源<br>archive.mozilla.org] CDN[CDN<br>download-installer.cdn.mozilla.net] Attr[归因服务<br>stubdownloader.services.mozilla.net] AttrCDN[归因 CDN<br>cdn.stubdownloader.services.mozilla.net] Inst([下载的安装程序]) %% 案例 1:Bedrock,启用 DNT 用户 ----> Bedrock Bedrock ---->|"未设置归因数据"| Bouncer Bouncer ----> CDN CDN ---->|"包含静态归因数据:<br><i>dlsource</i>: mozillaci"| Inst linkStyle 6,7,8,9 stroke-width:2px,fill:none,stroke:blue; %% 案例 2:Bedrock,禁用 DNT 用户 ---> Bedrock linkStyle 10 stroke-width:2px,fill:none,stroke:green; %% 案例 3:通过搜索引擎访问 Bedrock 用户 ----> 搜索 搜索 ---->|"设置 UTM 参数"| Bedrock linkStyle 11,12 stroke-width:2px,fill:none,stroke:red; %% 案例 4:通过返回 AMO 流程访问 Bedrock 用户 ---->|"发起返回 AMO 请求"| AMO AMO ---->|"设置 <i>campaign</i> 和<br><i>content</i> UTM 参数"| Bedrock linkStyle 13,14 stroke-width:2px,fill:none,stroke:purple; %% 案例 5:从 CDN 直接下载 用户 --> CDNOrigin CDNOrigin -->|"包含静态归因数据:<br><i>dlsource</i>: mozillaci"| Inst linkStyle 15,16 stroke-width:2px,fill:none,stroke:pink; %% 所有情况的常见链接 Bedrock ---->|"转发归因数据:<br><i>dlsource</i>: mozorg<br><i>dltoken</i>: 存在<br>任何设置的 UTM 参数"| Bouncer Bouncer ---->|"转发归因数据"| Attr Attr <---->|"获取安装程序"| CDN Attr ---->|"将修改后的安装程序放置在归因 CDN 上"| AttrCDN AttrCDN ---->|"包含动态归因数据:<br><i>dlsource</i>: mozorg<br><i>dltoken</i>: 存在<br>任何设置的 UTM 参数"| Inst %% 所有情况的常见链接 CDN <---->|"获取安装程序"| CDNOrigin end

Windows

Windows 归因是通过在下载时将数据注入到 NSIS 安装程序的签名块中来实现的。此技术在 这篇 Microsoft 博客文章 的“欺骗 Authenticode”部分进行了描述。

macOS

macOS 归因是通过在下载时向 .app 捆绑包添加 com.apple.application-instance 扩展属性来实现的。根据 这篇 Apple 技术说明,此特殊的扩展属性明确地不是 .app 捆绑包数字签名的一部分。

Microsoft Store

通过 Microsoft Store 完成的 Firefox 安装支持提取可能嵌入其中的广告系列 ID。这使我们能够通过提供包含归因数据的特定链接到 Microsoft Store 来归因不同渠道的安装。例如

ms-windows-store://pdp/?productid=9NZVDKPMR9RD&cid=source%3Dgoogle.com%26medium%3Dorganic%26campaign%3D(not%20set)%26content%3D(not%20set)

https://www.microsoft.com/store/apps/9NZVDKPMR9RD?cid=source%3Dgoogle.com%26medium%3Dorganic%26campaign%3D(not%20set)%26content%3D(not%20set)

有关 Microsoft Store 环境中自定义广告系列 ID 的一般工作原理,请参阅 Microsoft 的文档

Microsoft Store 提供单个 cid(广告系列 ID)。他们的文档声称它限制为 100 个字符,尽管在我们自己的测试中,我们能够检索广告系列 ID 的前 208 个字符。Firefox 预期此广告系列 ID 遵循与桩和完整安装程序归因代码相同的格式,其最大长度为 1010 个字符。由于广告系列 ID 比 Firefox 允许的更受限制,因此我们需要更仔细地考虑在其中包含的内容与桩和完整安装程序归因相比。在撰写本文时,我们尚未能够测试我们是否能够在现实世界中可靠地提取超过广告宣传的 100 个字符的广告系列 ID——在我们发送任何关键信息超过前 100 个字符之前,我们应该进行此操作。

除了通过广告系列 ID 检索到的归因数据外,我们还会向其中添加一个额外的键,以指示用户在安装时是否登录了 Microsoft Store。此 msstoresignedin 键可以具有 truefalse 的值。

还有一些其他注意事项需要牢记

  • 仅在用户首次通过 Store 安装 Firefox 时设置广告系列 ID。后续安装将继承原始广告系列 ID(即使它是空字符串)。这意味着只有全新安装会被归因——而不是重新安装。

  • 在撰写本文时,尚不清楚未登录 Microsoft Store 完成的安装是否能够找到其广告系列 ID。Microsoft 的文档声称他们可以,但我们自己的测试尚未能够验证这一点。