使用 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，從 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 並與 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 中加入用戶端 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 中建議將 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")，它將出現在網址中，並指示使用者來源情境的識別碼。將此查詢參數設定為等於 AMP 用戶端 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 中提供這些詳細資訊。 透過這種方法，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>

更新表單輸入以使用 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"
/>

透過採取這些步驟，Client ID 可供目標伺服器使用，並且/或者作為使用者點擊連結或提交表單後所到達頁面（目的地內容）上的 URL 參數。 名稱（或「鍵」）將會是 ref_id，因為這是我們在上述實作中定義的方式，並且將具有與 Client ID 相等的值。 例如，透過點擊上面定義的連結（<a> 標籤），使用者將導覽至此 URL

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

當使用者到達包含 ref_id 值的頁面時，無論是作為 URL 參數還是在標頭中，我們都有機會共同處理 ref_id 識別碼以及透過頁面本身公開的識別碼（即 Cookie 值）。 透過將兩者都包含在分析 ping 中，您的分析伺服器可以同時處理這兩個值，並且在知道它們相關的情況下，在您的後端反映這種關係。 下一步提供有關如何執行此操作的詳細資訊。

擷取 URL 查詢參數

透過使用替換功能，我們設定了連結導覽流程或表單提交流程，將資訊（特別是 Client ID）公開給目標伺服器，並且/或者作為 URL 參數，使用者完成導覽後可以在用戶端讀取該參數。

如果資訊僅公開給伺服器，例如透過表單 POST，那麼您可以繼續處理資訊並呈現結果頁面。 在處理此類資料時，請注意以下詳細說明的參數驗證相關步驟。

如果資訊可透過 URL 取得，並且您希望處理它，則可以使用幾種方法

• 在重新導向期間處理（伺服器端處理）
• 在到達頁面處理（用戶端處理）

在重新導向期間處理（伺服器端處理）

若要在重新導向期間處理，請在伺服器上處理請求並擷取相關參數。 請注意以下詳細說明的參數驗證相關步驟。 處理資料，結合包含其他相關識別碼的 Cookie 值，然後重新導向至不包含參數的 URL。

在到達頁面處理（用戶端處理）

若要在到達頁面處理，方法會因該頁面是 AMP 頁面還是非 AMP 頁面而異。

更新 AMP 頁面： 在您的 amp-analytics 設定中使用查詢參數替換功能，以取得 URL 內的 ref_id 識別碼值。 查詢參數功能採用一個參數，該參數指示 URL 中所需鍵值對的「鍵」，並傳回對應的值。 使用 Client 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。 接下來我們將介紹如何處理作為 inbound 分析 ping 一部分的這兩個識別碼。

在我們繼續之前，請務必注意以下參數驗證中描述的步驟，並確保您願意信任 orig_user_id 和 user_id 所指示的兩個值。

檢查您的對應表中是否存在與 inbound 分析 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 中的值時，請務必驗證 referrer 以確保您可以信任這些值。

例如，在上面的步驟中，我們建構了以下 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 查詢參數接收的值的建議步驟： 確認到達頁面的 referrer 符合您期望看到的 URL。 這通常應該是您先前在有效的 CORS 請求中看到攜帶先前看到的識別碼值的 URL。 我們建議您僅接受此類已知的識別碼。

在非 AMP 頁面上，直接在用戶端檢查 document.referrer，或將該值作為分析 ping 的一部分傳遞，以便能夠在伺服器端進行驗證。 如果 referrer 值是您可以信任的值，那麼您可以接受並處理源自到達頁面 URL 的值，例如上面範例中的 orig_user_id。

在 AMP 頁面上，使用 Document Referrer 替換變數，將 referrer 值作為分析 ping 的一部分傳遞。 伺服器端處理是唯一可用的選項。 為了說明，以下是到達頁面可以傳送的分析 ping，其中包含 (1) 當前頁面的 Client ID 值，(2) 透過 URL 傳遞的值（我們已設定為參照頁面中的 Client ID 值），以及 (3) referrer 資訊本身，以驗證 (2) 的值： https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}&referrer=${documentReferrer}

如果您無法信任 referrer，則拒絕透過 URL 參數提供的任何值，並且不要使用它們。

強烈建議的做法

僅保留一個關聯

任何兩個內容之間的識別碼應僅維護一個關聯。 如果您先前與 Cookie 或您發布的其他使用者識別碼關聯的 AMP Client ID 與您發布的新 Cookie 或使用者識別碼一起出現，則您應刪除針對先前 Cookie 和使用者識別碼持有的所有狀態。

這些步驟將有助於確保與使用者對隱私的期望保持一致。 如前幾節所述，在 AMP 中管理使用者狀態通常涉及跨多個顯示 AMP 內容的內容儲存和關聯不同的識別碼。 絕不應濫用這種情況來重建資料或執行使用者不期望或您未明確向使用者揭露的追蹤，例如，在使用者刪除您網站的 Cookie 後。

尊重 Cookie 和本機儲存空間刪除

您應尊重所有適用於使用者的隱私控制，包括建立刪除所有 Cookie 和本機儲存空間的能力的任何此類控制。 在任何時候都不應使用 AMP Client ID 或 AMP 基礎架構來重建已刪除的識別碼，在使用者明確刪除識別碼關係的一方之後。

遵守當地法律和法規

關聯來自兩個或多個網域的 Cookie 和/或識別碼可能需要在某些司法管轄區更新您的隱私權政策、提供額外的使用者揭露或取得最終使用者同意。 每個發布商都應根據所有關於資料收集、儲存、處理和使用者通知的適用法律和法規，分析 AMP Client ID 的使用情況，AMP Client ID 使用 Cookie 或本機儲存空間作為持久儲存的方式來提供穩定的識別碼。