使用 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 缓存使用 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 设置可能会在某些情况下阻止此操作，因此这组任务可能不足以在所有场景中完全管理用户状态。

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

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

注意

以下实施指南建议使用 Cookie 并使用 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 之前检查过，则您会在与 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 查看器中显示的页面。

通过使用需要客户端 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：当从非发布商来源的 AMP 页面发送分析 ping 时的标识符排列

在搜索映射表时，请注意哪种情况适用，并在您期望它们出现的地方的映射表的列中搜索值。例如，如果分析 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 或本地存储作为持久存储方式，以提供稳定的标识符。