使用 AMP 管理未验证用户状态

目录

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

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

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

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

背景

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

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 Cache 使用 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 Cache 请求发布商内容。

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

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

但是，AMP 页面的发布商很容易（在不知不觉中）设计出涉及多个上下文的用户旅程。 让我们回顾一下我们之前对购物车用例的探讨，并添加更多细节，以使其成为一个完整的用户故事

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

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

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

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

实施指南

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

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

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

第2部分：在链接和表单提交中使用客户端 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，您将看不到与 uid 对应的 Cookie 中设置的值

> 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 页面或 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 中将 uid 值用作此处客户端 ID 参数的值，我们与在 任务 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 参数还是在标头中，我们都有机会与页面本身公开的标识符（即 Cookie 值）一起共同处理 ref_id 标识符。通过在分析 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 的使用情况，因为它使用 Cookie 或本地存储作为持久存储的方式来提供稳定的标识符，并应考虑所有关于数据收集、存储、处理和用户通知的适用法律和法规。