同意QAチェックリスト:リリース前にテストすべき項目

同意に専用のQAが必要な理由

同意は静かに壊れます。チームメンバーが追加した新しいスクリプト、変更されたタグのトリガー、名前が変わったCookieによって、訪問者が選択する前にトラッキングが始まったり、選択がまったく記録されなくなったりします。それでも、レポートがおかしく見えるまで誰も気づきません。リリースごとに実行する短く再現可能なチェックリストがあれば、こうした問題の大半は見つかります。

拡張機能を無効にしたクリーンなブラウザプロファイルまたはプライベートウィンドウでチェックを実行し、各項目の横に結果を記録してください。

A. 初回訪問

  1. バナーが表示される。最初のページ読み込みで、重要なコンテンツを覆うようなレイアウトのずれがないこと。
  2. 選択前に不要なタグが動作しない。ネットワークタブで、分析や広告のリクエストを確認します。
  3. 選択前に不要なCookieが設定されない。Applicationタブで確認します。
  4. 同意が必要な場所ではデフォルトの同意シグナルが拒否になっている。
  5. バナーが開いている間もページが使える。コンテンツが読めること。

B. 選択を行う

  1. すべて許可で正しいタグが有効になり、シグナルが即座に許可に変わる。
  2. すべて拒否が、許可と同じくらい見つけやすくクリックしやすく、不要なタグをオフのままにする。
  3. 個別の選択が機能する。分析だけをオンにすると、分析だけが有効になり、他は何も有効にならない。
  4. 選択が記憶される。再読み込み後も次のページでも、バナーが再表示されない。
  5. 選択が記録される。同意ログにタイムスタンプ付きで残る。

C. 選択を変更する

  1. 常設の入口(フッターのリンクやアイコン)から、どのページでも設定を再度開ける。
  2. 同意を撤回すると、該当するタグが止まり、可能な場合はそのCookieも削除される。
  3. 拒否から許可への変更で、手動の再読み込みなしにタグが開始する。

D. 地域と言語

  1. 地域ルールが想定どおりに動作する。VPNやテスト設定で、対象とする各地域の訪問者を再現します。
  2. 言語が訪問者の言語に従い、すべてのボタンラベルが翻訳され、生のキーが見えない。
  3. 右から左へ書く言語を提供している場合、レイアウトが正しく反転する。

E. 技術とプラットフォーム

  1. 広告シグナルが広告タグに届く。広告リクエストに、同意文字列または同等のシグナルが含まれていることを確認します。
  2. モバイルブラウザで、縦向きでも横向きでもバナーが正しく表示され、ボタンがタップしやすい大きさである。
  3. アクセシビリティの基本:キーボードのみで操作でき、フォーカスが見え、スクリーンリーダーがダイアログを読み上げる。
  4. パフォーマンス:バナーのスクリプトがレンダリングをブロックせず、読み込み後にメインコンテンツを押し下げない。

リリースを遅らせずに実行する方法

追加する価値のある特殊なケース

埋め込み動画プレーヤー、チャットウィジェット、地図、ソーシャルボタン、決済やログインのiframeなど、自社のプロパティ固有の要素についても項目を追加してください。これらは独自のトラッカーを読み込むことがよくあります。WebViewを使うモバイルアプリを提供している場合は、セクションAからCをアプリ内でも繰り返します。インシデントから何かを学ぶたびに、リストに1行を足せば、同じミスは戻ってきません。

チェックが失敗したときの対応

選択前にトラッキングするもの、または拒否を無視するものについては、同意チェックの失敗をリリースのブロッカーとして扱います。ボタンが少しずれているといった見た目の問題は、チケットを切ってリリースできます。優先順位は、選択前のトラッキング、無視された選択、失われた選択、見た目の順です。

FlexyConsentの位置づけ

FlexyConsentのバナーは57言語で利用でき、Google Consent Mode v2、IAB TCF 2.4、IAB GPP v1.1に対応しているため、上記の技術的な項目の多くをカバーします。それでもチェックリストは必要です。ページ上で実際に何が動作するかは、自社のタグ、テーマ、スクリプトによって決まるからです。

重要なポイント

← ブログ すべて読む →