Android Privacy Sandbox 開發人員預覽版隆重登場!瞭解如何開始使用,並繼續提供意見回饋

歸因報表

提供意見

現有的行動歸因和評估解決方案往往使用廣告 ID 等跨方 ID。Attribution Reporting API 的設計宗旨是要避免仰賴跨方 ID,進一步保護使用者隱私,同時顧及重要使用情境,支援應用程式和網頁的歸因與轉換評估功能。

這個 API 具有以下結構機制,可提供有助於保護隱私的架構 (詳情請參閱本文後續章節):

有了上述機制,就無法跨兩個不同的應用程式或網域連結使用者身分。

Attribution Reporting API 支援下列使用情境:

  • 製作轉換報表:為廣告客戶提供廣告活動、廣告群組和廣告素材等各個維度的轉換 (觸發) 次數與轉換 (觸發) 值,協助他們評估廣告活動的成效。
  • 進行最佳化:提供可用於訓練機器學習模型的個別曝光歸因資料,並製作成事件層級報表,協助最佳化廣告支出。
  • 偵測無效活動:提供可用於偵測及分析無效流量和廣告詐欺行為的報表。

Attribution Reporting API 的運作方式大致如下,詳情請參閱本文後續章節:

  1. 廣告技術平台完成註冊程序,以便使用 Attribution Reporting API。
  2. 廣告技術平台使用 Attribution Reporting API 登錄歸因來源 (廣告點擊或瀏覽)。
  3. 廣告技術平台使用 Attribution Reporting API 登錄觸發事件 (使用者在廣告客戶應用程式或網站中進行轉換)。
  4. Attribution Reporting API 將觸發事件與歸因來源進行比對 (轉換歸因),然後系統透過事件層級報表和可匯總報表,在裝置外部將一或多個觸發事件傳送至廣告技術平台。

為廣告技術平台進行註冊

為了確保隱私保護機制正常運作,所有廣告技術平台 (包括 Google 的平台) 都必須完成簡易註冊程序才能使用 Attribution Reporting API。這個程序的細節仍在開發階段,如有任何相關意見,歡迎與我們分享。

之所以設立註冊程序,是要確保廣告技術平台不會為了針對使用者的網站和應用程式活動取得更多相關資訊,而建立不必要的重複身分。舉例來說,Attribution Reporting API 會限制追蹤量,以及廣告技術平台可針對特定歸因來源和觸發事件查看的資訊量。如要進一步瞭解這些限制,請參閱下方的「在歸因報表中查看評估資料」一節。

假如有正當業務需求 (例如經營多個獨立產品線),企業還是可以註冊多次,但前提是不得合併透過不同註冊身分取得的資料,藉此規避隱私權限制。

在註冊過程中,廣告技術平台必須提供相關資訊,例如:

  • 聯絡資訊和企業資訊
  • 用於接收事件層級報表和可匯總報表的回傳網址
  • Attribution Reporting API 的用途

登錄歸因來源 (點擊或瀏覽)

Attribution Reporting API 將廣告點擊和瀏覽稱為「歸因來源」。如要登錄廣告點擊或廣告瀏覽,請呼叫 registerAttributionSource()。這個 API 預期的參數如下:

  • 歸因來源 URI:平台會向這個 URI 發出要求,擷取與歸因來源相關聯的中繼資料。
  • 輸入事件:可以是 InputEvent 物件 (用於點擊事件) 或 null (用於瀏覽事件)。

當 API 向歸因來源 URI 發出要求時,廣告技術平台應透過新的 HTTP 標頭 Attribution-Reporting-Register-Source 回應,並提供歸因來源中繼資料,當中包含下列欄位:

  • 來源事件 ID:將 64 位元未簽署整數進行編碼的 DOMString。這個值代表與此歸因來源 (廣告點擊或瀏覽) 相關聯的事件層級資料。
  • 目的地:發生觸發事件的 eTLD+1 或應用程式套件名稱。
  • 到期時間 (選填):以秒為單位,指定經過多少時間後應將來源從裝置中刪除。預設值為 30 天,最小值為 2 天,最大值為 30 天。系統會將這個值四捨五入為最接近的天數。
  • 來源優先順序 (選填):經過簽署的 64 位元整數。如果有多個歸因來源能夠與特定觸發事件建立關聯,系統可根據這個值選取應與該觸發事件建立關聯的來源。

    接收到觸發事件時,API 會尋找來源優先順序值最高的相符歸因來源並產生報表。每個廣告技術平台都可定義自己的優先順序策略。

    值越大,表示優先順序越高。

  • 安裝和安裝後歸屬期 (選填):用於決定安裝後事件的歸因,詳情請參閱本文後續章節。

歸因來源中繼資料回應可另外在下列標頭中提供額外資料:

以下程式碼片段呈現出歸因來源資料目前的設計:

Attribution-Reporting-Register-Source: {
  "source_event_id": "[64 bit unsigned integer]",
  "destination": "[eTLD+1 or app package name]",
  "expiry": "[64 bit signed integer]",
  "source_priority": "[64 bit signed integer]"
}
Attribution-Reporting-Register-Aggregate-Source: <aggregation-key-data>
Attribution-Reporting-Redirects: <Ad tech partner URLs>

以下是範例工作流程所含的步驟:

  1. 廣告技術 SDK 呼叫 API,啟動歸因來源登錄程序,指定 API 要呼叫的 URI:

    registerAttributionSource(
        Uri.parse("https://adtech.example/attribution_source?my_ad_click_id=123"),
        myClickEvent);
    
  2. API 使用以下其中一種標頭向 https://adtech.example/attribution_source?my_ad_click_id=123 發出要求:

    <!-- For click events -->
    Attribution-Reporting-Source-Info: navigation
    
    <!-- For view events -->
    Attribution-Reporting-Source-Info: event
    
  3. 這個廣告技術平台的 HTTPS 伺服器以包含下列內容的標頭進行回應:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "234",
        "expiry": "60000",
        "source_priority": "5"
    }
    Attribution-Reporting-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    https://adtechpartner2.example?their_ad_click_id=890
    Attribution-Reporting-Source-Info: navigation
    
  4. API 向 Attribution-Reporting-Redirects 中指定的每個網址發出要求。在這個範例中,指定了兩個廣告技術合作夥伴的網址,因此 API 向 https://adtechpartner1.example?their_ad_click_id=567 發出了一項要求,同時也向 https://adtechpartner2.example?their_ad_click_id=890 發出一項要求。

  5. 這個廣告技術平台的 HTTPS 伺服器以包含下列內容的標頭進行回應:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "789",
        "expiry": "120000",
        "source_priority": "2"
    }
    

    請注意,廣告技術平台的回覆可在 Attribution-Reporting-Register-Source 標頭中指定不同的中繼資料。

根據上述步驟中的要求,系統會登錄三個導覽 (點擊) 歸因來源。

登錄觸發事件 (轉換)

廣告技術平台可以使用 triggerAttribution() 方法登錄「觸發事件」,即安裝或安裝後事件等轉換。

triggerAttribution() 方法預期的參數為觸發事件 URI。API 會向這個 URI 發出要求,擷取與觸發事件相關聯的中繼資料。

API 會遵循重新導向網址。廣告技術伺服器回應應包含名為 Attribution-Reporting-Register-Event-Trigger 的 HTTP 標頭,代表一或多個已登錄觸發事件的相關資訊。這個標頭的內容應採用 JSON 編碼,並包含下列欄位:

  • 觸發事件資料:用於識別觸發事件的資料 (點擊事件為 3 位元,瀏覽事件為 1 位元)
  • 觸發事件優先順序 (選填):經過簽署的 64 位元整數,代表在同一歸因來源的所有觸發事件中,這個觸發事件的相對優先順序
  • 簡化鍵 (選填):經過簽署的 64 位元整數,用於識別相同廣告技術平台針對同一歸因來源多次登錄同一觸發事件的情況

廣告技術伺服器回應可在下列標頭中提供額外資料:

多個廣告技術平台可以登錄同一觸發事件,方法是使用 Attribution-Reporting-Redirects 欄位中的重新導向,或是多次呼叫 triggerAttribution() 方法。建議您使用「簡化鍵」欄位,避免相同廣告技術平台針對同一觸發事件提供多個回應,導致報表中出現重複的觸發事件。

以下程式碼片段呈現出觸發事件資料目前的設計:

Attribution-Reporting-Register-Event-Trigger: {
    // trigger_data returned in reports is truncated to the last 1 or 3 bits,
    // based on conversion type
    "trigger_data": "[unsigned 64-bit integer]",
    "trigger_priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]"
}
Attribution-Reporting-Aggregate-Trigger-Data: <aggregation-key-data>
Attribution-Reporting-Aggregate-Values: <aggregation-value-data>
Attribution-Reporting-Redirects: <Ad tech partner URLs>

以下是範例工作流程所含的步驟:

  1. 廣告技術 SDK 使用註冊時使用的以下 URI 呼叫 API,啟動觸發事件登錄程序:

    triggerAttribution(
        Uri.parse("https://adtech.example/attribution_trigger?app_install=123"));
    
  2. API 向 https://adtech.example/attribution_trigger?app_install=123 發出要求。

  3. 這個廣告技術平台的 HTTPS 伺服器以包含下列內容的標頭進行回應:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "1122",
        // This returns 010 for click-through conversions (CTCs) and 0 for
        // view-through conversions (VTCs) in reports
        "trigger_priority": "3",
        "deduplication_key": "3344",
    }
    Attribution-Reporting-Redirects: https://adtechpartner.example?app_install=567
    
  4. API 向 Attribution-Reporting-Redirects 中指定的每個網址發出要求。這個範例只指定了一個網址,因此 API 會向 https://adtechpartner.example?app_install=567 發出要求。

  5. 這個廣告技術平台的 HTTPS 伺服器以包含下列內容的標頭進行回應:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "5566",
        "trigger_priority": "3",
        "deduplication_key": "3344"
    }
    

    根據上述步驟中的要求,系統會登錄兩個觸發事件。

已套用來源優先歸因演算法

Attribution Reporting API 採用「來源優先歸因演算法」,將觸發事件 (轉換) 對應至歸因來源。如果有多個廣告技術平台登錄單一歸因來源 (詳情請參閱本文後續章節),系統會針對每個廣告技術平台獨立進行歸因作業,將觸發事件歸因至優先順序最高的歸因來源。如果有多個歸因來源的優先順序都相同,API 會選擇最後登錄的歸因來源。其他未獲選的歸因來源都會遭到捨棄,日後無法再用於觸發事件歸因作業。

安裝後歸因

在某些情況下,即使有其他符合資格且更近期發生的歸因來源,也還是必須將安裝後觸發事件歸因至促成安裝的同一歸因來源。

為了支援這個使用情境,這個 API 可讓廣告技術平台設定安裝後歸屬期:

  • 登錄歸因來源時,請指定預期會進行安裝的安裝歸屬期 (一般為 2 到 7 天,接受範圍為 2 至 30 天)。
  • 登錄歸因來源時,請指定安裝後的歸屬期,在這個期間內,任何安裝後的觸發事件均會與引發安裝的歸因來源建立關聯 (一般為 7 至 30 天,接受範圍為 0 至 30 天)。
  • 發生應用程式安裝事件時,Attribution Reporting API 會進行驗證,並在內部將安裝歸因至來源優先歸因來源。不過,該安裝事件不會傳送至廣告技術平台,也不會計入平台專屬的頻率限制配額。
  • 日後如果在安裝後歸屬期內發生觸發事件,系統會將這些事件做為經過驗證的安裝事件,歸因至同一歸因來源 (前提是該歸因來源必須符合資格)。

    有時使用者會解除安裝並重新安裝應用程式,目前我們正在設法支援這類使用情境。

未來我們可能會嘗試延伸這項設計,以支援更進階的歸因模式。

所有應用程式和網頁式觸發路徑組合皆受支援

Attribution Reporting API 可讓系統歸因在單一 Android 裝置上依下列觸發路徑發生的事件:

  • 應用程式至應用程式:使用者在應用程式中看到廣告,然後在該應用程式或其他已安裝的應用程式中完成轉換。
  • 應用程式至網頁:使用者在應用程式中看到廣告,然後在行動瀏覽器或應用程式瀏覽器中完成轉換。
  • 網頁至應用程式:使用者在行動瀏覽器或應用程式瀏覽器中看到廣告,然後在應用程式中完成轉換。
  • 網頁至網頁:使用者在行動瀏覽器或應用程式瀏覽器中看到廣告,然後在同一裝置上的相同瀏覽器或其他瀏覽器中完成轉換。

我們允許網路瀏覽器支援新的網頁式功能,例如與網頁版 Privacy Sandbox 的 Attribute Reporting API 類似的功能,後者可呼叫 Android API 進行跨應用程式/網頁歸因作業。

針對單一歸因來源優先處理多個觸發事件

單一歸因來源可能會產生多個觸發事件。舉例來說,單一購買流程可能牽涉到一個「應用程式安裝」觸發事件、一或多個「加入購物車」觸發事件,以及一個和「購買」觸發事件。根據來源優先歸因演算法,每個觸發事件都會歸因至一或多個歸因來源,詳情請參閱本文後續章節。

可歸因至單一歸因來源的觸發事件有數量限制,詳情請參閱下方的在歸因報表中查看評估資料」一節。如果觸發事件數量超過限制,一個實用的做法是導入優先順序邏輯來取得最重要的觸發事件。舉例來說,廣告技術平台的開發人員可讓「購買」觸發事件的優先順序高於「加入購物車」觸發事件。

如要支援這個邏輯,開發人員可以為觸發事件設定另外的優先順序欄位,這樣在指定報表期內,系統就會先選擇優先順序最高的觸發事件,然後再套用限制。

讓多個廣告技術平台登錄歸因來源或觸發事件

收到歸因報表的廣告技術平台往往不只一個。因此,這個 API 可讓多個廣告技術平台登錄同一歸因來源或觸發事件。廣告技術平台只有在登錄了歸因來源和觸發事件後,才能接收來自 API 的回傳。

歸因來源

registerAttributionSource() 方法支援歸因來源重新導向:

  1. 呼叫 registerAttributionSource() 方法的廣告技術平台會在回應中提供額外的 Attribution-Reporting-Redirects 欄位,代表廣告技術合作夥伴的重新導向網址組合。
  2. 接著,API 會呼叫重新導向網址,讓廣告技術平台合作夥伴能夠登錄歸因來源。

Attribution-Reporting-Redirects 欄位中可以列出多個廣告技術平台合作夥伴網址,且廣告技術平台合作夥伴不得指定自己的 Attribution-Reporting-Redirects 欄位。

這個 API 也可讓不同的廣告技術平台各自呼叫 registerAttributionSource()

觸發事件

第三方登錄觸發事件的方法也類似:廣告技術平台可以使用額外的 Attribution-Reporting-Redirects 欄位,也可以各自呼叫 triggerAttribution() 方法。

如果廣告客戶要使用多個廣告技術平台登錄同一觸發事件,則應使用「簡化鍵」。簡化鍵是用於區分同一事件的重複報表。如未提供簡化鍵,系統可能會將重複的觸發事件做為不重複事件回報給各個廣告技術平台。

歸因範例

在本節所述的範例中,廣告客戶使用了兩個廣告放送技術平台 (Adtech A 和 Adtech B) 和一個評估服務合作夥伴 (MMP)。

首先,Adtech A、Adtech B 和 MMP 都必須完成註冊,才能使用 Attribution Reporting API。

下列清單提供了一系列每天發生的假設的使用者動作,以及歸因報表 API 如何處理 Adtech A、Adtech B 和 MMP 的此類動作:

第 1 天:使用者點擊 Adtech A 放送的廣告

Adtech A 使用自己的 URI 呼叫 registerAttributionSource()。API 向 URI 發出要求,系統使用 Adtech A 伺服器回應的中繼資料登錄該點擊事件。

Adtech A 還在 Attribution-Reporting-Redirects 標頭中加入了 MMP 的 URI。API 向 MMP 的 URI 發出要求,系統使用 MMP 伺服器回應的中繼資料登錄該點擊事件。

第 2 天:使用者點擊 Adtech B 放送的廣告

Adtech B 使用自己的 URI 呼叫 registerAttributionSource()。API 向 URI 發出要求,系統使用 Adtech B 伺服器回應的中繼資料登錄該點擊事件。

與 Adtech A 一樣,Adtech B 也在 Attribution-Reporting-Redirects 標頭中加入了 MMP 的 URI。API 向 MMP 的 URI 發出要求,系統使用 MMP 伺服器回應的中繼資料登錄該點擊事件。

第 3 天:使用者瀏覽 Adtech A 放送的廣告

API 的回應與第 1 天相同,唯一差別在於系統登錄了 Adtech A 和 MMP 兩者的瀏覽事件。

第 4 天:使用者安裝應用程式,該程式使用 MMP 進行轉換評估

MMP 使用自己的 URI 呼叫 triggerAttribution()。API 向網址發出要求,系統使用 MMP 伺服器回應的中繼資料登錄該轉換事件。

MMP 也在 Attribution-Reporting-Redirects 標頭中加入了 Adtech A 和 Adtech B 的 URI。API 向 Adtech A 和 Adtech B 的伺服器發出要求,系統使用伺服器回應的中繼資料相應地登錄該轉換事件。

圖 1 展現了上述清單所述的程序:

圖 1.Attribution Reporting API 如何回應一系列使用者動作的示例。

歸因的運作方式如下:

  • Adtech A 將點擊的優先級設為高於瀏覽,因此將安裝歸因於第 1 天的點擊動作。
  • Adtech B 在第 2 天進行了安裝。
  • MMP 將點擊的優先級設為高於瀏覽,且將安裝歸因於第 2 天的點擊。第 2 天的點擊是優先級最高、最近期的廣告事件。

在歸因報表中查看評估資料

Attribution Reporting API 支援產生下列類型的報表 (詳情請參閱本文後續章節):

  • 事件層級報表:將特定歸因來源 (點擊或瀏覽) 與有限位元的高精確度觸發事件資料建立關聯。
  • 可匯總報表:不一定與特定歸因來源有關聯。相較於事件層級報表,這類報表提供更豐富、更精確的觸發事件資料,但這些資料只會以匯總形式提供。

這兩種報表相輔相成,並可同時使用。

事件層級報表

將某個觸發事件歸因至歸因來源後,系統就會產生事件層級報表,並將報表儲存在裝置上,直到可在其中一個報表傳送期間 (詳情請參閱本文後續章節) 回傳至各個廣告技術平台的回傳網址。

如果只需要少量的觸發事件相關資訊,事件層級報表就會很有用。事件層級觸發事件資料有大小上限。如果是點擊 (也就是說,觸發事件可獲指派八個類別的其中一個類別),上限為 3 位元;如果是瀏覽,則為 1 位元。此外,事件層級報表不支援將高精確度觸發事件端資料 (例如特定價格或觸發時間) 進行編碼。

事件層級報表包含多種資料,例如:

  • 目的地:發生觸發事件的廣告客戶應用程式套件名稱或 eTLD+1
  • 歸因來源 ID:用於登錄歸因來源的歸因來源 ID
  • 觸發事件類型:1 或 3 位元的低精確度觸發事件資料 (視歸因來源類型而定)

事件層級報表套用的隱私保護機制

觸發事件資料的受限精確度

這個 API 提供 1 位元的瀏覽後轉換觸發事件資料和 3 位元的點閱觸發事件資料。歸因來源仍繼續支援完整的 64 位元中繼資料。

為了配合事件層級報表的可用位元數限制,請評估是否要減少觸發事件所透露的資訊量,以及實際的減少方式。

差異化隱私雜訊架構

這個 API 的目標之一,是要使用經過 k 隨機化的回應,為每個來源事件產生加入了雜訊的輸出結果,藉此讓事件層級評估作業符合地方的差異化隱私規範。

無論是否有如實回報歸因來源事件,系統都會套用雜訊。系統在裝置上登錄歸因來源時,有 $ p $ 的機率會以正常的方式登錄,並有 $ 1-p $ 的機率會由裝置從所有可能的 API 輸出狀態中隨機選擇 (包括完全不回報任何內容,或是回報多個假內容)。

k 隨機化回應是一種演算法,在滿足以下等式時具有「ε 差異化隱私」特性

\[ p = \frac{k}{k + e^ε - 1} \]

如果 ε 的值較低,實際輸出結果會受到 k 隨機化回應機制保護。確切的雜訊參數尚未定案,我們日後會再根據意見回饋進行調整。

可用觸發事件 (轉換) 的相關限制

每個歸因來源的觸發事件有數量限制,目前的提案如下:

  • 瀏覽廣告歸因來源為 1 至 2 個觸發事件
  • 點擊廣告歸因來源為 3 個觸發事件

系統會先考量與歸因來源和觸發事件相關的優先順序,再套用這些限制。

每個歸因來源的廣告技術平台數量限制

可與單一歸因來源建立關聯的廣告技術平台有數量限制。系統會先考量與歸因來源和觸發事件相關的優先順序,再套用這些限制。

特定的報表傳送期

廣告瀏覽歸因來源報表會在來源到期時間的 1 小時後傳送。這個到期日可自行設定,但不能短於 2 天或超過 30 天。

廣告點擊歸因來源報表無法自行設定,並會在來源到期前的指定時間點 (與來源登錄時間的相對時間點) 傳送。歸因來源和到期日之間的時間會分成多個報表期。每個報表期都有期限 (從歸因來源時間開始)。在每個報表期結束時,裝置會收集自上一個報表期起發生的所有觸發事件,並傳送已排定的報表。這個 API 支援下列報表期:

  • 2 天:裝置會收集歸因來源登錄後最多 2 天內發生的所有觸發事件。報表會在歸因來源登錄時間的 2 天又 1 小時後傳送。
  • 7 天:裝置會收集歸因來源登錄後 2 到 7 天內發生的所有觸發事件。報表會在歸因來源登錄時間的 7 天又 1 小時後傳送。
  • 自訂時間長度:由歸因來源的「到期時間」屬性定義。報表會在指定到期時間的 1 小時後傳送。這個值不得短於 2 天或超過 30 天。

可匯總報表

可匯總報表也能提供裝置收集到的觸發事件資料,但精確度更高、速度更快,所涵蓋的內容也比事件層級報表更多。這類高精確度資料只能透過「匯總」提供,且不會與特定觸發事件或使用者建立關聯。匯總鍵的大小上限為 128 位元;這讓可匯總報表能夠支援多種報表使用情境,例如:

  • 製作觸發事件價值 (例如收益) 報表
  • 處理更多觸發事件類型

此外,可彙整的報表會使用與事件層級報表相同的來源優先歸因邏輯,但可以支援更多歸因於點擊或瀏覽的轉換。

Attribution Reporting API 準備及傳送可匯總報表方式的整體設計如下 (如圖 1 所示):

  1. 裝置傳送經過加密的可匯總報表至廣告技術平台。
  2. 廣告技術平台傳送一批可匯總報表至匯總服務進行匯總。
  3. 匯總服務讀取一批可匯總報表、解密內容並進行匯總。
  4. 最終匯總結果傳回廣告技術平台。
圖 1. Attribution Reporting API 準備及傳送可匯總報表的流程。

可匯總報表包含下列歸因來源相關資料:

  • 來源:放送廣告的應用程式套件名稱或 eTLD+1 網址。
  • 目的地:發生觸發事件的應用程式套件名稱或 eTLD+1 網址。
  • 日期:歸因來源所代表事件的發生日期。
  • 酬載:以經過加密的鍵/值組合形式收集的觸發事件值,用於在受信任的匯總服務中計算匯總結果。

匯總服務

下列服務都提供匯總功能,並可協助防範不當的匯總資料存取行為。

這些服務是由各方管理,詳情請參閱本文後續章節:

  • 廣告技術平台只應部署匯總服務。
  • 鍵管理隱私預算服務是由名為「驗證者」的信任方執行。這些驗證者會驗證用於執行匯總服務的程式碼是否為 Google 提供的公開程式碼,且所有匯總服務使用者都套用相同的鍵和預算服務。
匯總服務

廣告技術平台必須預先部署以 Google 提供的二進位檔為基礎的「匯總服務」

這項匯總服務會在代管於雲端的受信任執行環境 (TEE) 中運作。TEE 可提供下列安全性優點:

  • 確保在 TEE 中執行的程式碼是 Google 提供的特定二進位檔。除非符合這項條件,否則匯總服務無法存取運作所需的解密鍵。
  • 可確保執行程序安全無虞,不受外部監控或竄改。

上述安全性優勢可讓匯總服務更安全地執行敏感作業,例如存取加密資料。

如要進一步瞭解匯總服務的設計、工作流程和安全性注意事項,請參閱 GitHub 的匯總服務文件

鍵管理服務

這項服務會驗證匯總服務執行的是否為經核准版本的二進位檔,然後在廣告技術平台中為匯總服務提供適用於觸發事件資料的正確解密鍵。

隱私預算服務

這項服務會追蹤廣告技術平台的匯總服務存取特定觸發事件 (可能包含多個匯總鍵) 的頻率,並設下適當的解密次數限制。每個觸發事件只能解密一次。

Aggregatable Reports API

這個 API 會為可匯總報表提供內容,並使用為事件層級報表登錄歸因來源時所用的相同基礎 API。以下各節說明這個 API 的延伸功能。

登錄可匯總來源資料

當 API 向歸因來源 URI 發出要求時,廣告技術平台可登錄匯總鍵清單,方法是以新的 HTTP 標頭 Attribution-Reporting-Register-Aggregate-Source 回應,並為清單中的各個匯總鍵填入下列欄位:

  • 來源事件 ID:鍵名稱的字串,可做為合併鍵與觸發事件端鍵結合,藉此形成最終鍵。
  • 鍵:鍵的位元字串值。
  • 鍵偏移:用於將這個鍵與觸發事件端鍵結合的偏移索引整數值。

使用「鍵偏移」欄位串連位元字串,將這個鍵和觸發事件端的鍵結合,即可產生最終鍵。最終鍵的長度上限為 128 位元,超過的部分會遭到截斷。

在以下範例中,廣告技術平台會使用這個 API 收集下列資訊:

  • 廣告活動層級的匯總轉換計數
  • 地理區域層級的匯總購物價值
Attribution-Reporting-Register-Aggregate-Source:
[{
  // Generates a "101011001" key prefix named "campaignCounts".
  "source_event_id": "campaignCounts",
  "key_piece": "101011001", // User saw ad from campaign 345 (out of 511).
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
},
{
  // Generates a "101" key prefix named "geoValue".
  "source_event_id": "geoValue",
  // Source-side geo region = 5 (US) but pad with 0s since the shop operates in
  // ~100 separate countries.
  "key_piece": "0000101",
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
}]

登錄可匯總觸發事件

登錄觸發事件時要提供兩個額外標頭。

第一個標頭是用來在觸發事件端登錄匯總鍵清單。廣告技術平台應以 HTTP 標頭 Attribution-Reporting-Aggregate-Trigger-Data 回應,並為清單中的每個匯總鍵填入以下欄位:

  • 鍵:鍵的位元字串值。
  • 鍵偏移:將歸因來源鍵與觸發事件鍵結合時做為偏移索引的整數值。
  • 來源鍵:包含歸因來源端鍵名稱的字串清單,這些鍵應與觸發事件鍵結合,以形成最終鍵。

以下程式碼片段接續了在可匯總報表中登錄匯總來源資料範例的內容:

Attribution-Reporting-Aggregate-Trigger-Data:
[
  // Each dictionary independently adds pieces to multiple source keys.
  {
    "key_piece": "10",// Conversion type purchase = 2
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 9,
    // Apply this suffix to:
    "source_keys": ["campaignCounts"]
  },
  {
    "key_piece": "10101",// Purchase category shirts = 21
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 7,
    // Apply this suffix to:
    "source_keys": ["geoValue" ]
  }
]

第二個標頭是用來登錄應為各個鍵做出貢獻的值清單。廣告技術平台應以 HTTP 標頭 Attribution-Reporting-Aggregate-Values 回應。

每個觸發事件都可為可匯總報表貢獻多次。任何指定歸因來源的貢獻總數會受到 $ L1 $ 參數的限制,該參數為特定歸因來源的所有匯總鍵貢獻 (值) 總和上限。如果超過限制,系統就會自動捨棄後續貢獻。初始提案是將 $ L1 $ 設為 $ 2^{16} $ (65536)。匯總服務中的雜訊會與這項參數成比例增加。因此,建議您根據分配到的 $ L1 $ 隱私預算比例,妥善調整針對特定匯總鍵回報的值。這個做法可讓匯總報表在套用雜訊後盡可能保有高精確度。這項機制相當具有彈性,可支援許多匯總策略。

在以下範例中,系統會將 $ L1 $ 的貢獻分給 campaignCountsgeoValue,平均分配隱私預算:

Attribution-Reporting-Aggregate-Values:
{
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
    "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
    "geoValue": 1664
}

上述範例會產生以下匯總計數:

[
  // campaignCounts:
  {
    // The attribution source key piece "101011001" (offset 0)
    // is concatenated with  "10" (offset 9) trigger key piece to form
    // the final key "10101100110" = 1382.
    "key": "1382",
    "value": 32768
  },
  // geoValue:
  {
    // The attribution source key piece "0000101" (offset 0)
    // is concatenated with  "10101" (offset 7) trigger key piece to form
    // the final key "000010110101" = 181.
    "key": "181",
    "value": "1664"
  }
]

您可以反轉縮放比例係數,藉此取得正確的值,對套用的雜訊進行模數運算:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

差異化隱私

這個 API 的一個目標,是提供可支援差異化隱私匯總評估作業的架構,實際做法為加入與 $ L1 $ 預算成比例的雜訊,例如採以下分布方式的雜訊:

\[ Laplace(\frac{ε}{L1}) \]

未來的考量,以及需要大家集思廣益的問題

Attribution Reporting API 目前仍在開發階段。我們也在探索日後有可能支援的功能,例如非最終點擊歸因模式和跨裝置評估使用情境。

此外,我們也希望針對以下幾個問題,向社群徵求意見回饋:

  1. 我們打算讓多個廣告技術平台登錄歸因來源和觸發事件,藉此提供第三方評估功能。在目前的提案中,只有最初發出 API 呼叫的廣告技術平台能夠指定第三方廣告技術平台清單。為了簡化 API 設計,我們可以改為讓廣告技術平台僅指定下一個廣告技術平台來串連重新導向。
  2. 如要啟用應用程式至網頁評估功能 (觸發事件可在應用程式或網頁中發生),廣告技術平台必須在歸因來源和觸發事件登錄項目中,提供相同的「目的地」欄位。我們目前正在評估使用網頁 eTLD+1 是否合理 (即使觸發事件是在應用程式中發生)。
  3. 如果廣告技術平台多次登錄同一觸發事件,就會重複回報觸發事件,為了避免這個情形,建議您使用簡化鍵。我們目前正在評估應用程式是否能夠將這個簡化鍵傳遞至所有廣告技術平台,包括第三方平台。
  4. 關於歸因來源登錄,我們正在評估建議的第三方設計和重新導向設計是否可行,包括自歸因網路。具體來說,我們想知道是否需要資訊公開,才能看到重新導向路徑中的所有使用者。
  5. 我們正在評估是否存在多個歸因來源 (包括網頁和應用程式歸因來源) 可導致觸發事件,以及是否存在必需的的特殊歸因。
  6. 登錄歸因來源時,廣告技術平台只能指定一個應用程式目的地。我們想知道這是否能夠滿足您的使用需求。
  7. 我們想瞭解您在哪些情形下希望 API 送出已驗證安裝的報表。這些報表會計入廣告技術平台中相應的頻率限制。