「IAB 歐盟資訊公開和同意聲明架構第 2.2 版」導入作業的疑難排解

互動廣告協會 (IAB) 於 2023 年 5 月 16 日宣布推出 IAB 資訊公開和同意聲明架構第 2.2 版。做為供應商，Google 自 2023 年 7 月 11 日起開始接受資訊公開和同意聲明架構第 2.2 版字串。在此日期前傳送資訊公開和同意聲明架構第 2.2 版字串的要求，可能會導致錯誤。

• 資訊公開和同意聲明架構第 2.1 版：我們將繼續接受資訊公開和同意聲明架構第 2.1 版字串，但隨著業界逐步採用資訊公開和同意聲明架構第 2.2 版，建議 CMP 遵循 IAB 規定 的時程完成導入。
• Google 同意聲明管理工具：Ad Manager、AdSense 和 AdMob「隱私權與訊息」分頁中提供的 Google 同意聲明管理工具，預計在 11 月初前針對 GDPR 訊息，支援資訊公開和同意聲明架構第 2.2 版，以符合 IAB 對 CMP 要求的最新導入期限 (2023 年 11 月 20 日)。

歐洲互動廣告局 (IAB Europe) 與互動廣告局科技實驗室 (IAB Tech Lab) 和共同成員公司攜手開發的「資訊公開和同意聲明架構第 2.0 版」已拍板定案，Google 現已全面支援「資訊公開和同意聲明架構第 2.0 版」。

為了讓發布商有時間因應歐洲互動廣告局 (IAB Europe)「資訊公開和同意聲明架構第 2.0 版」推出後可能遇到的錯誤和設定不當問題，我們會將偵測到的錯誤製作成報表，並提供 150 天寬限期讓發布商解決相關錯誤。

---

本文將說明如何解決「資訊公開和同意聲明架構第 2.2 版」的導入錯誤，內容包括：

• 新版指南
• 政策中心
• 錯誤報表
• 疑難排解

 

---

新版指南

異動項目

• 根據資訊公開和同意聲明架構規定，需每隔 13 個月向使用者發出提醒並重新取得同意聲明：

  依據 IAB 資訊公開和同意聲明架構政策，您每 13 個月 (390 天) 都必須至少提醒使用者一次，以確認對方的同意聲明選項。如果同意聲明決定超過 13 個月，Google 就會認定資訊公開和同意聲明字串失效，不會向該使用者放送廣告。建議您與同意聲明管理平台合作，在 13 個月上限期滿之前提醒使用者確認同意聲明選項。

• 錯誤類型 3.2 已經排除。最近 13 個月內更新的資訊公開和同意聲明 (TC) 字串仍維持有效。

常見錯誤的修正方式

請採行下列做法來解決 Ad Manager、AdSense 和 AdMob 的一些常見錯誤：

考慮以不會用於營利的資訊公開和同意聲明字串向使用者重新徵求同意聲明
^{(錯誤 1.1、3.1、4.1、5.1、5.2 和 6.1)}

相關錯誤

錯誤 1.1；此做法可能也適用於錯誤 3.1、4.1、5.1、5.2 和 6.1。

新版指南

考慮重新向使用者徵求同意聲明。

原因

若發布商在導入期間的任何階段，曾經使用架構外的全域範圍字串、無效的測試用 CMP ID 或 GVL ID，或未將 Google 列為取得適當同意聲明的服務供應商，建議重新向使用者徵求同意聲明。

錯誤 1.1、1.2、1.3：請務必查看這些錯誤是否影響到大量使用者。如果是，CMP 端可能有錯誤；請確認 Google 已就必要目的取得同意聲明，且可基於同意聲明「和」正當利益提供服務 (供應商 ID 755)。

IAB 規範

根據 IAB 規範，CMP 可以快取同意聲明字串的期限是 13 個月。

之前有某些 CMP 會保留並延長首次同意的日期，但這是錯誤的做法；同意日期一律應為同意聲明字串的新日期。

建議做法：確保 CMP 在 500 毫秒內，傳回來自 AddEventHandler 的呼叫
^{(錯誤 2.1a、2.1b、2.0a、2.0b，以及 2.0c)}

相關錯誤

錯誤 2.1a (此做法可能也適用於錯誤 2.1b、2.0a、2.0b，以及 2.0c)。

新版指南

雖然現在已經沒有逾時相關規定，但我們仍建議 CMP 仔細檢查導入方式，確保能夠立即將呼叫傳回給 AddEventListener getTCData。

如果 CMP 沒有回應，請求可能就無法營利。

原因

Google 遵循 IAB 規範，要求 CMP 立即回應 AddEventListener 函式。如果 CMP 沒有立刻回應，請求可能就無法營利。

此外，CMP 回應是事件鏈的一部分，會影響送出廣告請求的速度。縮短網頁載入與廣告請求的間隔時間，有助於減少發布商錯失的廣告曝光次數。

IAB 規範

適用的 IAB 規範：IAB AddEventListener 規格 (存放在 GitHub)

登錄目前的資訊公開和同意聲明資料後，就算 CMP 狀態為 loading，且 CMP 中的資訊公開和同意聲明資料不完整，仍然必須立即呼叫 AddEventListener 回呼，讓呼叫指令碼存取已登錄的 listenerId。此外，每次更改資訊公開和同意聲明字串時，除非已經使用 RemoveEventListener 移除回呼，否則都必須呼叫回呼。

政策中心

如果應用程式或網站不符合 Google 同意聲明管理規定，政策中心就會通知發布商。

錯誤報表

如果系統偵測到發布商的一或多個網站或應用程式有資訊公開和同意聲明字串相關問題，就會透過產品使用者介面通知發布商。發布商可以在帳戶的「歐盟使用者同意聲明」頁面中，點選「下載資訊公開和同意聲明架構錯誤報表」來取得報表，當中會詳細列出最近 7 天偵測到的錯誤。

系統曾在過去 7 天內偵測到錯誤時，才會製作這份報表。

如要存取「歐盟使用者同意聲明」頁面與資訊公開和同意聲明架構錯誤報表，請按照下列步驟操作：

• Ad Manager：按一下「管理」「歐盟使用者同意聲明」。
• AdMob 和 AdSense：按一下「封鎖控制項」「歐盟使用者同意聲明」。

這份報表會針對每項偵測到的錯誤列出下列資訊：

• 網域/MobileAppID：設定不當的網站或行動應用程式。
• 廣告單元路徑：與錯誤相關聯的廣告單元。
• 錯誤代碼：錯誤的對應代碼。
• 錯誤數：在過去一週觀察到發生錯誤的查詢數量。
• 上次偵測到錯誤的日期：最近一次偵測到錯誤的日期。

發布商可使用報表中列出的錯誤代碼，在下方疑難排解表格中找到建議採取的動作並修正錯誤。

疑難排解

為協助發布商修正設定不當的 IAB 資訊公開和同意聲明架構第 2.2 版整合問題，我們在下方表格中彙整常見的資訊公開和同意聲明字串錯誤類型，以及對應的疑難排解建議做法。

請參閱表格以瞭解廣告請求層級發生的問題，以及對應的系統行為。

有限同意聲明情境

如果某項請求有多個錯誤，下列三種情境的優先順序一律高於設定不當。

情境	說明	建議採取的行動
1.1	不論目的為徵求同意聲明或顧及正當利益，皆不允許 Google 做為供應商。	確認使用者是否刻意拒絕 Google 做為供應商、同意聲明管理平台是否導入錯誤，或者是否有任何發布商限制。
1.2	未針對歐洲經濟區國家/地區和英國取得「目的 1」的同意聲明。	確認使用者是否刻意不允許「目的 1」，或是 CMP 導入方式有誤。 瑞士發布商若未向使用者要求同意聲明，請務必正確設定「PublisherCC」和「PurposeOneTreatment」欄位。   2021 年 12 月起，我們將不再根據德國的《電信與電子媒體資料保護法》(Telecommunications and Telemedia Data Protection Act) 規定，檢查 PurposeOneTreatment 對於來自德國的廣告請求所進行的處理。
1.3	已取得「目的 1」的同意聲明，但缺乏基本廣告的法律依據。	確認使用者是否刻意拒絕基於其他用途的正當利益，或是 CMP 導入方式有誤。

設定不當

若有設定不當，系統就不會再按廣告請求供應廣告。

錯誤	說明	建議採取的行動
2.1a	由於 CMP 狀態為 stub、loading 或 error，因此標記或 SDK 未收到資訊公開和同意聲明字串。	若您以手動叫用函式的方式請求廣告，請確認 getTCData 的回應為 TCData.eventStatus = 'tcloaded' 或 'cmpuishown' + 'useractioncomplete'；這類回應代表 CMP 已準備就緒，可為使用者提供同意聲明選項。 若您不是以手動叫用函式的方式請求廣告，請向您的 CMP 確認是否已導入 getTCData 支援功能，且能傳回 TCData.eventStatus = 'tcloaded' 或 'cmpuishown' + 'useractioncomplete'。這類回應代表使用者同意聲明功能已準備就緒，可透過 API 使用。
2.1b	同時符合以下兩項條件： CMP 設定了 &gdpr=1 請求中包含 &gdpr_consent=，但資訊公開和同意聲明字串為空白。	請洽詢 CMP，確認對方已根據 IAB 資訊公開和同意聲明架構的技術規格正確導入 API。
2.0a	資訊公開和同意聲明字串未採用 Base64 編碼格式，因此無法剖析。 例如：“2”	在 gdpr_consent= 參數中，CMP (或發布商) 只能傳送採用 Base64 編碼格式的資料。
2.0b	發生解碼錯誤，因此無法剖析資訊公開和同意聲明字串。 例如：包含的位元數不正確	CMP 應修正資訊公開和同意聲明字串導入錯誤。
2.0c	發生資料錯誤，因此無法剖析資訊公開和同意聲明字串。 例如：時間戳記不正確、供應商 ID 過大	CMP 應修正資訊公開和同意聲明字串導入錯誤。

資訊公開和同意聲明字串問題

當發生與廣告請求有關的資訊公開和同意聲明字串問題時，系統就會捨棄廣告請求且不再供應廣告。

錯誤	說明	建議採取的行動
3.1	CMP ID 無效。	確認 CMP 已通過 IAB 驗證，且已在資訊公開和同意聲明字串中正確設定其 ID。 如果資訊公開和同意聲明字串產生時，CMP 的資格有效，但之後遭 IAB 刪除，則必須透過有效的 CMP 重新取得同意聲明。
3.2	已停止使用。	沒有任何建議採取的行動。此錯誤原先用來表示資訊公開和同意聲明字串的建立日期，距今已超過 13 個月。

必須重新取得同意聲明

您需要重新向使用者取得同意聲明。如果取得同意聲明的時間距今已超過 13 個月，抑或所用的全球供應商清單 (GVL) 版本當中不含 Google，請重新向使用者取得同意聲明，否則系統會捨棄廣告請求，並且不供應廣告。

錯誤	說明	建議採取的行動
3.3	資訊公開和同意聲明字串最近一次的更新日期距今已超過 13 個月。	CMP 應刪除舊的資訊公開和同意聲明字串，並重新取得同意聲明。 如果在 CMP 將同意聲明列為失效並重新徵得使用者同意前，發出包含過期資訊公開和同意聲明字串的廣告請求，就可能發生這類錯誤 (但數量不多)。 如果您在應用程式中使用 Google 同意聲明管理工具和 UMP SDK，請確認是否已正確導入 UMP SDK，且每次應用程式啟動時都會呼叫 requestConsentInfoUpdate。
4.1	用來產生資訊公開和同意聲明字串的 GVL 版本內不包含 Google。	請使用最新版 GVL 重新取得同意聲明。

全域範圍和架構外範圍

與全域範圍和架構外範圍 (Ad Manager、AdMob、AdSense) 有關的問題。如果資訊公開和同意聲明字串指出「架構外」或「全域範圍」，系統就不會放送廣告。

錯誤	說明	建議採取的行動
5.1	資訊公開和同意聲明字串允許架構外的同意聲明。	要求您的 CMP 從資訊公開和同意聲明字串中移除架構外信號。
5.2	全域範圍的資訊公開和同意聲明字串。	要求您的 CMP 改用特定服務專用的資訊公開和同意聲明字串。

廣告放送量受限

系統會放送受限制的廣告。

錯誤	說明	建議採取的行動
6.1	資訊公開和同意聲明字串版本為 1 或 1.1 (第 1.0 版字串)。	CMP 應傳送資訊公開和同意聲明架構第 2.2 版字串。

Google 將處理問題

若發生這類問題，Google 會視情況處置，並繼續進行正常的資訊公開和同意聲明架構處理程序。

錯誤	說明	建議採取的行動
7.1	gdprApplies 尚未定義或設定為無效/無法解讀的值，但存在有效的資訊公開和同意聲明字串。	不適用
7.2	產生資訊公開和同意聲明字串時使用的 GVL 版本，比 Google 廣告放送技術目前已知的版本還要新。	不適用
7.3	某些目的、功能和/或供應商超出範圍 (不明)。	不適用
7.4	資訊公開和同意聲明字串的 tcf_policy_version 比最新版的 GVL 舊。	CMP 應刪除舊的資訊公開和同意聲明字串，並使用最新版的 GVL 重新取得同意聲明。
7.5	請求中包含 &gdpr=1，但請求網址中完全沒有 &gdpr_consent 參數。	不適用
7.6	發布商的國家/地區代碼無效，但已取得「目的 1」的同意聲明。	CMP 應修正資訊公開和同意聲明字串導入錯誤。
7.7	語言代碼無效。	CMP 應修正資訊公開和同意聲明字串導入錯誤。
7.8	資訊公開和同意聲明字串版本欄位不是 1 或 2。	如果系統偵測到無效的資訊公開和同意聲明字串，CMP 應重新取得同意聲明，修正這類字串的導入錯誤。 如果您在應用程式中使用 Google 同意聲明管理工具和 UMP SDK，請確認是否已正確導入 UMP SDK，且每次應用程式啟動時都會呼叫 requestConsentInfoUpdate。
7.9	額外同意聲明字串版本不是 1 或 2。	CMP 應將額外同意聲明字串版本設為 1 或 2。

額外同意聲明字串問題

發生這類問題時，Google 會將「額外同意聲明」(AC) 字串視為無效，且不會將資訊公開和同意聲明字串未包含的供應商列入考慮。

錯誤	說明	建議採取的行動
8.1	額外同意聲明字串未使用版本分隔符 (~)。	CMP 應使用「~」做為額外同意聲明字串的第二個字元，用來分隔版本號碼，以及已取得使用者同意的供應商名單。
8.2	額外同意聲明字串中的供應商名單格式不符合規定 (以「.」分隔的 int64 名單)	CMP 應修正額外同意聲明字串導入錯誤。