診断を置いたらCookie同意バナーは要るのか — 保存しているものから逆算して確かめる

診断コンテンツいくつかの質問に答えると結果が返る形式のコンテンツ。おすすめ商品の提案やタイプ分けなど、読者が自分に当てはめた結果を持ち帰れる。を1本置くだけで、サイトのプライバシー対応をやり直すことになるのか。同意バナーの設置、プライバシーポリシーの追記、社内の法務確認。診断の中身を決めるより手前の作業のほうが重く見えて、そこで止まる。

ただ、この問いに一般論で答えられる範囲はかなり狭いです。同意が要るかどうかは「診断を置いたから」ではなく、その診断が訪問者のブラウザとサーバーに何を残すかで変わるからです。順番としては、条文を読みにいく前に、使う道具が何を保存しているかを一覧にするほうが早い。

この記事で出すのは、診断シミュレーションProが何を置いて何を置かないかを、保存項目の粒度まで下ろしたものです。適用可否の判断そのものは書けません。判断するための材料をそろえるところまで。

Cookieを1つも発行しない診断もある

同意バナーが話題になるのは、多くの計測ツールが訪問者のブラウザにCookieサイトが閲覧者のブラウザに保存する小さなデータ。ログイン状態の維持や、同じ人の再訪問の識別に使われる。を置き、それを継続的な識別に使うからです。診断ツールでも、外部SaaSの埋め込み型なら埋め込み先のドメインからCookieが飛んでくることがあります。

一方で、Cookieを一切使わない作りも成立します。診断シミュレーションProの計測がそれで、プラグインはCookieを1つも発行しません。手元のコードを setcookie と document.cookie で検索しても、該当は0件でした。

代わりにブラウザへ置くのは、localStorageのキーが1つだけ。mqs_session_key という名前で、中身は mqs_ に続くランダムな16文字です。同じブラウザで次に来たときはこの文字列が使い回されますが、そこから人物にたどり着く手段はこちら側にありません。localStorageが使えない設定のブラウザでは、そのページ限りの一時的なキーが作られて終わります。

Cookieでないから同意管理の対象外、と言い切れるかは別の話です。localStorageも管理対象に含める考え方はありますし、導入している同意管理ツールがどう扱うかにもよります。ここは自サイトの方針に合わせて決める場所。

サーバーに残る1行に、名前もIPも入っていない

ブラウザ側の次は、サイトのDBに何が積まれるかです。

計測用のテーブルには、イベントが1行ずつ入ります。1行が持つのは、セッションキー・設問セットのID・設問のID・選択肢のID・何問目か・表示した結果のID・設置ページのID・ページのパス・リファラのパス・日時。列はここで終わりです。ページもリファラも記録するのはパスの部分だけなので、リファラのドメインも、URLに付いてくるクエリ文字列も残りません。

入っていないものを並べたほうが早いかもしれません。氏名、メールアドレス、電話番号、IPアドレス、ユーザーエージェント。どれも列そのものが存在しないので、保存のしようがない。IPアドレスだけは1分あたりの送信回数を数えるのに使いますが、持ち方はハッシュ化した値を1分で消える一時データのキーにするところまで。既定で1分120回を超えた分を捨てる、それだけの用途です。ログの側には落ちません。

送り先も自分のサイトです。集計は外部の解析サービスを経由せず、そのWordPressのDBに直接溜まります。 フロント側のスクリプトから外部ドメインへ通信する処理は入っていません。第三者にデータが渡らないという点は、保存項目と同じくらいポリシーに書きやすい事実です。

個人を追わない計測でどこまで改善が回るかは個人情報を保存しないまま診断の効果を測るにまとめました。

重くなるのは、たいてい結果の中に置いたフォームのほう

ここまでは診断の計測部分の話です。実務で扱いが重くなるのは、むしろ結果コンテンツの中身のほうだったりします。

結果の中身はブロックエディタで自由に組めるので、Contact Form 7 のフォームもそこに入ります。診断から問い合わせまで1ページで完結させたいなら自然な組み方ですが、そこに氏名とメールアドレスが入力された瞬間、扱いは通常のお問い合わせフォームと同じになる。診断だから軽い、ということはありません。hidden項目に結果名を入れているなら、その人がどの結果になったかも送信内容として届きます。この設計は診断結果から問い合わせにつなげるで具体的に書きました。

reCAPTCHAGoogleが提供する、フォームの送信者が人間か自動プログラムかを判定する仕組み。スパム対策としてContact Form 7などと組み合わせて使う。やTurnstileを掛けているなら、そこで何が送られるかは外部サービス側の取り決めです。診断プラグイン側がやっているのは、AJAXで差し込まれたウィジェットを描き直すところまでで、データの扱いには入っていきません。結果コンテンツに動画の埋め込みや広告タグを置いたときも同じ構図。ブロックエディタで自由に作れるということは、置いたものの扱いもこちら側に付いてくるということでもある。

線を引くとこうなります。診断の計測はCookieなし・個人情報なし。結果の中に何を置いたかは、サイト全体のプライバシー対応と同じ土俵。

ポリシーに書き足す材料は、設定画面でそろう

プライバシーポリシーに追記するとして、必要になるのはだいたい4つです。何を集めるか、何のために使うか、どこに置くか、どれだけ持つか。

前の3つはここまでで出ました。残る保持期間は設定画面の値をそのまま書けます。生の計測ログの保持は1〜365日の範囲で指定でき、既定は90日。指定を過ぎた行は、日を跨いだcronが拾って消していきます。設問セット単位で計測データをまとめて消すボタンも管理画面にあります。

どの日数を書くかは、集めたい数字ではなく運用の期間から決まります。数か月で畳むキャンペーン診断に365日と書いてあれば、持ちすぎではないかと聞かれる。ポリシーの文面と設定値は別々に決めるとずれるので、同じ日に決めてしまうのが楽です。

なお削除されるのは生のログのほうで、日次の集計値は残ります。「何日分の生ログを持つか」と「何日分のグラフが見られるか」は別、と押さえておくとポリシーの文面もぶれません。

断定できないところは、断定しないまま持っていく

ここまでは事実です。ここから先は、こちらでは決められません。

個人情報保護法やGDPRがそのサイトにどう適用されるかは、事業者の所在、想定する読者、扱う情報の中身、そしてサイトに載っている他のもので変わります。診断プラグイン1本の仕様で決まる話ではない。「このプラグインを使えば同意バナーは不要です」と書ければ楽ですが、それは製品側が言っていいことではないと考えています。

代わりにできるのは、確認の手間を減らすことです。「診断を入れていいですか」だけでは、法務も専門家も判断のしようがありません。まず「何を保存するのか」を聞き返すところから始まって、そこで一往復増える。最初から保存項目の一覧を添えれば、その往復は省けます。

受託でクライアントのサイトに組み込むなら、この一覧は見積もりの段階で渡しておくほうが安全です。公開直前に法務レビューが入って設計から戻る——その芽を先に摘めます。制作物として組み込むときの段取りは制作会社が受託案件で診断を組み込むときの作り方にまとめてあります。

同意バナーの要否から決めようとすると、話が動きません。何を保存していて何を保存していないかを先に確定させれば、確認すべき範囲はかなり狭くなります。ここに出した保存項目のもとになっている計測の作りは、診断シミュレーションProの製品ページで確かめられます。