近期更新
- 新增轉換偵錯報表一節
- 新增加入許可清單以登錄網頁來源的操作說明
如「Attribution Reporting API 設計提案」所述，API 可以就單一 Android 裝置上的下列觸發條件路徑做出歸因：
- 應用程式至應用程式：使用者在應用程式中看到廣告，然後在該應用程式或其他已安裝的應用程式中完成轉換。
- 應用程式至網頁：使用者在應用程式中看到廣告，然後在行動瀏覽器或應用程式瀏覽器中完成轉換。
- 網頁至應用程式：使用者在行動瀏覽器或應用程式瀏覽器中看到廣告，然後在應用程式中完成轉換。
- 網頁至網頁：使用者在行動瀏覽器或應用程式瀏覽器中看到廣告，然後在同一裝置上的相同瀏覽器或其他瀏覽器中完成轉換。
此處的網頁是指顯示在應用程式中的網頁內容。網頁內容可以顯示在行動瀏覽器應用程式環境，或是做為內嵌式網站顯示在非瀏覽器應用程式中。
上述觸發路徑會轉譯成下列要求：
- 廣告技術：更新 API 呼叫和報表，以啟用應用程式至網頁路徑
- 應用程式和瀏覽器：能將網頁歸因來源和網頁觸發條件的登錄傳遞至 Android
本文將說明 Attribution Reporting API 提供哪些擴充功能，以支援應用程式至網頁、網頁至應用程式以及網頁至網頁觸發路徑，也會說明廣告技術和應用程式需要進行哪些變更，才能符合支援這些觸發路徑的要求。
取得 Attribution Reporting API 的存取權
廣告技術平台需要註冊，才能存取 Attribution Reporting API。詳情請參閱「註冊 Privacy Sandbox 帳戶」。
完成註冊程序後，如果 API 收到未註冊的登錄呼叫，就會捨棄該項登錄。
註冊時，廣告技術平台應確保可能用於應用程式和網站的所有伺服器網址，都已用來登錄歸因來源和觸發條件。系統支援多個伺服器註冊網址，但僅支援一個報表來源。這個報表來源衍生自其中一個伺服器登錄網址的網域。
廣告技術相關異動
登錄和歸因相關異動
登錄歸因來源時，廣告技術會指定目的地欄位，也就是發生觸發事件的應用程式套件名稱。為啟用應用程式至網頁的評估功能，我們計劃支援一個應用程式目的地欄位 (應用程式套件名稱) 和一個網頁目的地欄位 (eTLD+1)。
登錄網頁歸因來源或觸發條件時，API 不支援重新導向，因為每個代管網頁內容的應用程式都可能有專屬的權限模型。每個應用程式都有責任追蹤重新導向 (如果支援的話)，以及呼叫每個重新導向躍點的網頁環境 API。
此外，這項整合也可讓廣告技術針對網頁歸因來源使用應用程式專屬的歸因邏輯。舉例來說，您現在可以針對網頁歸因來源指定安裝後歸屬期。
接收應用程式和網頁報表
Android Attribution Reporting API 可同時傳送應用程式和網站轉換的報表。如果廣告技術不想讓網頁和應用程式介面的觸發條件資料與匯總鍵/值保持一致，可以區分網頁轉換和應用程式轉換：
網頁至網頁評估的影響
應用程式會選擇將登錄資訊傳送至 Attribution Reporting API 的時間。這裡有幾個考量要點：
- 該裝置是否支援 Attribution Reporting API？ 我們會回報新信號給應用程式，表明 Attribution Reporting API 在該裝置上是否可用。請參閱應用程式變更一節，瞭解應用程式如何將登錄資訊傳送至 Attribution Reporting API。
- 歸因來源和觸發條件的哪個部分應傳遞至 API？這可由各個應用程式決定，如果應用程式允許，也可由廣告技術決定。如果應用程式有自己的成效評估解決方案，可以考慮改用該項解決方案。可以的話，將所有來源和觸發條件登錄傳遞至 Android Attribution Reporting API，能為應用程式和網站提供最準確的歸因。
以下示例顯示瀏覽器應用程式如何搭配 Attribution Reporting API 使用，以在使用者點擊瀏覽器應用程式和非瀏覽器應用程式中的廣告時，準確地進行評估：
- 第 1 天，使用者在瀏覽器應用程式中點選廣告。
- 瀏覽器應用程式可以選擇使用自己的成效評估解決方案，或將網頁廣告點擊的登錄資訊傳送至 Attribution Reporting API。
- 第 2 天，使用者在非瀏覽器應用程式中點選廣告。
- 點擊會向 API 登錄為歸因來源。由於事件發生在不同的應用程式，瀏覽器應用程式無法查看這次點擊。
- 第 3 天，使用者透過瀏覽器應用程式完成轉換。
- 如果瀏覽器應用程式使用自己的成效評估解決方案同時登錄點擊和轉換，並將該項資訊傳遞至 Attribution Reporting API，廣告技術就不太可能跨多個成效評估解決方案簡化轉換報表。此外，廣告技術可能會同時耗用瀏覽器應用程式的頻率限制和 Attribution Reporting API 的頻率限制。因此，當 API 可用時，建議應用程式傳送所有要登錄到 API 的廣告事件和轉換。
從 WebView 登錄歸因來源和觸發條件
如果應用程式使用 WebView 顯示網頁內容，而不是 Android 廣告，應用程式可以申請加入 registerWebSource() 的許可清單，並提供網站的頂層來源 (而非應用程式套件名稱)，與歸因來源建立關聯。
WebView 與瀏覽器類似，支援使用 registerWebTrigger() 登錄觸發條件，以將觸發條件與頂層來源建立關聯。WebView 不支援登錄應用程式觸發條件；如有這類用途，請聯絡我們。如需 WebView 支援的完整組合清單，請參閱「從 WebView 登錄歸因來源和觸發條件」。
如果 Android 的 Attribution Reporting API 可用，WebView 僅支援在 Attribution-Reporting-Eligible 標頭中登錄 OS，這ㄧ點與瀏覽器不同。如果無法使用 Android 的 Attribution Reporting API，WebView 就不會設定 Attribution-Reporting-Eligible 標頭，也不會進行登錄。
如何使用 OS 登錄歸因來源 / 觸發條件：
- 廣告技術應使用
Attribution-Reporting-Register-OS-Source標頭回應來源登錄，從 WebView 發出對registerSource()或registerWebSource()的次要 API 呼叫。 - 此外，廣告技術也可使用
Attribution-Reporting-Register-OS-Trigger標頭回應觸發條件登錄，從 WebView 發出對registerWebTrigger()或registerTrigger()的次要 API 呼叫。
請注意，如果回應不含前述標頭，或是即使不支援網頁，仍同時包含 Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger 標頭，則整個登錄都會失敗。
如要進一步瞭解 WebView 是否會使用 registerSource()/registerWebSource() 和 registerTrigger() / registerWebTrigger()，以及如何變更這項行為，請參閱「從 WebView 登錄歸因來源和觸發事件」。
轉換偵錯報表
Attribution Reporting API 支援名為轉換偵錯報表的選用功能，可讓廣告技術在廣告 ID 可用時，進一步瞭解歸因報表。偵錯報表有兩種，分別是「歸因成功」和「詳細」報表。無論是跨應用程式還是跨網頁歸因都適用這兩種報表，且兩份報表內的資訊皆相同；唯一差別僅在於傳送偵錯報表時依據的權限不同。
如果是在單一應用程式 (例如同一個瀏覽器應用程式) 中發生的「網頁至網頁」歸因情形，系統只有在第三方 Cookie 可用時才會提供歸因成功報表和詳細報表，這並非取決於廣告 ID 是否可用。
至於「應用程式至網頁」、「網頁至應用程式」和「網頁至網頁」的跨應用程式歸因情形，如果廣告 ID 在應用程式端可用，且廣告技術可以在網站端傳遞相同 (正確) 的廣告 ID，系統就會提供歸因成功報表和詳細報表。 請見下方的「應用程式至網頁」示例，其中來源是在發布商應用程式中，但觸發事件卻發生在瀏覽器應用程式的廣告客戶網站上。
如要啟用「應用程式至網頁」的歸因成功偵錯報表，必須同時符合以下三項條件：
- 使用者不得選擇停用會用到廣告 ID 的個人化功能
- 發布商應用程式必須宣告廣告 ID 權限
- 廣告技術必須在觸發事件登錄作業 (來自網路內容) 中傳遞廣告 ID 值
如要啟用「應用程式至網站」的詳細偵錯報表，請按照下列步驟操作：
- 來源詳細報表僅以發布商端的權限為依據。如要讓系統傳送來源詳細報表，使用者不得選擇停用廣告 ID 個人化功能，且發布商應用程式必須宣告廣告 ID 權限。
- 觸發事件詳細報表則僅以觸發事件端 (本例為網頁) 的權限為準。您必須確保瀏覽器中有第三方 Cookie 可用，才能讓系統傳送觸發事件詳細報表。
- 觸發事件詳細報表可選擇納入
source_debug_key，如果發布商應用程式有廣告 ID 可用，那麼這份報表就會納入source_debug_key。
請注意，無論在何種情況下，廣告技術都還是需要透過來源和觸發事件登錄標頭中的 debug_reporting 字典欄位，選擇接收詳細偵錯報表。
應用程式相關異動
我們將使用一組新的網頁內容 API 呼叫，讓應用程式能夠將網頁歸因來源和網路觸發條件的註冊傳送至 Android 上的 Attribution Reporting API，進而支援跨應用程式與網頁介面的歸因。
完成下列各節所述的登錄步驟後，應用程式與網頁的歸因來源和觸發事件都會儲存在裝置上，而 Attribution Reporting API 則可跨應用程式與網頁介面執行來源優先的最終接觸歸因模式。
如需查看示例，瞭解瀏覽器可如何與 Android Attribution Reporting API 整合，進而啟用跨應用程式和網頁的評估功能，請參閱網頁版 Privacy Sandbox 的提案。在提案中，瀏覽器會新增下列要求標頭：
Attribution-Reporting-Eligible會播送 OS 層級是否支援歸因功能。此時，標頭會指出 Android 的 Attribution Reporting API 是否可用。- 如果可用，廣告技術可視需要使用
Attribution-Reporting-Register-OS-Source進行回應，以便從瀏覽器應用程式發起對registerWebSource()的次要 API 呼叫。 - 此外，廣告技術也可使用
Attribution-Reporting-Register-OS-Trigger標頭回應觸發事件登錄作業，以便從瀏覽器應用程式發起對registerWebTrigger()的次要 API 呼叫。
歸因來源登錄
登錄歸因來源時，應用程式可呼叫 registerWebSource()，這需要下列參數：
- 歸因來源 URI：平台會向這份清單中的每個 URI 發出要求，以擷取與歸因來源相關聯的中繼資料。
每個 URI 都應隨附一個布林值的 Debug 標記，藉此指出報表是否應加入廣告技術所提供的偵錯金鑰。 - 輸入事件：可以是
InputEvent物件 (用於點擊事件) 或null(用於瀏覽事件)。 - 來源出發地：來源發生的出發地 (發布商網站)。
- OS 目的地：發生觸發事件的應用程式套件名稱。
- 網頁目的地：觸發事件的 eTLD+1。
- 已驗證的目的地：用於在使用者點選時進行導覽的 OS 或網頁目的地 URI 意圖。
當 API 向歸因來源 URI 發出要求時，廣告技術應透過新的 HTTP 標頭 Attribution-Reporting-Register-Source 回應，並提供歸因來源中繼資料。這個標頭使用的欄位與「應用程式至應用程式」歸因來源的登錄作業相同，但有幾項變更：
- API 會使用應用程式指定的目的地來驗證廣告技術指定的目的地。如果目的地不同，API 就會捨棄歸因來源登錄作業。
應用程式應在呼叫網頁內容 API 之前驗證網頁目的地。針對點擊操作，應用程式應檢查指定的目的地是否符合使用者要前往的目的地。 - API 會忽略
Attribution-Reporting-Redirects中提供的任何重新導向的 URI。應用程式應自行追蹤重新導向，並針對每個重新導向呼叫registerWebSource()，以便視需要套用自己的權限政策。
應用程式必須加入許可清單，才能呼叫 registerWebSource()。如要加入許可清單，請填寫這份表單。許可清單的用途是就建立對網路環境的信任感這項議題，減少隱私權方面的疑慮。
觸發事件 (轉換) 登錄
在觸發條件註冊時，應用程式可呼叫 registerWebTrigger()，預期會出現下列參數：
- 觸發事件 URI：平台向這份清單中的每個 URI 發出要求，以擷取與觸發條件相關聯的中繼資料
- 目的地來源：發生觸發條件的來源 (廣告客戶網站)
從 WebView 登錄歸因來源和觸發事件
根據預設，WebView 會使用 registerSource() 和 registerWebTrigger()，將來源與應用程式建立關聯，並在觸發事件發生時，將觸發事件與 WebView 的頂層來源建立關聯。
如果應用程式必須使用不同行為 (例如在 WebView 中代管網頁內容的相關行為)，則需要對 androidx.webkit.WebViewSettingsCompat 類別使用 setAttributionRegistrationBehavior 方法。這個方法會指定 WebView 是否應呼叫 registerWebSource()/registerSource() 和 registerWebTrigger()/registerTrigger()。
以下為 setAttributionRegistrationBehavior 的可用選項：
| 值 | 說明 | 用途範例 |
|---|---|---|
| APP_SOURCE_AND_WEB_TRIGGER (預設) | 允許應用程式從 WebView 登錄應用程式來源 (與應用程式套件名稱相關聯的來源)，以及網頁觸發事件 (與 eTLD+1 相關聯的觸發事件)。 | 使用 WebView 放送廣告 (而非啟用網頁瀏覽功能) 的應用程式 |
| WEB_SOURCE_AND_WEB_TRIGGER | 允許應用程式從 WebView 登錄網頁來源和網頁觸發事件。 注意：採用這個選項的應用程式，必須申請加入許可清單才能使用 registerWebSource()。 |
以 WebView 為基礎的瀏覽器應用程式，且其廣告曝光和轉換皆可能發生在 WebView 網站上。 |
| APP_SOURCE_AND_APP_TRIGGER | 允許應用程式從 WebView 登錄應用程式來源和應用程式觸發事件。 | 以 WebView 為基礎的應用程式，且其廣告曝光和轉換應一律與應用程式建立關聯，而非與 WebView 的 eTLD+1 建立關聯。 |
| DISABLED | 停用從 WebView 登錄來源和觸發事件的功能。 請注意，系統仍可能會對歸因來源或觸發事件 URI 發出初始網路呼叫，但會捨棄任何回應，也不會在裝置上儲存任何資料。 |
隱私權和安全性考量
對報表套用隱私權保護機制所帶來的影響
如同主要設計提案中所述，API 會對報表套用隱私權保護頻率限制。部分限制會在來源和目的地應用程式中進行劃分。登錄網頁歸因來源或觸發事件時，頻率限制會依來源或目的地網站劃分，並不是依照應用程式。
如果應用程式維持不同的頻率限制，可能會讓對手能使用 API 的頻率限製以外的應用程式頻率限制。為緩解此疑慮，應用程式應確保並未同時在應用程式的成效評估解決方案與 Android Attribution Reporting API 上登錄指定的歸因來源。
建立對網頁環境的信任感
在網頁環境 API 呼叫中，API 會信任應用程式，以偵測及指定來源和目標的出發地。這可能會引發潛在的隱私權和安全性疑慮：
- 攻擊者可以聲稱代管自家網站，設法規避系統針對任一來源可傳輸的資訊量設下的頻率限制。
- 多個攻擊者可共謀登錄各自的歸因來源，以聲明同一個來源網站的擁有權。這可能會導致來源網站達到廣告技術平台的頻率限制，並造成實際來源網站無法登錄正當的歸因來源。
為減緩此問題，我們將限制哪些瀏覽器或應用程式可以呼叫 registerWebSource()，以證明登錄時使用的來源網站即為向使用者顯示的實際網站。如要加入獲准呼叫 registerWebSource() 的許可清單，請填寫網頁到應用程式歸因報表註冊表單。
如果沒有來源端的共謀，觸發事件端的隱私權和安全性考量就不適用，導致任何應用程式都可以呼叫 registerWebTrigger()。
使用者控制項
應用程式可以繼續支援使用者控制項或權限政策，但前提是必須能在登錄時定義這些項目。舉例來說，如果應用程式允許任何網站層級或使用者層級權限，應用程式就應評估這些權限，並判斷是否要呼叫網頁結構定義的 API。
此外，我們也將支援新的應用程式 API 呼叫，以刪除裝置上儲存的應用程式歸因來源、觸發條件和待處理的報告。舉例來說，如果應用程式允許使用者清除瀏覽記錄，他們可能會呼叫 API，以便刪除該應用程式儲存在他們裝置上的歸因來源、觸發事件和待處理報表。
未來的考量，以及需要大家集思廣益的問題
Attribution Reporting API 的應用程式至網頁互通性目前仍在開發階段。我們也希望針對以下幾個提案，向社群徵求意見回饋：
- 在 Android Privacy Sandbox 支援的裝置上，您要如何使用瀏覽器成效評估解決方案搭配 Android Attribution Reporting API？您會想要將所有內容傳遞至 Android 嗎？
- 每個歸因來源和觸發事件都可能會收到 2 次連線偵測 (ping)，分別來自瀏覽器/應用程式和 Attribution Reporting API，您對此有任何疑慮嗎？
- 我們可以如何協助您簡化各種 API 的偵錯作業？
- 此提案目前不包括驗證應用程式和網站目的地的關聯性。我們日後可能會使用 Digital Asset Links 檢查關聯，藉此驗證這些目的地。這樣會導致任何用途受阻嗎？使用 Digital Asset Links 來進行此驗證是否合理呢？
- 登錄歸因來源時，您必須指定目的地。如果是「網頁至應用程式」的情況，建議您指定應用程式連結。您會使用哪些格式指定這個應用程式連結？
- 登錄「應用程式至網頁」的歸因來源時，您需要使用 Android Attribution Reporting API 從應用程式登錄該來源事件。舉例來說，如果使用者點選廣告，並在瀏覽器或瀏覽器的自訂分頁中開啟點擊內容，則該點擊 (來源事件) 應透過應用程式 (而非瀏覽器環境) 登錄。如果您對此有疑慮，或是有其他用途不屬於這些描述支援流程的問題類別，請與我們聯絡。
為您推薦
- 注意：系統會在 JavaScript 關閉時顯示連結文字
- 歸因報表
- Attribution Reporting API 開發人員指南
- 版本資訊