同意しない人の行動は測れる？｜同意モードの仕組み

「同意を求める表示を入れたら、アクセスの数字が2割落ちた」「訪問が減ったのか、測れなくなっただけなのか分からない」——同意の取得を始めた直後に必ず出る混乱です。数字の落ち込みは、訪問の減少ではありません。同意しない人の行動が記録に残らなくなったことの表れです。この記事では、同意の状態をタグに伝える仕組みで何が測れて何が測れないのかを整理します。

同意しない人はどこまで見えるか

結論から言うと、同意しない人の行動は個人単位では追えません。ただし、まったく見えないわけでもありません。

同意を得られない場合、識別のための記録を残せません。同じ人が再訪しても、別の人として扱われます。

それでも、同意の状態と行動の有無を伝える信号は送られる仕組みがあります。Cookieを使わない形の信号です。

この信号があるため、成果の総数を推定して補う余地が生まれます。個人を追えなくても、全体の傾向は掴めます。

逆に言えば、個人の経路をたどる分析は難しくなります。同じ人の複数回の訪問をつなげられません。

この違いを理解しておくと、報告での説明が変わります。数字が減ったのではなく、見える範囲が変わったと伝えられます。

以下では、仕組みの中身を順に見ていきます。

仕組みを知らないまま数字だけを見ていると、原因の切り分けができません。

同意モードとは何をする仕組みか

この仕組みは、利用者が同意したかどうかの状態をタグに伝えます。その状態に応じてタグの動作が変わります。

同意がある場合は、通常どおり記録します。ない場合は、記録の一部を行わない動作に切り替わります。

つまり、同意の有無で計測の挙動を切り替える仕組みです。同意を得る仕組みそのものではありません。

同意を得る表示は、別の仕組みで用意します。表示を出す仕組みと、動作を切り替える仕組みは別物です。

2つの仕組みが連携して動くという構造を理解しておくと、実装の話が分かりやすくなります。

公式の説明では、地域別に動作を変える機能や、保存済みの情報を消去する機能も用意されているとされています。

拒否された場合にURL経由で情報を受け渡す機能もあるとされています。用途に応じて選べます。

まずは基本の切り替えを理解するところから始めます。

4つの区分で伝える

伝える同意の状態は、4つの区分に分かれています。用途ごとに別々に扱えます。

1つ目は広告に関連する情報の保存、2つ目は分析に関連する情報の保存です。

3つ目は、広告の目的で利用者のデータを送ることへの同意です。4つ目は、個人に合わせた広告への同意です。

この4つを別々に扱えるため、利用者が用途ごとに選べる設計にできます。分析だけ同意する、という形です。

実装のときは、この4つすべてを伝える必要があります。一部だけ伝えると、意図した動作になりません。

同意がない場合に送られるもの

拒否された場合でも、何も送られないわけではありません。送られる内容は限定されています。

公式の説明では、Cookieを使用しない信号をサーバーに送り、同意の状態と利用者の行動を伝えるとされています。

送られるのは、時刻、利用者の環境の情報、参照元のURLなどです。個人が特定されない集計の情報も含まれます。

識別子があるかどうかや、真偽の値といった形の情報です。誰であるかは分かりません。

この信号があることで、成果の発生の有無は把握できます。個人単位の追跡はできません。

つまり、量は掴めるが個人は追えないという状態です。分析の設計をこの前提に合わせます。

経路の分析や、同じ人の再訪の分析は精度が落ちます。総数の把握を主な目的にします。

報告の指標も、この前提に合わせて選びます。

送られない情報を把握する

送られないのは、個人を識別するための情報です。同じ人を再び認識する手がかりが残りません。

そのため、初回の訪問か再訪かの区別ができません。この区別を使った分析は成立しません。

複数の接点をたどる分析も難しくなります。広告から入って後日に成果に至った、という経路が追えません。

同じ人が複数の端末を使っている場合の統合も、より難しくなります。

これらの限界を先に把握しておくと、無理な分析に時間を使わずに済みます。

実装には段階がある

実装の方法には幅があります。どこまで細かく制御するかで段階が分かれます。

最も簡単なのは、同意が得られるまでタグを読み込まない形です。実装は容易ですが、拒否した人の情報は何も残りません。

タグは読み込むが、同意の状態を伝えて動作を切り替える形もあります。この形なら、拒否時の信号が送られます。

後者のほうが得られる情報は多くなります。ただし実装は複雑になります。

どちらを選ぶかは、必要な精度と実装できる体制で決めます。無理な実装は事故につながります。

段階を上げる余地があるため、まず簡単な形で始めて後から変える判断もできます。

変えるときは、数字の見え方が変わります。切り替えの日付を記録します。

実装の方針は、情報システムの担当者と一緒に決めます。

どちらを選ぶかの判断

判断の軸は、広告の成果を正確に測りたいかどうかです。測りたいなら、状態を伝える形が必要になります。

広告を使っていない、または成果の件数が少なくて精度の議論に意味がない場合は、簡単な形で足ります。

実装を担う体制がない場合も、簡単な形から始めます。中途半端な実装は、かえって数字を濁します。

外部に委託する場合は、どちらの形で実装するかを仕様として明記します。伝えていないと簡単な形になります。

決めた方針は記録に残します。後から数字の見え方を検証するときの前提になります。

欠けたデータを推定して補う

同意が得られない分のデータを、推定によって補う機能があるとされています。総数の把握に役立ちます。

拒否した人から送られる信号をもとに、成果の数を推定する形です。個人を復元するものではありません。

ただし、この機能には前提があります。公式は、一定のデータの収集の基準を満たすことが求められると述べています。

つまり、アクセスや成果の件数が少ないサイトでは、補完が働かない可能性があります。基準に届かないためです。

BtoBのサイトは、件数が少ないことが多くあります。補完に期待しすぎないほうが安全です。

補完が働いているかは、画面上の表示で分かる場合があります。推定を含む数字かどうかの注記です。

注記の有無を確認してから、数字の解釈を決めます。

補完がない場合は、実際より少ない数字として扱います。

補うための前提を確認する

確認したいのは、実装が正しく行われているかと、件数が基準に届いているかです。

実装が誤っていると、拒否時の信号が送られません。補完の材料がない状態です。

件数の基準は公開されていない部分もあります。断定を避け、注記の有無で判断します。

件数が少ないなら、補完に頼らない指標を選びます。手前の行動を数えるといった工夫です。

いずれにしても、数字の性質を報告のときに説明できる状態にします。

日本での必要性を整理する

この仕組みが必要かという問いには、2つの側面があります。法令の側面と機能の側面です。

法令の側面では、地域によって求められる水準が違います。国内の企業でも、海外からの訪問がある場合は考慮が要ります。

機能の側面では、広告の一部の機能を使うために対応が求められる場合があります。使いたい機能の要件を確認します。

この2つは別の話です。法令上は不要でも、機能を使うために必要という状況が起こります。

判断は、対象となる訪問者の所在と、使いたい機能から決めます。どちらも自社の状況に依存します。

不明な点は、法務や外部の専門家に確認します。この記事の範囲では断定できません。

確認した結果は記録に残します。方針が変わったときの根拠になります。

方針は年に一度見直します。規制も機能の要件も変わります。

規制と機能の2つの側面

規制の側は、利用者の権利を守るための義務です。守らないと制裁の対象になり得ます。

機能の側は、使うための条件です。満たさないと使えないという性質のものです。

混同すると、必要な対応が過剰にも過少にもなります。分けて整理するのが要点です。

整理した内容を1枚にまとめ、関係者で共有します。判断の根拠が揃います。

外部に説明する必要が出た場合も、この1枚があれば足ります。

側面	問われること	確認先
法令	利用者の権利を守れているか	法務や外部の専門家
機能	使いたい機能の要件を満たすか	提供元の公式の説明
実装	同意の状態が正しく伝わるか	情報システムや制作の担当
数字	推定を含むかどうか	解析の画面の注記

同意を管理する仕組みが必要

同意の状態を伝えるには、同意を得て記録する仕組みが別に必要です。表示と記録の両方を担います。

この仕組みは、専用のサービスを使うのが一般的です。自作すると、記録の保存や地域別の動作で困ります。

選ぶときは、伝える4つの区分に対応しているかを確認します。対応していないと、意図した動作になりません。

同意の記録を保存できるかも重要です。求められたときに示せる状態が必要になります。

表示の文言を自社で調整できるかも見ます。既定の文言が実態と合わないことがあります。

費用は規模によって変わります。訪問の数で課金される形が多くあります。

導入の前に、実装を担う担当者と一緒に確認します。連携の作業が必要になります。

選定の理由は記録に残します。乗り換えを検討するときの材料になります。

同意の記録を残す

誰がいつ何に同意したかを記録します。求められたときに示せる状態にしておきます。

記録の保存の期間も決めます。長すぎると管理の負担が増えます。

同意を撤回する手段も用意します。一度同意したら変えられない設計は避けます。

撤回された場合の動作も確認します。保存済みの情報を消去する機能が使える場合があります。

これらは仕組みの側の機能に依存します。選定の段階で確認します。

タグ管理の道具での実装

実装は、タグ管理の道具を経由するのが一般的です。個別のタグを直接触らずに済みます。

道具の側に、同意の状態を扱う機能が用意されています。タグごとに、どの同意が必要かを設定できます。

設定すると、同意がない場合にそのタグが動かない状態を作れます。個別の実装より事故が少なくなります。

同意を管理する仕組みとの連携も、道具の側で行います。多くのサービスは連携の手順を公開しています。

設定の順番を守ることが重要です。同意の状態が伝わる前にタグが動くと、意図した動作になりません。

読み込みの順序を確認します。ここが最も間違いやすい部分です。

実装が終わったら、必ず動作を確認します。設定しただけでは動いていないことがあります。

確認の方法は次の節で整理します。

実装の順番を守る

同意の状態を伝える記述は、他のタグより先に読み込まれる必要があります。順番が逆だと機能しません。

既定の状態も設定します。同意がまだ得られていない状態を、拒否として扱う形です。

既定を同意として設定すると、意図せず記録してしまう恐れがあります。慎重に確認します。

設定の内容は記録に残します。実装を引き継ぐときの資料になります。

順番の確認は、実装した担当者以外の目でも見ます。1人だと見落とします。

実装の確認方法

実装が正しく動いているかは、確認できます。確認せずに運用すると、数字が誤ったまま蓄積します。

最も基本的な確認は、同意する場合としない場合の両方で動作を見ることです。

拒否した状態で、記録が行われていないことを確かめます。行われていたら実装に問題があります。

同時に、拒否時の信号が送られているかも見ます。開発者向けの画面で通信の内容を確認できます。

同意した場合に、通常どおり記録されることも確かめます。片方だけの確認では不十分です。

地域別の動作を設定している場合は、その動作も確認します。設定と実際がずれることがあります。

確認の結果は記録に残します。実装を変えたときに比べる材料になります。

確認は実装の直後と、サイトを大きく変えたときに行います。

確認する項目を一覧にする

確認の項目を一覧にしておくと、抜けが減ります。項目は5つ程度で足ります。

同意前の状態、同意した場合、拒否した場合、撤回した場合、地域別の動作の5つです。

それぞれで期待される動作を書いておきます。書いていないと、何を見ればよいか分かりません。

一覧は実装の担当者と共有します。確認の作業を依頼するときにそのまま渡せます。

記録した結果は日付とともに残します。次回の確認で比べられます。

同意率を上げる設計

測れる範囲を広げる最も直接的な方法は、同意する人を増やすことです。表示の設計で変わります。

文言が分かりにくいと、拒否か離脱を選ばれます。何のために使うのかを簡潔に伝えます。

選択肢の見せ方も影響します。同意と拒否が同じ形で並んでいるほうが、利用者の判断を歪めません。

用途ごとに選べる形にすると、一部だけ同意する人が増える可能性があります。全部か何もなしかより柔軟です。

表示の位置や大きさも判断に影響します。閲覧を妨げすぎると、内容を読む前に離脱されます。

ただし、同意を誘導しすぎる設計は避けます。規制の観点でも問題になり得ます。

設計を変えたら、同意率の変化を測ります。測らないと効果が分かりません。

測るには、同意した数と表示した数を記録する必要があります。仕組みの側の機能を確認します。

バナーの文言を短くする

長い説明は読まれません。要点を1文か2文にまとめます。

伝えるのは、何のために使うのかと、選べることです。詳しい内容は別のページに置きます。

専門用語を並べると、警戒されて拒否が増えます。日常の言葉で書きます。

詳しいページへのリンクは必ず置きます。知りたい人が確認できる状態にします。

文言は法務にも確認します。表現によって意味が変わる部分があります。

数字が変わることを社内に伝える

実装すると、数字が変わります。事前に伝えていないと、施策の失敗と誤解されます。

伝えるのは、変わる理由と、いつから変わるかです。切り替えの日付を明示します。

前後の数字を単純に比べられないことも伝えます。境目として扱う必要があります。

報告の資料にも、切り替えの日付を注記します。後から見た人が誤解しません。

経営に近い相手には、なぜ必要なのかも説明します。数字が減るだけの施策に見えると理解を得られません。

説明の材料として、法令と機能の2つの側面を整理した1枚を使います。

併せて、測れる範囲が変わることも伝えます。個人の経路の分析が難しくなる点です。

先に伝えておけば、後の議論が短く済みます。

導入の手順

実際の進め方を整理します。確認を挟みながら進めます。

この5段階で導入は完了します。時間がかかるのは1段目と5段目です。

急いで4段目まで進めると、数字が誤ったまま蓄積します。確認を終えてから運用に入ります。

測れる範囲の限界を理解する

この仕組みを入れても、以前と同じ精度には戻りません。限界を理解して指標を選びます。

個人単位の追跡が難しくなるため、経路の分析は精度が落ちます。総数の把握を主軸にします。

複数回の訪問をつなげる分析も、以前より不確かになります。検討の期間が長いBtoBでは影響が出ます。

代わりに使えるのが、自社で持つデータです。問い合わせのフォームで流入の経路を尋ねる方法があります。

営業の記録と突き合わせる方法も有効です。解析の数字だけに頼らない設計にします。

測れないものを測ろうとするより、測れるものを増やす発想に切り替えます。

この切り替えは、報告の指標の見直しにもつながります。

限界の伝え方

社内に伝えるときは、できないことを先に示します。期待を整えるほうが後の議論が楽になります。

そのうえで、代わりに何が見えるかを示します。総数の傾向と、自社で持つデータです。

数字の精度が落ちた分は、別の方法で補う計画も示します。手を打っている姿を見せます。

補う方法として、フォームでの申告や営業の記録が使えます。すぐに始められる手段です。

伝える内容を1枚にまとめ、報告の資料に添えます。毎回の説明が要らなくなります。

やりがちな失敗

実装でつまずく形は、ある程度共通しています。

• 読み込みの順番を確認しない：同意の状態が伝わる前にタグが動き、意図した動作にならない
• 既定を同意として設定する：同意を得ていない状態で記録してしまう恐れがある
• 4つの区分の一部だけを伝える：機能の要件を満たさず、使えない機能が残る
• 実装後に動作を確認しない：数字が誤ったまま蓄積し、後から遡って直せない
• 数字が変わることを社内に伝えない：施策の失敗と誤解され、余計な調査が発生する

いずれも、実装の前後に確認すれば避けられます。特に順番と既定の設定は事故につながります。

もうひとつ多いのが、補完の機能に期待しすぎることです。件数が少ないと働かない可能性があります。

画面上の注記を確認し、推定を含むかを判断します。含まないなら、実際より少ない数字として扱います。

運用の決めごと

運用を続ける前提で、決めごとを用意します。項目は少なく保ちます。

• 同意の状態を伝える記述を最初に読み込み、既定は拒否として設定する
• 同意前、同意、拒否、撤回の各状態で動作を確認し、結果を日付とともに記録する
• 切り替えの日付を報告の資料に注記し、前後の数字を単純に比べない
• 法令と機能の2つの側面を整理した1枚を作り、年に一度見直す

この4項目を計測の手順書に入れます。実装を変えるたびに読み返せます。

見直しの時期

規制も機能の要件も変わります。年に一度は方針を見直します。

サイトを大きく変えたときは、その場で動作を確認します。実装が外れる事故が起きます。

同意を管理する仕組みの側の更新も確認します。連携の仕様が変わることがあります。

見直した内容は記録に残します。判断の背景が次の担当者に伝わります。

見直しの予定は繰り返しで入れます。思い出す運用では止まります。

まとめ

同意しない人の行動は、個人単位では追えませんが総数の把握には手立てがあります。要点は、同意の状態をタグに伝える実装を行い、既定を拒否として読み込みの順番を守ることです。拒否された場合もCookieを使わない信号が送られ、成果の総数を推定する余地が生まれる。ただし補完には一定のデータの収集の基準があり、件数が少ないサイトでは働かない可能性がある。測れない部分は、フォームでの申告や営業の記録といった自社のデータで補う。まずは自社のサイトで、拒否した状態で記録が行われていないかを確かめてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。