使用 AMP 管理未經驗證的使用者狀態

目錄

• 背景
  • AMP 網頁的顯示情境
  • 多種情境表示多種狀態管理
• 實作指南
  • 開始之前
  • 工作 1：針對發布商網域上的非 AMP 網頁，設定識別碼並傳送分析資料 Ping
  • 工作 2：針對 AMP 網頁，透過在 amp-analytics Ping 中加入 Client ID 替換設定識別碼並傳送分析資料 Ping
  • 工作 3：處理來自發布商網域網頁的分析資料 Ping
  • 工作 4：處理來自 AMP 快取或 AMP 檢視器顯示情境的分析資料 Ping，並建立識別碼對應 (若需要)
  • 工作 5：在連結和表單提交中使用 Client 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，從 Google AMP 快取請求發布商內容。

多種情境表示多種狀態管理

發布商必須準備好分別管理每個顯示情境的使用者狀態。AMP 的 Client 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 的 Client ID 替換、Cookie 的讀取和寫入，以及維護後端對應表。「部分」的原因何在？因為這些工作中傳達的步驟依賴於 Cookie 的讀取和寫入，並且因為瀏覽器的 Cookie 設定可能會在某些情況下阻止此操作，因此這組工作可能不足以在所有情境中完全管理使用者狀態。

在奠定基礎之後，我們接著會探討一個使用案例範圍較窄的主題，但該主題為這些使用案例提供完整的解決方案。

第二部分：在連結和表單提交中使用 Client ID：在工作 5 中，您將學習利用連結遍歷和/或表單提交的優勢，在使用者從一個網頁直接遍歷到另一個網頁的情境界限之間傳遞 AMP Client 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 (請求) 傳送到您的分析資料伺服器，其中包含請求網址本身內的實用資料。以下是一個範例，其中也說明您如何在請求中加入 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 中加入 Client ID 替換設定識別碼並傳送分析資料 Ping

現在轉向 AMP 網頁，讓我們看看您如何建立和傳輸分析資料的識別碼。這將適用於 AMP 網頁呈現的任何情境，因此涵蓋發布商網域上的任何 AMP 網頁、透過 AMP 快取提供的網頁或在 AMP 檢視器中顯示的網頁。

透過使用需要 Client ID 的功能，AMP 將執行「幕後」工作，以產生和儲存 Client ID 值，並將其呈現給需要這些值的功能。可以使用 AMP Client ID 的主要功能之一是 amp-analytics，這正好是我們實作分析資料使用案例範例所需的功能。

在 AMP 網頁上，建構包含 Client ID 的 amp-analytics Ping：

請注意，傳遞到 Client ID 替換的參數 ${clientId(uid) 是 uid。這是一個刻意的選擇，與 工作 1 中描述的發布商網域上使用的相同 Cookie 名稱相符。為了實現最無縫的整合，您應該應用相同的技術。

關於 amp-analytics 實作的其餘部分，請參閱 amp-analytics 設定的文件，以取得關於如何設定 amp-analytics 請求或修改分析資料供應商的請求的更多詳細資訊。Ping 可以進一步修改，以傳輸您直接定義的其他資料，或利用其他 AMP 替換。

小知識

為什麼我們將名稱 uid 用於傳遞到 Client ID 功能的參數？clientId(...) 替換採用的參數用於定義範圍。您實際上可以將 Client ID 功能用於許多使用案例，因此，產生許多 Client ID。參數區分這些使用案例，因此您可以使用它來指定您想要哪個使用案例的 Client ID。例如，您可能想要將不同的識別碼傳送給第三方 (例如廣告商)，並且您可以使用「範圍」參數來實現此目的。

在發布商網域上，最容易將「範圍」視為您呼叫 Cookie 的名稱。透過在此處的 工作 2 中建議 Client ID 參數的值為 uid，我們與在 工作 1 中使用名為 uid 的 Cookie 的選擇保持一致。

工作 3：處理來自發布商網域網頁的分析資料 Ping

由於工作 1 和 2 中執行的設定，當有人存取發布商網域上的 AMP 版本 (來自任何情境) 或非 AMP 版本時，分析資料 Ping 將使用相同的識別碼。透過遵循 工作 2 中的指南，選擇與您在 工作 1 中使用的 Cookie 名稱相同的 Client 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 Client ID。將此識別碼用作「別名」，而不是使用或建立新的發布商網域識別碼 (Cookie)，您無法執行此操作 (因為第三方 Cookie 遭到封鎖)，並將別名新增至對應表。您將無法立即連結兩個情境之間的活動，但透過使用對應表，您或許能夠在使用者未來造訪時將 AMP Client ID 值與發布商網域識別碼連結起來。當這種情況發生時，您將擁有連結活動並協調不同情境中的網頁造訪來自同一使用者所需的資訊。工作 5 描述如何在使用者從一個網頁立即遍歷到另一個網頁的特定情境中實現完整的解決方案。

實作步驟

在伺服器上檢查現有的發布商網域識別碼：

讀取作為分析資料請求一部分傳送的 Cookie。在我們的範例中，這表示檢查來自 example.com 的 uid Cookie。

• 如果成功讀取 uid 值，請使用它來記錄分析資料 (分析記錄識別碼)。由於 工作 1，我們知道此識別碼的值為 $publisher_origin_identifier。建立分析記錄識別碼後，我們可以跳到「資料儲存」章節。
• 如果未成功讀取 uid 值，請繼續執行以下涉及對應表的步驟。

對應表

我們的對應表將分析資料 Ping 中看到的 AMP Client ID 值與發布商網域識別碼關聯起來，如下所示：

在判斷您未成功讀取發布商網域識別碼後，立即檢查分析資料 Ping 中包含的 AMP Client ID 是否已在對應中使用。若要執行此操作，請先查閱傳入的 amp-analytics 請求以取得 Client ID 值。例如，從此請求：

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

我們擷取出與 AMP Client ID 對應的粗體部分：$amp_client_id。

接下來，檢查對應表，嘗試在「別名」欄中找到相同的值：

在上面的範例中，我們找到一個已存在的記錄。我們找到的與 AMP Client ID 配對的值會成為分析記錄識別碼。在這裡，它是 $existing_publisher_origin_identifier。建立分析記錄識別碼後，我們可以跳到「資料儲存」章節。

否則，如果在對應中找不到 AMP Client ID，我們需要建立一個對應：

1. 產生預期發布商網域識別碼。在以下範例中，我們將其稱為 $prospective_identifier。應根據您在發布商網域上設定值的方式建立此值，如上方的 工作 1 中所述。
2. 接下來，嘗試將預期發布商網域識別碼設定為發布商網域上的 Cookie。如果可以寫入第三方 Cookie，則此操作將成功，否則將失敗。
3. 然後，儲存 {預期發布商網域識別碼、AMP Client ID} 對。

我們建立的對應最終看起來像這樣：

我們將使用預期發布商網域識別碼作為分析記錄識別碼，因為它是與發布商網域上的狀態相關聯的值。在本例中，它是 $prospective_identifier，這將在接下來的「資料儲存」章節中發揮作用。

資料儲存

現在您已找出分析記錄識別碼，您可以實際儲存以該識別碼為索引鍵的使用者狀態資訊 (在本例中為分析資料)：

{analytics record identifier, analytics data ...}

工作 5：在連結和表單提交中使用 Client ID

一般而言，當不允許讀取和寫入第三方 Cookie 時，在某些情況下，管理使用者狀態將無法完全有效。在工作 1-4 中，我們採取的步驟在兩個方面有所幫助：(1) 它們為允許讀取和寫入第三方 Cookie 的情況提供完全有效的解決方案，以及 (2) 它們設定我們的系統以利用任何最終的機會來協調跨情境識別碼，如果在瀏覽器的 Cookie 設定下無法立即協調。

在此工作中，我們將涵蓋額外的最佳化，當使用者透過連結或表單提交從一個網頁跨情境導覽到另一個網頁時，此最佳化有所幫助。在這些情況下，以及透過以下描述的實作工作，可以設定完全有效的方案來管理跨情境的使用者狀態。

使用替換功能

我們的方法將利用兩種 AMP 變數替換類型。

更新外寄連結以使用 Client ID 替換：定義一個新的查詢參數 ref_id (「參照來源 ID」)，它將出現在網址中，並指示來源情境的使用者識別碼。將此查詢參數設定為等於 AMP Client ID 替換的值：

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

用於將 Client ID 傳遞到外寄連結的替代解決方案：將新的查詢參數 ref_id 定義為資料屬性 data-amp-addparams 的一部分，對於需要參數替換的查詢，請提供作為 data-amp-replace 一部分的詳細資訊。透過此方法，網址看起來會很簡潔，並且 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>

更新表單輸入以使用 Client ID 替換：為輸入欄位定義一個名稱，例如 orig_user_id。將表單欄位的 default-value 指定為 AMP Client ID 替換的值：

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

透過執行這些步驟，目標伺服器和/或使用者在點擊連結或提交表單後到達的頁面（目標環境）即可取得用戶端 ID。名稱（或「鍵」）將會是 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 的使用情況，它使用 Cookie 或本機儲存空間作為持久儲存的方式來提供穩定的識別碼，並考量所有關於資料收集、儲存、處理和使用者通知的適用法律和法規。