ブラウザコンソールでIAB GPP文字列をデバッグする：ステップバイステップのチュートリアル
GPPの問題が見つけにくい理由
米国の訪問者がデータの販売または共有をオプトアウトしたとき、その選択はページ上のすべての広告パートナーに届く必要があります。IAB Global Privacy Platform（GPP）では、その選択はコンパクトな文字列とセクションIDのリストとして伝わります。どちらかが誤っていても（欠落、古い値、誤ったセクションなど）、目に見える形で壊れるものはありません。広告は表示され、バナーも問題なく見えます。問題が表面化するのは後になってからで、パートナーがオプトアウトを無視したり、あなたのインベントリへの入札が減ったりといった形で現れます。
朗報は、ほぼすべてをブラウザコンソールから確認できることです。このチュートリアルでは、実際のページで実行する順に確認手順を説明します。
ステップ1：APIが存在し、準備できていることを確認する
GPP対応のCMPは、グローバルな__gpp関数を公開します。ページでDevToolsを開き、pingコマンドを実行します。
__gpp('ping', function (data) { console.log(data); });
返されるオブジェクトから、多くのことが一目でわかります。
- gppVersion — 現行の実装では1.1と表示されるはずです。
- cmpStatus — CMPが読み込まれたか、エラーになったか。
- cmpDisplayStatus — この訪問者に対してバナーが表示、非表示、無効のいずれか。
- signalStatus — CMPが同意状態を確定すると「ready」、まだ判断中は「not ready」。
- supportedAPIs — CMPが生成できるセクション。
- applicableSections — 現在この訪問者に適用されるセクションID。
- gppString — エンコードされた文字列そのもの。
__gppが未定義の場合、CMPのスタブがないか、読み込みが遅すぎます。スタブは、それを期待する広告スクリプトよりも前に配置されていなければなりません。そうでないと、それらのスクリプトはCMPを検出できず、待機するか、シグナルなしで進んでしまいます。
ステップ2：適用されるセクションを確認する
GPPの各プライバシーフレームワークには数値のセクションIDがあります。パブリッシャーが最もよく目にするのは、2（EU TCF v2）、5（カナダTCF）、7（US National、「usnat」）、そしてカリフォルニア、バージニア、コロラド、ユタ、コネチカットなど個別の州セクションを示す8以降です。米国の州の訪問者は、通常、applicableSectionsにEUセクションではなく、全国セクションまたは該当する州のセクションが表示されるはずです。
複数の場所からテストしてください。よくあるバグは、CMPがバナーのために地域を正しく検出していながら、それとは無関係にデフォルトのセクションを文字列に書き込んでしまうこと、あるいはその逆です。VPNやCMPのプレビューツールを使って、バナーの表示内容とapplicableSectionsの報告内容を比較してください。
ステップ3：セクションデータを読む
文字列を手作業でデコードするのではなく、CMPに解析済みのセクションを問い合わせます。
__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');
US Nationalセクションでは、オプトアウトのフィールドは単純な規則を使います。0は適用外、1はユーザーがオプトアウトした、2はユーザーがオプトアウトしていない、を意味します。まず次のフィールドに注目してください。
- SaleOptOutとSharingOptOut
- TargetedAdvertisingOptOut
- 対応するnoticeフィールド。各慣行について訪問者に通知が提示されたかどうかを記録します
次に、ページ上でオプトアウトを実行します。「Do Not Sell or Share」リンクをクリックするか、設定センターで設定を切り替えて、もう一度getSectionを実行します。オプトアウトのフィールドが2から1に切り替わるはずです。切り替わらない場合、UIとシグナルが同期していません。
ステップ4：Global Privacy Controlの経路をテストする
複数の州法は、事業者にGlobal Privacy Controlのシグナルをオプトアウトとして扱うことを求めています。GPCに対応したブラウザまたは拡張機能でGPCを有効にし、コンソールでnavigator.globalPrivacyControlがtrueを返すことを確認してから、新しいセッションでページを読み込みます。訪問者がバナーに触れなくても、該当するオプトアウトのフィールドがすでに1になっているはずです。セクションによっては、その選択がGPCシグナルに由来することを示すフィールドも含まれます。
ステップ5：スナップショットだけでなくイベントを監視する
広告スクリプトは、ページ読み込み時に文字列を一度読んでそのまま忘れてはいけません。パートナーが見ているものを確認するには、リスナーを登録します。
__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });
listenerRegistered、signalStatus、sectionChangeなどのイベントが観察できるはずです。訪問者が選択を変更したときは、更新された文字列を伴うsectionChangeイベントが続きます。ヘッダー入札のラッパーや広告サーバー連携が、signalStatusが「ready」になる前にしか文字列を読まない場合、空の値や古い値を送る可能性があります。
ステップ6：文字列を広告リクエストまで追跡する
最後に、Networkタブを開いて広告リクエストを絞り込みます。多くの広告エンドポイントはgppとgpp_sidパラメータ（文字列と適用されるセクションID）を受け付けます。次の点を確認してください。
- 米国の訪問者からのリクエストに両方のパラメータが含まれている。
- 文字列が、リクエスト時にpingが返した文字列と一致している。
- オプトアウト後のリクエストが、キャッシュされた文字列ではなく新しい文字列を運んでいる。
Prebid.jsを使っている場合は、そのconsent managementモジュールがGPP向けに設定されていることを確認し、ラッパーから出ていく入札リクエストと、最終的な広告サーバー呼び出しの両方を調べてください。
よくある失敗パターン
- スタブが広告タグより後に読み込まれる — パートナーにはCMPがまったく見えない。
- 地域に対して誤ったセクション — 米国のトラフィックにEUセクションが送られる、またはセクションがまったくない。
- UIとシグナルの不一致 — トグルは変わるが文字列は変わらない。
- GPCの無視 — ブラウザのシグナルがオプトアウトにならない。
- リクエスト内の古い文字列 — ラッパーが最初に見た値をキャッシュしている。
重要なポイント
- pingから始める。バージョン、ステータス、適用セクション、文字列から、ほとんどの状況がわかる。
- getSectionでオプトアウトのフィールドを読む。1はオプトアウト済み、2は未オプトアウト。
- オプトアウトリンクとGPCを別々にテストし、どちらもシグナルを変えることを確認する。
- イベントを監視し、広告リクエストが文字列を読む前に「ready」のシグナルを待つ。
- オプトアウトの前後で、実際のネットワークリクエスト内のgppとgpp_sidを確認する。