谷歌分析中会话拼接的 4 种基本方法

只需单击一下，用户就可以销毁 Google Analytics 数据：从 AMP 页面移动到主站点或从主站点移动到支付处理器可以将一次访问变成多个会话，并在此过程中弄乱源数据。

至关重要的是，这些点击通常发生在高价值的过渡点——从匿名访问者到登录用户，或者从购买前到购买后的时刻。

会话拼接修复技术故障线，保留干净的分析数据并挽救归因信息。 这篇文章涵盖了四个常见用例：

1. 用户 ID 跟踪
2. AMP跟踪
3. 子域跟踪
4. 跨域跟踪

什么是会话拼接？

在 Google Analytics 中，会话拼接连接发生在单个会话中的用户活动，但由于技术跟踪限制，错误地生成了多个会话。

任何拼接会话的努力都取决于两个要素，Simo Ahava 详细介绍了这些要素：

• 跟踪到相同 Google Analytics 媒体资源 ID (UA-XXXXXX-Y) 的跟踪器对象
• 具有相同客户端 ID 的 _ga cookie

现代浏览器不允许来自一个域的站点与另一个域共享 cookie。 克服这一限制是修补会话的核心，否则会撕裂。

数字营销人员比 Google 更频繁地使用“会话拼接”一词，而 Google 最近更喜欢另外两个术语：

1. 会话统一。 “会话统一允许在分配用户 ID 之前收集的点击与 ID 相关联。”
2. 网站链接。 “跨域跟踪使 Analytics 可以将其视为单个用户的单个会话。 这有时称为站点链接。”

值得注意的是，关于会话统一的 Google Analytics 支持文章在图像替代文本和标题中保留了“会话拼接”一词（为了好奇）； Google AMP Client ID API 的支持文章中还出现了对会话拼接的杂散参考。

在本文中，我使用会话拼接是一个总括性术语，它包括对在单个会话中发生的用户活动进行正确分组的所有努力。 正如 Yehoshua Coren 所指出的，潜在的技术现实比术语更重要：“它真的不止于此。 这是一个 clientId 完整性问题。”

无论您怎么称呼它，挑战都会影响几乎每个站点的数据质量和归因。

谁应该最关心会话拼接？

会话拼接对每个站点都很有用，但对一些站点来说必不可少：

• 有登录的网站。 具有登录功能的站点依靠“会话统一”来收集有关导致用户登录的事件的数据。
• AMP 重站点。 当用户从 AMP 页面迁移到本地托管的非 AMP 页面时，正确的跟踪会保留归因数据。
• 大型多领域组织。 当用户跨域（或子域）迁移时，多个域需要跨域跟踪以保留归因信息。
• 具有第三方支付处理商的网站。 如果没有会话拼接，依赖第三方支付处理器的网站可能会丢失电子商务转化的归因数据。
• 使用社交登录的网站。 与第三方支付处理器一样，社交登录可能会错误地将登录后用户重新分类为来自社交网络的推荐人。
• 带有 iframe 表单的站点。 iframe 在您网站的页面中嵌入了跨域跟踪挑战。

1.用户ID追踪

对于具有登录功能的网站，用户 ID 跟踪会随着时间的推移连接多次访问——例如，允许企业查看哪些 SaaS 功能与客户产生共鸣。

会话统一将登录前活动与登录后用户 ID 结合起来——从两者创建一个会话。 这样，您就可以看到登录之前的哪些行为，如果该登录代表了一个转换点，那么这些行为就特别有价值。

因此，会话统一不是仅捕获第二个会话的一部分（第一张图片），而是将登录前点击量（白色）与登录后点击量（蓝色）结合起来：

重要的是，会话统一仅在“这些命中发生在第一次分配特定 ID 值的同一会话中”时才连接命中。 换句话说，它包括来自登录前会话的数据，而不是之前的会话。

谷歌分析在日常分析处理期间应用会话统一——“每天凌晨 5 点，基于在与资产相关的任何报告视图中选择的最西端时区。”

这种时间滞后可能会导致“在日内日期期间更高的直接会话和直接收入，因为 [. . .] 活动推荐信息是在用户尚未登录的会话的第一次点击期间发送的。”

默认情况下，会话统一在您设置用户 ID 跟踪时切换为开。 你为什么要关掉它？ 我问过我们 Speero 机构分析师之一的 Silver Ringvee。 虽然他没有看到明显的用例，但他推测了一个潜在的用例：

但是，在某些情况下，您确实希望关注实际登录的用户（而不是在旅程的某个时刻登录的用户）。 因此，如果您不关心在他们获得 ID 之前发生的事情，您可能希望将其关闭。

您可以在 Admin > Property > Tracking Info > User-ID 中关闭会话统一：

虽然用户 ID 跟踪与预期登录的站点（例如 SaaS、电子商务）最相关，但还有其他方法可以激励登录。 例如，像 Quora 和 Glassdoor 这样的网站会在登录墙后面屏蔽高价值的内容。

对于这些登录类型，会话统一提供了关于最吸引人的内容的重要数据 - 促进登录和注册的答案或文章。

2. AMP 跟踪

Google 的 AMP 推出造成了跟踪问题：来自搜索的 AMP 点击将用户带到“缓存上的 AMP”版本，该版本托管在 Google 的 CDN 上。

正如 Perficient 的 Eric Enge 告诉我的那样，“很多人仍然没有正确理解这一点。 大多数发布商都失去了跟踪跨域（从 Google 缓存到您的实际域）的微妙之处。”

最终，用户可以通过以下三种方式之一访问 AMP 页面； 每个都会影响客户端 ID 的存储位置：

1. 谷歌搜索。 AMP 页面可通过 Google 搜索结果访问并显示在“AMP 查看器”中。 客户 ID 存储在 google.com 上。
2. 代理/缓存。 从代理/缓存访问 AMP 页面。 客户 ID 存储在 cdn.ampproject.org 上。
3. 直接放大器。 AMP 页面可直接在发布商域上访问。 客户端 ID 存储在发布者域中。

在前两种情况下，从 AMP 页面点击发布商网站上的另一个页面会生成引荐和新会话，而不是将点击计为单个会话中的第二次互动。

如果不加以管理，由此产生的分析数据会遇到几个问题：

• 膨胀的会话计数
• AMP 页面的高跳出率
• AMP 页面的每个会话/会话持续时间的页面数较少

与其他会话拼接问题一样，解决方案是在不同域的页面之间传递相同的客户端 ID，谷歌通过 AMP 客户端 ID API 实现了这一点。

如何使用 Google AMP API 传递相同的 Client ID

设置 AMP 跟踪有两个步骤：分析代码更改和引荐排除。

1. 分析代码更改。 正确的 AMP 跟踪始于对 AMP 和非 AMP 页面上的 Google Analytics 代码的少量添加。 Google 提供了有关如何对 analytics.js、gtag.js 和 Google 跟踪代码管理器进行更改的详细信息。

由于一些浏览器拒绝第三方 cookie，谷歌于 2018 年 9 月发布了 AMP 链接器，它用客户端 ID 信息装饰 URL，绕过基于 cookie 的限制。 如果您已启用 Google AMP 客户端 ID API，则 AMP 链接器不需要额外设置。

2. 推荐排除。 此外，您需要将 ampproject.org 添加为推荐排除项。 如果您从多个子域提供 AMP 内容，Google 建议为每个子域添加引荐排除。

正如 Enge 详细说明的那样，当前的解决方案并不完美：“您看不到自己托管的 AMP 页面与 Google CDN 托管页面之间的区别。”

该限制会影响具有“规范 AMP 页面”的网站——在发布商域上托管的 AMP 页面是移动页面的标准（规范）版本。 同一篇文章提供的解决方案是创建命中级别自定义维度。

初始安装后，更改将影响近期的 Google Analytics 数据：

• 总用户数和会话数将下降。 拼接 AMP 和非 AMP 会话将合并错误分离的用户和会话。
• 相关指标将变得更加准确。 例如，AMP 页面的跳出率将会下降。
• 新用户会增加。 Google AMP API 为 AMP 访问者一次性重置客户端 ID。 正如 Google 所指出的：“根据用户访问您网站的频率，这可能会导致您的新用户指标和相关报告出现明显的临时波动。”

3. 子域跟踪

子域跟踪变得相当容易，并且依赖于 Cookie 域的设置。 以前是手动步骤，将 Cookie 域 (cookieDomain) 设置为“自动”现在是 Google Analytics 脚本和 Google 标签管理器中的 Google Analytics 设置变量的默认选项。

Simo Ahava 解释说，将 Cookie 域设置为“自动”应用了一种递归算法

尝试写入 cookie，从最通用的域级别（顶级域）开始，并在成功后停止。 应该留下的是根域，因此所有子域都可以使用 cookie。

由于该算法将 cookie 设置在可能的最高级别（根域），因此登陆子域并随后迁移到核心域的用户不会生成新的客户端 ID，也不会启动新的会话。

第二步是将您的根域添加到引荐排除列表中，以便子域和核心域之间的访问不会启动新会话。 （第一步仅确保 Google 将访问者视为同一用户。 ）当您创建 Google Analytics 媒体资源时，Google 会自动将根域添加到引荐排除列表中，但该设置值得仔细检查。

理论上，这些更新会自动跟踪子域——默认情况下，Cookie 域和引荐排除列表设置为正确的值。

4. 跨域追踪

跨域跟踪是任何会话拼接过程中最复杂的，因为许多解决方案都是定制的：正确的实施取决于您的站点、支付处理器、登录工具或 - 上帝帮助您 - iframe 的设置。

如果多个站点共享相同的跟踪代码但未进行其他技术更改：

1. Analytics 将在域之间复制会话（因为客户端 ID 不会从一个转移到另一个）。
2. 原始归属信息将丢失，转换为来自其他域的推荐，由于它共享相同的跟踪代码，因此将显示为自我推荐。

与 AMP 跟踪一样，成功的跨域跟踪需要将客户端 ID 从一个站点传递到另一个站点，而不传递 cookie 本身。 有几个核心用例，每个用例都有独特的解决方案。

公司内部跨域跟踪

大型组织通常管理多个域，但希望在访问者从一个域移动到另一个域时对其进行跟踪。 假设站点共享相同的 Google Analytics 代码，跨多个域跟踪用户需要三个额外步骤。

前两个步骤更改跟踪代码以允许域通过链接传递和接收客户端 ID：

• 自动链接域。 在 Google 跟踪代码管理器的 Google Analytics 设置变量中添加所有域作为逗号分隔的列表，或修改您的 Google Analytics 代码以包含这些域。

• 允许链接器。 为确保域可以接收通过链接传递的客户端 ID，请在 Google 跟踪代码管理器的 Google Analytics 设置变量中添加一个名为“allowLinker”的字段，并将该值设置为“true”。 （如果用户流是单向的，则您需要仅在目标域（而不是源域）上允许链接器。）

链接器会附加时间戳和其他元数据来验证客户 ID，从而降低与客户 ID 共享的链接影响 Google Analytics（分析）数据的可能性。

最后一步是将所有域添加到您的推荐排除列表中。 否则，您将生成大量的自我推荐——Google Analytics 将正确识别域之间的一个用户，但仍会生成一个新会话。

要有效地分析从跨域跟踪收集的数据，请将主机名添加到 URL 路径中。 否则，多个域共享的路径将组合在一起。 以下两个 URL 在页面级报告中只会显示为 /about-us/：

您可以通过使用以下值设置自定义过滤器来添加主机名：

（如果您试图挽救未正确过滤的历史数据，您可以使用带有主机名的二级维度来区分视图中的 URL。）

第三方支付处理

对于第三方支付处理，正确的设置至关重要：没有它，您将丢失所有交易的归因数据，这些数据将显示为来自支付处理器的推荐。 但是，您对付款处理商页面的控制有限。

一种解决方案是为您的支付处理商的域设置推荐排除； 但是，如果出现以下情况，那么这项手动操作可能会变成一项重磅任务：

• 您与许多支付处理商合作。
• 支付处理商经常更改域。
• 排除代理的域也有排除“真实​​”推荐流量的风险（例如，您通过 PayPal 博客上的链接获得推荐访问）。

Ahava 详细介绍了一个创造性的综合解决方案：为收据或“谢谢”页面的所有流量创建推荐排除。 当用户从支付处理商的域返回到您的网站时，引荐排除会保留原始源数据并阻止 Google Analytics 生成新会话。

实施 Ahava 的解决方案有两个步骤：

1. 创建自定义 JavaScript 变量。 为感谢页面的 URL 设置引用值“null”。
2. 修改在感谢页面上触发的标签。 对于在您的感谢页面上触发的任何标记，请将“referrer”字段设置为最近创建的变量。

全面禁止推荐给定页面似乎有风险，但感谢页面只能在结账漏斗中访问（或应该访问）——没有人在感谢页面上开始他们的用户旅程——所以不存在丢失有价值的风险源数据。

社交登录

社交登录不能依赖于一揽子域引荐排除——虽然谷歌登录可能来自 account.google.com（一个你可以安全排除的子域），其他人，如 Facebook，来自 facebook.com，几乎每个网站都有来自 Facebook 的非登录推荐流量。

一个常见的解决方案是在新选项卡或窗口中打开授权，以保持站点会话的连续性。 但是，广告拦截器可能会干扰此过程，或者您可能更愿意（为了用户体验）不要打开新窗口。

另一个解决方案——很像 Ahava 的感谢页面策略——是覆盖或忽略您网站上托管的登录后页面的引用信息。 将引用者值设置为您自己的域或“null”可确保源注册为 Direct，从而保留单个会话。 该策略仅在登录后页面具有唯一 URL 时才有效。

内嵌框架

iframe 是会话拼接的一个挑战，部分原因是iframe 内容通常在 Analytics 代码触发之前加载。 这意味着传统的跟踪解决方案（例如将客户端 ID 附加到 URL）需要进行调整，如 Google 的开发人员指南详细信息：

要解决此问题，您可以在 iframe 内配置页面，以延迟创建跟踪器，直到它从父页面接收到客户端 ID 数据之后。 在父页面上，您将其配置为使用 postMessage 将客户端 ID 发送到 iframe 页面。

由于 iframe 上的跨域跟踪可能很痛苦——Ahava 将它们称为“存在于网站之间空隙中的无法追踪的小怪物”——它们（也）经常被更专注于移动表单的供应商用于 Web 表单将数据导入 CRM，而不是在 Google Analytics 中跟踪这些交互。

Bounteous 解释了在跨域 iframe 跟踪中使用 postMessage 的过程：

我们可以让我们的子 iframe 发出一条消息，我们可以“监听”并使用它来通知 GTM 发生了重要的交互。 这对于跟踪 iframe 中的简单表单提交等内容非常有用 [. . .] 我们需要采取以下步骤：

1.) 从我们的子 iframe 发布消息
2.) 在我们的父框架中监听消息
3.) 当我们捕获到消息时，将事件推送到 GTM 数据层

有一个重要的警告：您必须能够向 iframe 添加代码。 否则，该过程将无法进行。

Ahava 为跨域 iframe 跟踪编写了两个解决方案，其中最新的使用 customTask：

customTask API 是 Universal Analytics 库的一项功能（也被 Google Tag Manager 的标签使用）。 它允许您在生成（测量协议）命中时获取和设置值。

对于跨域 iframe 跟踪，“customTask 利用 setInterval() 脚本定期轮询页面，直到找到目标 iframe 或达到超时。”

当 Google Analytics 向父页面注册命中时，Ahava 的解决方案会提示 customTask 寻找与预设 CSS 选择器匹配的 iframe，然后使用初始命中的客户端 ID 装饰 iframe URL。

然而，即使是那个解决方案也是脆弱的，尤其是如果 iframe 包含重定向——确实是“无法追踪的狗屎怪物”。

结论

会话拼接将 Google Analytics 数据与我们所知道的真实情况保持一致：用户可以一次性在域之间导航、完成购买或填写表单，将他们短暂地转换到另一个域或从另一个域转换。

这些交互的关键性质——登录前和登录后、匿名访问者与已知潜在客户、潜在客户与过去的购买者——使得会话拼接非常值得付出努力。

将用户交互编织在一起可以增强归因数据并减少用户旅程关键时刻的盲点。