歐洲互動廣告局 (IAB Europe) 與互動廣告局科技實驗室 (IAB Tech Lab) 和共同成員公司攜手開發的「資訊公開和同意聲明架構第 2.0 版」已拍板定案,Google 現已全面支援「資訊公開和同意聲明架構第 2.0 版」。
為了讓發布商有時間因應歐洲互動廣告局 (IAB Europe)「資訊公開和同意聲明架構第 2.0 版」推出後可能遇到的錯誤和設定不當問題,我們會將偵測到的錯誤製作成報表,並提供 150 天寬限期讓發布商解決相關錯誤。
本文將說明如何解決「資訊公開和同意聲明架構第 2.0 版」的導入錯誤,內容包括:
新版規範
異動項目
- 針對資訊公開和同意聲明架構規定,每 13 個月必須重新取得同意聲明設定提醒:依據 IAB 資訊公開和同意聲明架構政策,您每 13 個月都必須至少提醒使用者一次,以確認對方的同意聲明選項。如果同意聲明決定超過 13 個月,資訊公開和同意聲明字串就會失效,Google 也不會向該使用者放送廣告。建議您與同意聲明管理平台合作,在 13 個月上限期滿之前提醒使用者確認同意聲明選項。
- 錯誤類型 3.2 已經排除。最近 13 個月內更新的資訊公開和同意聲明 (TC) 字串仍維持有效。
常見錯誤的修正方式
請採行下列做法來解決 Ad Manager、AdSense 和 AdMob 的一些常見錯誤:
考慮向看到無法營利的資訊公開和同意聲明字串的使用者重新徵求同意聲明(錯誤 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 個月。
AddEventHandler
的呼叫(錯誤 2.1a、2.1b、2.2a、2.2b 和 2.2c)
相關錯誤
錯誤 2.1a;此規範可能也適用於錯誤 2.1b、2.2a 2.2b 和 2.2c。
新版規範
雖然現在已經沒有逾時相關規定,但我們仍建議 CMP 仔細檢查導入方式,確保能夠立即將呼叫傳回給 AddEventListener getTCData
。
如果 CMP 沒有回應,請求可能就無法營利。
原因
Google 遵循 IAB 規範,要求 CMP 立即回應 AddEventListener
函式。如果 CMP 沒有立刻回應,請求可能就無法營利。
此外,CMP 回應是事件鏈的一部分,會影響送出廣告請求的速度。縮短網頁載入與廣告請求的間隔時間,有助於減少發布商錯失的廣告曝光次數。
IAB 規範
適用的 IAB 規範:IAB AddEventListener 規格 (存放在 GitHub)
loading
,且 CMP 中的資訊公開和同意聲明資料不完整,仍然必須立即呼叫 AddEventListener
回呼,讓呼叫指令碼存取其已登錄的 listenerId
。此外,每次更改資訊公開和同意聲明字串時,除非已經使用 RemoveEventListener
移除回呼,否則都必須呼叫回呼。錯誤報表
如果系統偵測到發布商的一或多個網站或應用程式有資訊公開和同意聲明字串相關問題,就會透過產品使用者介面通知發布商。發布商可以在帳戶的「歐盟使用者同意聲明」頁面中,點選 [下載資訊公開和同意聲明架構錯誤報表] 來取得報表,當中會詳細列出最近 7 天偵測到的錯誤。
- Ad Manager:按一下 [管理]
[歐盟使用者同意聲明]。
- AdMob 和 AdSense:按一下 [封鎖控制項]
[歐盟使用者同意聲明]。
這份報表會針對每項偵測到的錯誤列出下列資訊:
- 網域/MobileAppID:網站或行動應用程式的設定有誤。
- 廣告單元路徑:與錯誤相關聯的廣告單元。
- 錯誤代碼:錯誤的對應代碼。
- 錯誤數:在過去一週觀察到發生錯誤的查詢數量。
- 上次偵測到錯誤的日期:最近一次偵測到錯誤的日期。
發布商可使用報表中列出的錯誤代碼,在下方疑難排解表格中找到建議採取的動作並修正錯誤。
疑難排解
為協助發布商修正設定不當的 IAB 資訊公開和同意聲明架構第 2.0 版整合問題,我們在下方表格中彙整了常見的資訊公開和同意聲明字串錯誤類型,以及對應的疑難排解建議做法。
請參閱表格以瞭解廣告請求層級發生的問題,以及對應的系統行為。
有限同意聲明情境
情境 1.1 和 1.3 一律會捨棄廣告請求且不再供應廣告;情境 1.2 則不會。若某項請求有多個錯誤,上述三種情境的優先順序一律高於設定不當。
情境 | 說明 | 建議採取的行動 |
---|---|---|
1.1 | 不論目的為徵求同意聲明或顧及正當利益,皆不允許 Google 做為供應商。系統會捨棄廣告請求且不再供應廣告。 | 確認使用者是否刻意拒絕 Google 做為供應商、CMP 是否導入錯誤,或者是否有任何發布商限制。 |
1.2 | 未針對歐洲經濟區國家/地區和英國取得「目的 1」的同意聲明。 |
確認使用者是否刻意不允許「目的 1」,或這是因為同意聲明管理平台導入錯誤造成的。 德國發布商若未向使用者要求同意聲明,請務必正確設定「
PublisherCC 」和「PurposeOneTreatment 」欄位。 |
1.3 | 已取得「目的 1」的同意聲明,但缺乏基本廣告的法律依據。系統會捨棄廣告請求且不再供應廣告。 |
確認使用者是否刻意拒絕基於其他用途的正當利益,或這是因為 CMP 導入錯誤造成的。 |
設定不當
若有設定不當,系統就不會再按廣告請求供應廣告。
錯誤 | 說明 | 建議採取的行動 |
---|---|---|
2.1a | 由於同意聲明管理平台狀態為 stub 、loading 或 error ,因此標記或 SDK 未收到資訊公開和同意聲明字串。 |
若您以手動叫用函式的方式請求廣告,請確認 getTCData TCData.eventStatus 的回應為 若您不是以手動叫用函式的方式請求廣告,請向您的 CMP 確認是否已導入 |
2.1b |
同時符合以下兩項條件:
|
請洽詢您的 CMP,確認對方已根據 IAB 資訊公開和同意聲明架構的技術規格正確導入 API。 |
2.2a |
資訊公開和同意聲明字串未採用 Base64 編碼,因此無法剖析。 例如: |
同意聲明管理平台 (或發布商) 在 gdpr_consent= 參數中只能傳送採用 Base64 編碼的資料。 |
2.2b |
由於解碼錯誤,因此無法剖析資訊公開和同意聲明字串。 例如:包含的位元數不正確 |
同意聲明管理平台應修正資訊公開和同意聲明字串導入錯誤。 |
2.2c |
發生資料錯誤,因此無法剖析資訊公開和同意聲明字串。 例如:時間戳記不正確、供應商 ID 過大 |
同意聲明管理平台應修正資訊公開和同意聲明字串導入錯誤。 |
資訊公開和同意聲明字串問題
當發生與廣告請求有關的資訊公開和同意聲明字串問題時,系統就會捨棄廣告請求且不再供應廣告。
錯誤 | 說明 | 建議採取的行動 |
---|---|---|
3.1 | 同意聲明管理平台 ID 無效。 |
確認同意聲明管理平台已通過 IAB 驗證,且已在資訊公開和同意聲明字串中正確設定其 ID。 如果資訊公開和同意聲明字串產生時,同意聲明管理平台的資格有效,但之後遭 IAB 刪除,則必須透過有效的同意聲明管理平台重新取得同意聲明。 |
3.2 | 已不再使用。 | 先前的意義:資訊公開和同意聲明字串的建立日期距今已超過 13 個月。同意聲明管理平台應刪除舊的資訊公開和同意聲明字串並重新取得同意聲明。 |
3.3 | 資訊公開和同意聲明字串最近一次的更新日期距今已超過 13 個月。 | 同意聲明管理平台應刪除舊的資訊公開和同意聲明字串並重新取得同意聲明。 |
必須重新取得同意聲明
必須重新取得使用者的同意聲明。如果您先前已取得使用者同意聲明且距今已超過 13 個月 (或在 Google 加入 GVL 之前取得),您必須重新取得使用者同意聲明,否則系統就會捨棄廣告請求且不再供應廣告。
錯誤 | 說明 | 建議做法 |
---|---|---|
4.1 | 產生資訊公開和同意聲明字串時使用的全球供應商名單 (簡稱 GVL) 版本中不包含 Google。 | 使用包含 Google 的新版 GVL 重新取得同意聲明。 |
全域範圍和架構外範圍
與全域範圍和架構外範圍 (Ad Manager、AdMob、AdSense) 有關的問題。如果資訊公開和同意聲明字串仍指出「架構外」或「全域範圍」,系統就會停止放送廣告。
錯誤 | 說明 | 建議做法 |
---|---|---|
5.1 | 資訊公開和同意聲明字串允許架構外的同意聲明。 | 要求您的同意聲明管理平台從資訊公開和同意聲明字串中移除架構外信號。 |
5.2 | 全域範圍的資訊公開和同意聲明字串。 | 要求您的同意聲明管理平台改用特定服務專用的資訊公開和同意聲明字串。 |
廣告會繼續放送
系統會依據目前的設定繼續放送個人化和非個人化廣告,營利不會受到影響。
錯誤 | 說明 | 建議做法 |
---|---|---|
6.1 | 資訊公開和同意聲明字串版本為 1 或 1.1 (第 1.0 版字串)。 |
CMP 應傳送資訊公開和同意聲明架構第 2.0 版字串。 |
Google 將處理問題
若發生這類問題,Google 會視情況處置,並繼續進行正常的資訊公開和同意聲明架構處理程序。
錯誤 | 說明 | 建議做法 |
---|---|---|
7.1 | gdprApplies 尚未定義或設定為無效/無法解讀的值,但存在有效的資訊公開和同意聲明字串。 |
不適用 |
7.2 | 產生資訊公開和同意聲明字串時使用的全球供應商名單版本,比 Google 的廣告放送技術目前已知的版本還要新。 | 不適用 |
7.3 | 某些目的、功能和/或供應商超出範圍 (不明)。 | 不適用 |
7.4 | 資訊公開和同意聲明字串的 tcf_policy_version 比最新版的全球供應商名單舊。 |
同意聲明管理平台應刪除舊的資訊公開和同意聲明字串,並使用最新版的全球供應商名單來重新取得同意聲明。 |
7.5 |
請求中包含 |
不適用 |
7.6 | 發布商的國家/地區代碼無效,但已取得「目的 1」的同意聲明。 | 同意聲明管理平台應修正資訊公開和同意聲明字串導入錯誤。 |
7.7 | 語言代碼無效。 | 系統只會放送受限制的廣告。同意聲明管理平台應修正資訊公開和同意聲明字串導入錯誤。 |
7.8 | 資訊公開和同意聲明字串版本欄位不是 1 或 2 。 |
系統只會放送受限制的廣告。同意聲明管理平台應修正資訊公開和同意聲明字串導入錯誤。 |
7.9 | 額外同意聲明字串本不是 1 。 |
同意聲明管理平台應將額外同意聲明字串版本設為 1 。 |
額外同意聲明字串問題
發生這類問題時,Google 會將「額外同意聲明」(AC) 字串視為無效,且不會將資訊公開和同意聲明字串未包含的其他供應商列入考慮。
錯誤 | 說明 | 建議做法 |
---|---|---|
8.1 | 額外同意聲明字串未使用版本分隔符 (~ )。 |
同意聲明管理平台應使用「~ 」做為額外同意聲明字串的第二個字元,用來分隔版本號碼,以及已取得使用者同意的供應商名單。 |
8.2 | 額外同意聲明字串中有供應商名單未遵循預期格式 (以「.」做為分隔符的 int64 名單) | CMP 應修正額外同意聲明字串導入錯誤。 |