AdMob 和 AdSense 計畫政策

Google 的額外同意聲明模式技術規格

本文件制定了一份暫時的技術規格 (稱為「額外同意聲明模式」),僅供用於搭配歐洲互動廣告局的「資訊公開和同意聲明架構第 2.0 版」使用,讓尚未註冊加入歐洲互動廣告局全球供應商清單 (GVL) 的供應商有機會提供服務。透過這份規格,對於尚未註冊加入歐洲互動廣告局全球供應商清單,但已列入 Google 廣告技術供應商 (ATP) 名單的公司,發布商、同意聲明管理供應商 (CMP) 及合作夥伴就能收集額外的同意聲明,搭配已導入的「資訊公開和同意聲明架構第 2.0 版」。

相關資源

額外同意聲明模式的組成要素

在「額外同意聲明模式」中,我們同時支援:

  • IAB「資訊公開和同意聲明架構第 2.0 版」規格中定義的資訊公開和同意聲明字串 (TC 字串),其中包含為 IAB 全球供應商清單 (GVL) 廠商建立的資訊公開和同意聲明。和
  • 精簡 addtl_consent 字串 (AC 字串),其中包含已獲得使用者同意但未註冊 IAB 的 Google 廣告技術供應商清單。

此規格定義下列項目:

  1. 額外同意聲明字串格式
  2. 用來支援額外同意聲明字串的「資訊公開和同意聲明架構第 2.0 版」同意聲明管理平台 API 擴充功能
  3. 額外同意聲明字串的儲存方式
  4. 如何透過數位廣告鏈傳遞額外同意聲明字串

額外同意聲明 (AC) 字串格式

額外同意聲明字串中儲存了哪些資訊?

額外同意聲明字串包含以下三個部分:

  • 第 1 部分:規格版本編號,例如「1」
  • 第 2 部分:分隔符號「~」
  • 第 3 部分:經使用者同意、以點分隔的 Google 廣告技術供應商 (ATP) ID 清單,例如:「1.35.41.101」

舉例來說,AC 字串 1~1.35.41.101 代表使用者已同意 ID 為 13541101 的廣告技術供應商,且該字串採用第 1.0 版規格中定義的格式來建立。

誰應該建立額外同意聲明字串?

AC 字串只能由已註冊歐洲互動廣告局資訊公開和同意聲明架構的同意聲明管理平台,遵照 IAB 政策使用獲派的同意聲明管理平台 ID 編號來建立。廠商或任何其他第三方服務供應商均不得自行建立 AC 字串。

Google 廣告技術供應商名單將發布於何處?

Google 將於下列位置發布未註冊 IAB 的廣告技術供應商清單及其 ID:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

何時應建立額外同意聲明字串?

只有在發布商遵守 Google 歐盟地區使用者同意授權政策的情況下,才能建立 AC 字串。請特別注意,若使用者尚未提供下列具法律效益的同意聲明,則不得建立 AC 字串:1) 依法使用 Cookie 或其他本機儲存空間;和 2) 按照 Google 的歐盟地區使用者同意授權政策提供同意聲明,由廣告技術供應商收集、分享及使用個人資料以用於廣告個人化。

AC 字串只能做為 TC 字串的輔助字串,不得用來取代 TC 字串。如果 Google 收到的請求中不包含 TC 字串,Google 將不會處理該請求,並將捨棄其中的 AC 字串。

如果同意聲明管理平台已導入此規格,則必須確保所建立的 AC 字串只包含已發布的 Google 廣告技術供應商檔案中的 ID (亦即不在全球供應商清單上的廠商)。Google 收到 TC 字串時,將檢查其中列出的全球供應商清單版本。如果有廠商已註冊該版本,TC 字串會控制該廠商,並忽略該廠商的任何 AC 字串項目。在這種情況下,Google 保留從 AC 字串中移除此等「重複」項目,以及隨 TC 字串傳遞此等經修改的 AC 字串的權利。Google 以外的廠商均不得修改額外同意聲明字串。

同意聲明管理平台 API 擴充功能

建議您將現有的「資訊公開和同意聲明架構第 2.0 版」同意聲明管理平台 JavaScript API 擴充為允許傳回 AC 字串。說得更精確些,我們建議您將 TCDataInAppTCData JSON 物件擴充為傳回這項資料。

TCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}

InAppTCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}

應如何儲存額外同意聲明字串?

網頁

同意聲明管理平台可自行選擇儲存機制。

應用程式內

應由同意聲明管理平台 SDK 使用 NSUserDefaults (iOS) 或 SharedPreferences (Android) 來儲存 AC 字串。這種方法可以:

  • 讓廠商輕鬆存取額外同意聲明字串
  • 讓額外同意聲明字串的保留時間橫跨多個應用程式工作階段
  • 讓 AC 字串得以在多個同意聲明管理平台之間移動,以使發布商彈性變換所使用的同意聲明管理平台 SDK

如果發布商選擇從應用程式中移除同意聲明管理平台 SDK,則應負責為使用者清除 AddtlConsent 值,以免廠商繼續使用其中包含的 AC 字串。

NSUserDefaults and SharedPreferences 中的儲存和查詢鍵
IABTCF_AddtlConsent

字串:包含規格版本和已獲同意的廣告技術供應商 ID 的額外同意聲明字串

如何透過數位廣告鏈傳遞額外同意聲明字串

出價要求

我們將重複使用 ConsentedProvidersSettings 填入不在全球供應商清單上的下游廠商。

message ConsentedProvidersSettings {
 // 一組供應商 ID;發布商已告訴 Google,其歐洲經濟區使用者已針對該 ID 對應的供應商
 // 提供下列具法律效益的同意聲明:1) 依法使用 Cookie 或其他本機儲存空間;
 // 和 2) 按照 Google 的歐盟地區使用者同意授權政策提供同意聲明,
 // 由廣告技術供應商收集、分享及使用個人資料以用於廣告個人化。
 // 供應商 ID 與供應商名稱的對應表張貼於 providers.csv。
 repeated int64 consented_providers = 2 [packed = true];
}

 // 供應商相關資訊;發布商已告訴 Google,
 // 此等供應商的歐洲經濟區使用者已按照 Google 歐盟地區使用者同意授權政策
 // 提供同意聲明,允許將其個人資料用於廣告個人化。
 // 只有在 regs_gdpr 設為 true 時,才會填入此欄位。
 optional ConsentedProvidersSettings consented_providers_settings = 42;

網址式服務

廣告素材顯示時,<img> 標記下方可能會包含一些像素,例如 <img src="http://vendor-a.com/key1=val1&key2=val2">;這個像素會從瀏覽器傳送 HTTP GET 請求到廠商的網域。

由於像素位於 <img> 標記內,無法執行 JavaScript,因此無法使用同意聲明管理平台 API 來取得 TC 字串。我們會按照類似支援 TC 字串的方式,在像素網址中應插入 AC 字串的位置提供標準網址參數和巨集。

網址參數 相應的巨集 在網址中的表示法
addtl_consent ADDTL_CONSENT &addtl_consent=${ADDTL_CONSENT}

範例 1

圖片網址必須包含由網址參數和巨集 &addtl_consent=${ADDTL_CONSENT} 組成的鍵/值組合,廠商 A 才能接收 AC 字串。最終網址為:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

 

範例 2

如果特定要求中的額外同意聲明字串為:1~1.35.41.101

廣告素材的呼叫端或顯示端會以實際的 AC 字串取代網址中的巨集,因此包含該巨集的原始像素在呼叫指定伺服器時,會變成下列形式:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

這對您有幫助嗎?
我們應如何改進呢?

還有其他問題嗎?

登入即可獲得其他支援選項,快速解決您的問題