使用 AMP 管理未经身份验证的用户状态

目录

• 背景
  • AMP 页面的显示上下文
  • 多个上下文意味着多个状态管理
• 实施指南
  • 开始之前
  • 任务 1：对于发布商来源上的非 AMP 页面，设置一个标识符并发送分析 ping
  • 任务 2：对于 AMP 页面，通过在 amp-analytics ping 中包含客户端 ID 替换来设置标识符并发送分析 ping
  • 任务 3：处理来自发布商来源页面的分析 ping
  • 任务 4：处理来自 AMP 缓存或 AMP 查看器显示上下文的分析 ping，并建立标识符映射（如果需要）
  • 任务 5：在链接和表单提交中使用客户端 ID
• 强烈推荐的做法
  • 仅保留一个关联
  • 尊重 Cookie 和本地存储删除
  • 遵守当地法律和法规

用户状态是当今 Web 上的一个重要概念。考虑以下通过管理用户状态启用的用例

• 一个商家构建了一个有用的购物车，在用户第二次访问时，向用户显示他们在几周前的第一次访问中添加到购物车中的相同商品。通过确保他们仍然知道过去考虑购买的商品，这种体验增加了用户购买该商品的机会。
• 一位新闻出版商可以根据读者重复访问该出版商的文章，为读者量身定制推荐文章，这有助于保持读者参与并发现更多内容。
• 运行任何类型网站的网站开发人员收集分析数据，这些数据可以判断两个页面浏览量是属于同一个人浏览了两个页面，还是属于两个不同的人各自浏览了一个页面。了解这一点有助于了解网站的运行情况，并最终了解如何改进它。

本文旨在帮助您更成功地管理 AMP 中未经身份验证的用户状态，这是一种即使在用户未采取任何操作提供其身份（如登录）的情况下也能提供无缝用户体验的方式。在回顾了处理此主题中的一些挑战和注意事项后，本指南概述了 AMP 支持用户状态的方式，并提供了有关如何进行技术实施的建议。

背景

由于 AMP 页面可以在多个上下文中显示，例如在您的网站上、在 Google 搜索中或在第三方应用中，因此用户状态的主题在 AMP 中值得特别关注。这在用户在这些上下文之间移动时带来了管理用户状态的挑战。

AMP 页面的显示上下文

您可以将 AMP 视为一种便携式内容格式，使内容能够在任何地方快速加载。AMP 文档可以通过三个值得注意的上下文显示

• 发布商的来源
• AMP 缓存
• AMP 查看器

让我们更仔细地检查一下每种情况。

上下文 1：发布商的来源。 AMP 页面经过部署，以便它们最初托管在发布商的网站上并通过该网站访问，例如在 https://example.com 上可能会找到 https://example.com/article.amp.html。

发布商可以选择仅以 AMP 格式发布，或发布两个版本的内容（即，与非 AMP 内容“配对”的 AMP 内容）。“配对”模型需要一些特定步骤来确保搜索引擎、社交媒体网站和其他平台可以发现页面的 AMP 版本。完全支持这两种发布方法；由发布商决定采取哪种方法。

注意

由于刚刚描述的“配对”发布模型，发布商的来源（在上面的示例中，为 https://example.com）是可以访问 AMP 和非 AMP 内容的上下文。实际上，这是唯一可以发生这种情况的上下文，因为如下所述的 AMP 缓存和 AMP 查看器仅提供有效的 AMP 内容。

上下文 2：AMP 缓存。 AMP 文件可以由第三方缓存缓存在云中，以减少内容到达用户移动设备所需的时间。

通过使用 AMP 格式，内容生产者可以使 AMP 文件中的内容可被第三方缓存。在这种类型的框架下，发布商继续控制他们的内容（通过如上所述发布到他们的来源），但平台可以缓存或镜像内容以实现最佳的用户交付速度。

传统上，以这种方式提供的内容来自不同的域。例如，Google AMP 缓存使用 https://cdn.ampproject.org 提供内容，例如 https://example-com.cdn.ampproject.org/s/example.com/article.amp.html。

上下文 3：AMP 查看器。 AMP 格式旨在支持嵌入在第三方 AMP 查看器中。这使 AMP 文件和查看器体验之间能够高度协作，其优点包括：智能且安全的内容预加载和预渲染以及创新的功能，如在完整 AMP 页面之间滑动。

与 AMP 缓存案例一样，预计 AMP 查看器的域也与发布商来源不同。例如，Google 搜索的查看器托管在 https://google.com 上，并嵌入一个 iframe，该 iframe 从 Google AMP 缓存请求发布商内容。

多个上下文意味着多个状态管理

发布商必须准备好分别管理每个显示上下文的用户状态。AMP 的 客户端 ID 功能利用 Cookie 或本地存储来持久化状态，为 AMP 页面提供必要支持，从而为用户提供稳定和匿名的标识符。从实施的角度来看，可以使用 Cookie 或本地存储，并且 AMP 根据显示上下文决定使用哪个。此选择受管理扩展到数百或数千个发布商的此状态的技术可行性的影响。

但是，AMP 页面的发布商很容易（无意地）设计出涉及多个上下文的用户旅程。让我们回顾一下我们之前对购物车用例的介绍，并添加一些更多细节来创建一个完整的用户故事

在第 1 天，用户通过 Google 搜索从 Example Inc. 发现一个 AMP 页面。Google 搜索在 AMP 查看器中加载 AMP 页面。在查看页面时，用户将四件商品添加到购物车，但没有结账。两周后，在第 15 天，用户记起他们考虑购买的四件商品，并决定现在是购买的时候了。他们直接访问 Example Inc. 的主页 https://example.com（这是一个非 AMP 主页），并发现他们的四件商品仍然保存在购物车中。

在这种情况下，即使该用户已从 AMP 查看器上下文移动到发布商来源上下文，并且在这些事件之间经过了一段时间，但该用户也会获得一致的购物车体验。这种体验非常合理，如果您正在设计购物体验，则应该期望支持它，那么您如何实现它呢？

要启用此体验以及任何涉及用户状态的体验，用户遍历的所有上下文都必须彼此共享它们各自维护的状态。您可能会说“完美！”，想法是在这些上下文边界之间共享带有用户标识符的 Cookie 值。但有一个问题：即使每个上下文都显示由同一发布商控制的内容，但由于每个上下文都位于不同的域上，因此它们都将另一个视为第三方。

正如您将在以下讨论中看到的那样，当与 Cookie 交互时处于第三方位置可能会带来挑战，具体取决于用户的浏览器设置配置方式。特别是，如果在特定情况下阻止了第三方 Cookie，则会阻止在上下文之间共享信息。另一方面，如果允许第三方 Cookie 操作，则可以共享信息。

实施指南

本节提供有关管理用户状态的建议。以下任务以渐进方式呈现，但在很大程度上可以分为两部分

第一部分：基本实现： 任务 1-4 对于实现基本功能至关重要。它们依赖于一小组必要的功能，以使工作部分完成：AMP 的客户端 ID 替换、Cookie 的读取和写入以及维护后端映射表。为什么说“部分”完成？因为这些任务中传达的步骤依赖于读取和写入 Cookie，并且浏览器的 Cookie 设置可能会在某些情况下阻止此操作，因此这组任务可能不足以在所有场景中完全管理用户状态。

在奠定基础之后，我们将探讨一个使用范围较窄但为这些使用案例提供完整解决方案的主题。

第二部分：在链接和表单提交中使用客户端 ID：在任务 5 中，您将学习如何利用链接跳转和/或表单提交，在用户从一个页面直接跳转到另一个页面的上下文边界之间传递 AMP 客户端 ID 信息。

注意

以下实现指南建议使用和操作 Cookie。请务必查阅强烈推荐的做法部分，了解需要牢记的重要建议。

开始之前

在浏览以下技术指南时，让我们假设您将用户状态绑定到一个代表用户的稳定标识符。例如，标识符可能类似于 n34ic982n2386n30。然后在服务器端，您将 n34ic982n2386n30 与任何用户状态信息集相关联，例如购物车内容、之前阅读的文章列表或根据使用案例的其他数据。

为了在本文档的其余部分保持清晰，我们将用更易读的名称（前面带有美元符号 ($)）来称呼各种字符串形式的标识符

n34ic982n2386n30 ⇒ $sample_id

我们的使用案例：在本指南中，我们将研究一个旨在实现简单页面浏览跟踪（即分析）的示例，我们希望尽可能准确地统计用户。这意味着，即使在用户从不同的上下文访问特定发布商的内容（包括在 AMP 和非 AMP 页面之间切换）时，我们也希望这些访问能够计入对用户的统一理解，就像用户仅在该发布商的传统非 AMP 页面上浏览一样。

关于稳定 Cookie 值可用性的假设：我们还假设用户使用相同的设备、浏览器和非隐私/隐身浏览，以确保 Cookie 值在用户会话期间长期保存和可用。如果不是这种情况，则不应期望这些技术起作用。如果这是必需的，请考虑根据用户经过身份验证（即已登录）的身份来管理用户状态。

以下提出的概念可以扩展到其他使用案例：虽然我们只关注分析使用案例，但以下传达的概念可以针对需要跨上下文管理用户状态的其他使用案例进行修改。

任务 1：对于发布商来源上的非 AMP 页面，设置标识符并发送分析 ping

首先，让我们为从发布商来源提供的非 AMP 页面配置分析。这可以通过多种方式实现，包括使用 Google Analytics 或 Adobe Analytics 等分析包，或编写自定义实现。

如果您使用的是供应商提供的分析包，则该包很可能会通过其配置代码和 API 来处理 Cookie 的设置和 ping 的传输。如果是这种情况，您应该通读以下步骤，以确保它们与您的分析方法一致，但预计您无需在完成此任务时进行任何更改。

如果您希望自行设置分析，则本任务的其余部分将提供指导。

使用第一方 Cookie 设置标识符

如果您有从发布商来源提供的非 AMP 页面，请设置一个持久且稳定的标识符，以便在这些页面上使用。这通常使用第一方 Cookie 实现。

对于我们的示例，假设您已设置了一个名为 uid（“用户标识符”）的 Cookie，该 Cookie 将在用户首次访问时创建。如果这不是用户首次访问，则读取首次访问时先前设置的值。

这意味着发布商来源上的非 AMP 页面的状态有两种情况

情况 1：首次访问。首次访问非 AMP 页面时，将没有 Cookie。如果您在设置 Cookie 之前检查过 Cookie，则会看到 Cookie 中没有与 uid 对应的设置值

> document.cookie
  ""

在初始加载期间的某个时间，应设置 Cookie，这样如果您在页面加载后执行此操作，您将看到已设置了一个值

> document.cookie
  "uid=$publisher_origin_identifier"

情况 2：非首次访问。将设置一个 Cookie。因此，如果您在页面上打开开发者控制台，您会看到

> document.cookie
  "uid=$publisher_origin_identifier"

发送分析 ping

设置好标识符后，您现在可以将其纳入分析 ping 中，以开始跟踪页面浏览量。

具体实现将取决于您所需的配置，但通常您会希望将 ping（请求）发送到您的分析服务器，其中包含请求 URL 本身内的有用数据。下面是一个示例，其中还说明了如何在请求中包含您的 Cookie 值

https://analytics.example.com/ping?type=pageview&user_id=$publisher_origin_identifier

请注意，在上面的示例中，用户的标识符由特定的查询参数 user_id 指示

user_id=$publisher_origin_identifier

此处 "user_id" 的使用应由您的分析服务器期望处理的内容决定，而不是专门与您在本地存储标识符的 Cookie 名称相关联。

任务 2：对于 AMP 页面，通过在 amp-analytics ping 中包含客户端 ID 替换来设置标识符并发送分析 ping

现在转向 AMP 页面，让我们看看如何建立和传输用于分析的标识符。这适用于 AMP 页面的任何显示环境，因此涵盖发布商来源上的任何 AMP 页面、通过 AMP 缓存提供的页面或在 AMP 查看器中显示的页面。

通过使用需要客户端 ID 的功能，AMP 将执行“幕后”工作来生成和存储客户端 ID 值，并将它们提供给需要这些功能的功能。可以使用 AMP 客户端 ID 的主要功能之一是 amp-analytics，这恰好是我们实现分析使用案例示例所需要的。

在 AMP 页面上，构建包含客户端 ID 的 amp-analytics ping

请注意，传递到客户端 ID 替换的参数 ${clientId(uid)} 是 uid。这是一个经过深思熟虑的选择，与任务 1中描述的发布商来源上使用的 Cookie 名称相同。为了实现最无缝的集成，您应该应用相同的技术。

关于 amp-analytics 实现的其余部分，请参阅 amp-analytics 配置的文档，了解有关如何设置 amp-analytics 请求或修改分析供应商的请求的更多详细信息。可以进一步修改 ping 以传输您直接定义或利用其他 AMP 替换的数据。

须知

为什么我们将 uid 用作传递给客户端 ID 功能的参数名称？clientId(...) 替换所使用的参数用于定义范围。您实际上可以将客户端 ID 功能用于许多使用案例，因此会生成许多客户端 ID。该参数区分这些使用案例，因此您可以使用它来指定您想要哪个使用案例的客户端 ID。例如，您可能想要将不同的标识符发送给广告商之类的第三方，您可以使用“范围”参数来实现此目的。

在发布商来源上，最容易将“范围”视为您所调用的 Cookie。通过建议在任务 2中为客户端 ID 参数使用 uid 值，我们与任务 1中选择使用名为 uid 的 Cookie 相一致。

任务 3：处理来自发布商来源页面的分析 ping

由于在任务 1 和 2 中执行的设置，当有人访问 AMP 版本（来自任何上下文）或发布商来源上的非 AMP 版本时，分析 ping 将使用相同的标识符。通过遵循任务 2 中的指南，选择与您在任务 1中使用的 Cookie 名称相同的客户端 ID“范围”，AMP 会重用同一个 Cookie。

下表对此进行了说明

任务 4：处理来自 AMP 缓存或 AMP 查看器显示环境的分析 ping 并建立标识符映射（如果需要）

当我们在任务 2 中设置分析 ping 以从 AMP 缓存或 AMP 查看器中显示的 AMP 页面传输数据时，我们也制造了一个问题。如前所述，AMP 缓存和 AMP 查看器环境与发布商来源环境不同，并且随之而来的是不同的标识符维护方式。为了处理这些 ping 以避免诸如用户重复计数之类的问题，我们将采取一些步骤来尝试尽可能地协调标识符。

为了帮助解释我们采取的步骤，首先重新考虑重复计数问题是如何产生的会很有帮助。

回顾问题

考虑以下流程

1. 用户在 AMP 查看器显示环境中访问 AMP 页面，例如 https://google.com/amp/s/example.com/article.amp.html。由于 AMP 查看器无法访问发布商域上的 uid Cookie，因此会生成一个随机的 $amp_client_id 值来识别用户。
2. 然后，同一用户访问发布商域上的页面 https://example.com。如 任务 3 中所述，该用户会被 $publisher_origin_identifier 识别。

这里 (1) 和 (2) 发生在不同的域（或环境）中。因此，没有共享状态，并且 $amp_client_id 与 $publisher_origin_identifier 不同。那么，这会产生什么影响呢？(1) 是一个看起来像一个用户的单次页面浏览会话，而 (2) 是另一个看起来像来自另一个用户的单次页面浏览会话。基本上，即使该用户一直与 https://example.com 内容保持互动，我们也会高估用户数量，并且 (1) 中的用户看起来像是跳出（单次页面访问）。

解决方案策略

为了解决用户数量高估的问题，您应该采用以下策略，其有效性取决于是否允许读取或写入第三方 Cookie

• 立即标识符协调：如果您可以访问或更改发布商域 Cookie，请使用或创建发布商域标识符，并忽略分析请求中的任何标识符。您将能够成功链接两个环境之间的活动。
• 延迟标识符协调：如果您无法访问或更改发布商域标识符（即 Cookie），则回退到分析请求本身中包含的 AMP 客户端 ID。使用此标识符作为“别名”，而不是使用或创建新的发布商域标识符（Cookie），您无法执行此操作（因为第三方 Cookie 被阻止），并将别名添加到映射表中。您无法立即链接两个环境之间的活动，但是通过使用映射表，您或许可以将 AMP 客户端 ID 值与用户未来访问时的发布商域标识符链接起来。发生这种情况时，您将拥有链接活动和协调不同环境中页面访问来自同一用户所需的信息。任务 5 描述了如何在用户从一个页面立即跳转到另一个页面的特定场景中实现完整的解决方案。

实施步骤

在服务器上检查是否存在发布商域标识符

读取作为分析请求的一部分发送的 Cookie。在我们的示例中，这意味着检查来自 example.com 的 uid Cookie。

• 如果成功读取了 uid 值，请使用它来记录分析数据（分析记录标识符）。由于 任务 1，我们知道此标识符的值为 $publisher_origin_identifier。在建立分析记录标识符后，我们可以跳到 数据存储 部分。
• 如果未成功读取 uid 值，请继续执行以下涉及映射表的步骤。

映射表

我们的映射表将把分析 ping 中看到的 AMP 客户端 ID 值与发布商域标识符关联，如下所示

在确定未能成功读取发布商域标识符后，立即检查分析 ping 中包含的 AMP 客户端 ID 是否已在映射中使用。为此，首先查阅传入的 amp-analytics 请求以获取客户端 ID 值。例如，从这个请求中

https://analytics.example.com/ping?type=pageview&user_id=$amp_client_id

我们提取出与 AMP 客户端 ID 对应的加粗部分：$amp_client_id。

接下来，检查映射表，尝试在“别名”列中查找相同的值

在上面的示例中，我们找到一个已存在的记录。我们找到的与 AMP 客户端 ID 配对的值将成为分析记录标识符。在这里，它是 $existing_publisher_origin_identifier。在建立分析记录标识符后，我们可以跳到 数据存储 部分。

否则，如果在映射中找不到 AMP 客户端 ID，我们需要创建一个映射

1. 生成一个潜在的发布商域标识符。在以下示例中，我们将其称为 $prospective_identifier。此值应按照您在发布商域上设置该值的方式创建，如上面的 任务 1 中所述。
2. 接下来，尝试在发布商域上将潜在的发布商域标识符设置为 Cookie。如果可以写入第三方 Cookie，则此操作将成功，否则将失败。
3. 然后，存储 {潜在的发布商域标识符，AMP 客户端 ID} 对。

我们创建的映射最终如下所示

我们将使用潜在的发布商域标识符作为分析记录标识符，因为该值与发布商域上的状态相关联。在这种情况下，它是 $prospective_identifier，它将在下面的 数据存储 部分中发挥作用。

数据存储

现在您已经确定了分析记录标识符，您可以实际存储以该标识符为键的用户状态信息（在本例中为分析数据）

{analytics record identifier, analytics data ...}

任务 5：在链接和表单提交中使用客户端 ID

通常，当不允许读取和写入第三方 Cookie 时，将无法完全有效地管理用户状态。在任务 1-4 中，我们采取的步骤在两个方面有所帮助：(1) 它们为允许读取和写入第三方 Cookie 的情况提供了完全有效的解决方案，并且 (2) 它们设置了我们的系统，以便在由于浏览器的 Cookie 设置而无法立即进行协调时，能够利用任何最终的机会来协调跨环境标识符。

在本任务中，我们将介绍一个额外的优化，该优化在用户通过链接或表单提交从一个页面跨环境导航到另一个页面时有所帮助。在这些情况下，并且通过下面描述的实现工作，可以设置一个完全有效的方案来管理跨环境的用户状态。

使用替换功能

我们的方法将利用两种类型的 AMP 变量替换。

更新传出链接以使用客户端 ID 替换：定义一个新的查询参数 ref_id（“引用 ID”），该参数将出现在 URL 中，并指示用户原始环境的标识符。将此查询参数设置为等于 AMP 的客户端 ID 替换的值

<a
  href="https://example.com/step2.html?ref_id=CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
></a>

将客户端 ID 传递给传出链接的替代解决方案：将新的查询参数 ref_id 定义为数据属性 data-amp-addparams 的一部分，并且对于需要参数替换的查询，请在 data-amp-replace 中提供这些详细信息。使用这种方法，URL 看上去会很简洁，并且 data-amp-addparams 上指定的参数将被动态添加

<a
  href="https://example.com/step2.html"
  data-amp-addparams="ref_id=CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
></a>

为了通过 data-amp-addparams 传递多个查询参数，请使用 & 分隔它们，如下所示

<a
  href="https://example.com/step2.html"
  data-amp-addparams="ref_id=CLIENT_ID(uid)&pageid=p123"
  data-amp-replace="CLIENT_ID"
></a>

更新表单输入以使用客户端 ID 替换：为输入字段定义一个名称，例如 orig_user_id。指定表单字段的 default-value 为 AMP 的客户端 ID 替换的值

<input
  name="ref_id"
  type="hidden"
  value="CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
/>

通过执行这些步骤，客户端 ID 可用于目标服务器和/或作为用户在链接点击或表单提交后登陆的页面上的 URL 参数（目标环境）。名称（或“键”）将是 ref_id，因为这是我们在上述实现中定义的名称，并且将具有一个与客户端 ID 相等的相关值。例如，通过点击上面定义的链接（<a> 标签），用户将导航到此 URL

https://example.com/step2.html?ref_id=$amp_client_id

当用户登陆包含 ref_id 值（作为 URL 参数或在标头中）的页面时，我们有机会共同处理 ref_id 标识符以及通过页面本身公开的标识符（即 Cookie 值）。通过在分析 ping 中同时包含两者，您的分析服务器可以同时处理这两个值，并且，了解它们之间的关系，在您的后端中反映这种关系。下一步提供了有关如何执行此操作的详细信息。

提取 URL 查询参数

通过使用替换功能，我们设置了一个链接导航流或表单提交流，该流将信息（特别是客户端 ID）暴露给目标服务器和/或作为用户完成导航后可以在客户端上读取的 URL 参数。

如果信息仅暴露给服务器，例如通过表单 POST，则您可以继续处理信息并呈现生成的页面。在处理此类数据时，请注意下面详细介绍的关于 参数验证 的步骤。

如果信息通过 URL 可用，并且您希望处理它，则可以使用以下几种方法

• 在重定向期间处理（服务器端处理）
• 在登陆页面上处理（客户端处理）

在重定向期间处理（服务器端处理）

要在重定向期间进行处理，请在服务器上处理请求并提取相关参数。请注意下面详细介绍的关于 参数验证 的步骤。处理数据，结合包含其他相关标识符的 Cookie 值，然后重定向到不包含参数的 URL。

在登陆页面上处理（客户端处理）

要在登陆页面上进行处理，该方法将根据该页面是 AMP 页面还是非 AMP 页面而有所不同。

AMP 页面更新： 在您的 amp-analytics 配置中使用查询参数替换功能，以获取 URL 中的 ref_id 标识符值。查询参数功能接受一个参数，该参数指示 URL 中所需键值对的“键”，并返回相应的值。像我们之前所做的那样，使用客户端 ID 功能来获取 AMP 页面上下文的标识符。

https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}

当通过网络传输时，实际值将被替换

https://analytics.example.com/ping?type=pageview&orig_user_id=$referrer_page_identifier&user_id=$current_page_identifier

按照上面的示例，我们有

$referrer_page_identifier is $amp_client_id
$current_page_identifier is $publisher_origin_id

所以实际的 ping 是

https://analytics.example.com/ping?type=pageview&orig_user_id=$amp_client_id&user_id=$publisher_origin_id

我们建议按照下面参数验证部分中概述的步骤，验证查询参数值的真实性。

非 AMP 页面更新： 同样，在从您的发布商源提供的非 AMP 页面上，提取并传输 URL 中包含的 ref_id 值。按照下面参数验证部分中概述的步骤，验证该值的真实性。然后，构造分析 ping，其中将包括一个从 ref_id 派生的 orig_user_id 和一个基于第一方 Cookie 标识符值的 user_id。

重要提示

如果您选择在着陆页上客户端处理参数，则着陆页应在捕获标识符后立即从 URL 中删除标识符信息。

在删除参数之前，请确保需要运行以读取它们的其他代码已

• 在删除发生之前运行；或者
• 可以访问读取并删除参数的代码已存储数据的位置

要在您的非 AMP 页面上执行此操作，请包含以下 JavaScript，它将从 URL 中删除所有查询参数

var href = location.href.replace(/\?[^#]+/, '');
history.replaceState(null, null, href);

根据需要调整此代码以删除更少的查询参数。

在分析 ping 中处理多个标识符

与任务 4 中我们将分析 ping 配置为仅包含一个标识符值不同，通过我们在任务 5 中到目前为止所采取的步骤，我们现在有两个标识符 — orig_user_id 和 user_id。接下来我们将介绍如何处理作为入站分析 ping 一部分的这两个标识符。

在我们继续之前，请务必注意下面参数验证中描述的步骤，并确保您愿意信任 orig_user_id 和 user_id 指示的两个值。

检查您的映射表中是否存在与入站分析 ping 相对应的任何值。在上面的示例中，第一个页面浏览发生在不在发布商源上的 AMP 页面上，然后是第二个页面浏览发生在发布商源上。因此，分析 ping 查询参数的值将如下所示

情况 #1：当分析 ping 从发布商源上的页面发送时，标识符排列

请注意，来自第一个页面浏览的标识符对应于最右边的列，而来自第二个页面浏览的标识符位于中间列，这与我们上面示例流程的构建方式一致。

如果用户从发布商源提供的页面开始，然后导航到不在发布商源上的 AMP 页面，则参数的键将反转，但是我们引用值的方式不会反转（即 $amp_client_id 始终指存储在不在发布商源上的 AMP 页面上的标识符）

情况 #2：当分析 ping 从不在发布商源上的 AMP 页面发送时，标识符排列

当您搜索映射表时，请注意适用哪种情况，并在您希望它们出现的映射表列中搜索值。例如，如果分析 ping 是从发布商源上的页面发送的（情况 #1），则在映射表列“发布商源上的用户 ID”中检查以 user_id 为键的值，并在列“不在发布商源上的 AMP 页面上的用户 ID（‘别名’）”中检查以 orig_user_id 为键的值。

如果您在映射表中找不到正在使用的任何标识符值，请建立新的映射

• 如果分析请求来自您发布商源上的页面，那么您应该选择与 uid 对应的值作为分析记录标识符；选择 orig_uid 的值作为“别名”。
• 如果分析请求不是来自您发布商源上的页面，那么您应该选择与 uid 对应的值作为映射表中的“别名”值。然后，按照任务 4 中的其余说明，创建潜在的发布商源标识符，并尝试将此值设置为源上的 Cookie。

参数验证

URL 中包含的值可能会被恶意更改、格式错误，或者以某种方式不是您期望的值。这有时被称为跨站点请求伪造。正如确保您的分析服务器收到的分析 ping 来自您期望发送分析 ping 的页面非常重要一样，当您“转发”作为 URL 一部分的值时，请务必验证引用，以确保您可以信任这些值。

例如，在上面的步骤中，我们构造了以下 URL，旨在供用户单击并导航到相应的页面

https://example.com/step2.html?orig_user_id=$amp_client_id

但是，用户或某些攻击者也可能将此 URL 更改为

https://example.com/step2.html?orig_user_id=$malicious_value

您要确保只处理 $amp_client_id 的实例，并避免使用 $malicious_value 的实例。

验证通过 URL 查询参数接收的值的建议步骤： 确认着陆页的引用与您期望看到的 URL 匹配。这通常应该是您以前在有效的 CORS 请求中看到携带先前看到的标识符值的 URL。我们建议您仅接受此类已知标识符。

在非 AMP 页面上，直接在客户端检查 document.referrer，或者将该值作为分析 ping 的一部分传递，以便能够在服务器端进行验证。如果引用值是您可以信任的值，则您可以接受并处理源自着陆页 URL 的值，例如上面示例中的 orig_user_id。

在 AMP 页面上，使用文档引用替换变量，将引用值作为分析 ping 的一部分传递。服务器端处理是唯一可用的选项。为了说明，这里有一个着陆页可以发送的分析 ping，其中包含 (1) 当前页面的客户端 ID 值，(2) 通过 URL 传递的值，我们已将其设置为引用页面的客户端 ID 值，以及 (3) 引用信息本身，用于验证 (2) 的值：https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}&referrer=${documentReferrer}

如果您无法信任引用，则拒绝通过 URL 参数提供的任何值，并且不要使用它们。

强烈推荐的做法

只保留一个关联

任何两个上下文的标识符之间都应仅维护一个关联。 如果您先前与您发布的 Cookie 或其他用户标识符相关联的 AMP 客户端 ID 与您发布的新 Cookie 或用户标识符一起出现，则应删除您针对以前的 Cookie 和用户标识符保留的所有状态。

这些步骤将有助于确保与用户对隐私的期望保持一致。如前几节中所详述，在 AMP 中管理用户状态通常涉及存储和关联在显示 AMP 内容的多个上下文中的不同标识符。这种情况绝不应被滥用来重建数据或执行用户不会期望或您未向用户明确披露的跟踪，例如，在用户删除其网站的 Cookie 之后。

尊重 Cookie 和本地存储删除

您应该尊重所有提供给用户的适用隐私控制，包括任何创建删除所有 Cookie 和本地存储的能力的此类控制。 在任何时候，都不应在用户明确删除标识符关系的某一方后，使用 AMP 客户端 ID 或 AMP 基础结构来重建已删除的标识符。

遵守当地法律和法规

将来自两个或多个域的 Cookie 和/或标识符关联可能需要在某些司法管辖区更新您的隐私政策、提供额外的用户披露或获得最终用户同意。 每个发布商都应根据所有关于数据收集、存储、处理和用户通知的适用法律和法规，分析 AMP 客户端 ID 的使用，该客户端 ID 使用 Cookie 或本地存储作为持久存储的手段来提供稳定的标识符。