GDPRに備える広告tagは同意画面を作る前に送信先と広告の目的を棚卸しする

GDPRに向けて広告tagを見直すときは、同意を求める画面だけを急いで作らない。先に、どのpageへどのtagが入り、どの事業者へ何の情報を送っているかを確かめる。次に、その広告や計測を続ける理由と、利用者へ説明する内容を決める。画面の文言と実際の送信先が食い違えば、同意を求めても運用できない。

Googleは3月22日、広告サービスを利用するpublisherとadvertiserに関するGDPR対応の方針を案内した。Googleは、既存のEU法で必要な場合に利用者のconsentを得ることを求めており、GDPRの適用に合わせてEU consent policyを更新し、publisherへ追加の手順を求める予定だと説明している。non-personalized adsを表示したいpublisher向けの仕組みも5月までに出す予定とされた。3月25日の時点では、予定されている仕組みを前提に設定を決めず、今使っている広告とtagを確認する。

広告の表示と情報の送信を別に書き出す

siteへ広告を表示していると、画面で見えるbannerだけを広告の仕組みだと考えがちである。しかし、広告の表示、利用者の行動を測るtag、過去にsiteを見た人へ広告を出すためのtagは、同じpageに入っていても役割が違う。どれを使っているか分からないまま、同意文だけを足しても、説明する内容を決められない。

最初に、広告を出しているpageと、広告から利用者を送っているpageを分けて一覧にする。次に、pageのsource、theme、plugin、tag管理用のcontainerを確認し、入っているscriptの名前と送信先を控える。広告を表示するcode、accessを測るcode、conversionを数えるcode、外部serviceのwidgetを、一行ずつ分ける。ここでは、残すか止めるかをすぐ決めなくてよい。現状を見えるようにすることが先である。

たとえば、広告を載せる記事pageには広告のcodeがあり、問い合わせpageには広告から来た人の完了を数えるconversion tagが入っている場合がある。前者は広告を出すため、後者は広告の結果を数えるために使う。二つを同じ「広告tag」とまとめると、問い合わせpageで何を送るのか、広告を止めたら何の数字が取れなくなるのかを説明できない。

一覧には、tagの名前だけでなく、設置した人、管理するaccount、変更できる人も残す。制作会社がcodeを入れ、広告代理店がaccountを管理し、事業者が問い合わせを受ける形なら、三者の仕事は違う。作業を頼んだ相手だけが送信先を知る状態にしない。domain、広告account、tagの管理場所が誰の名義かも確かめる。

同意画面は目的と送信先が決まってから作る

Googleの案内は、GDPRに合わせてEU consent policyを更新し、publisherが利用者からconsentを得るために追加の手順を取る予定だとしている。これは、短いnoticeを一度表示すれば済むという意味ではない。利用者へ何を伝え、どの選択を求め、選択した後にどのtagを動かすのかを、実際の設置内容に合わせて決める必要がある。

ここで混同しやすいのは、privacy policyと同意を求める画面の役割である。privacy policyは、siteがどのような情報を扱うかを説明する文書になる。一方、画面上の同意は、利用者がpageを開いた時点でどのような選択をできるかに関係する。どちらか一つへ広告や計測の説明を押し込むのでなく、読む場所と選ぶ場所を分けて考える。

まず、棚卸ししたtagごとに、何のために置くかを短く書く。広告を表示するためか、広告経由の問い合わせを数えるためか、以前見た商品を再び案内するためか。目的が決まらないtagは、同意画面の対象を考える前に、残す必要があるかを確認する。利用していないtagを残したまま、説明と同意の範囲だけを増やす理由はない。

次に、利用者が選んだ結果を、誰が設定へ反映するか決める。文言を直す人、tagを置く人、広告の設定を変える人、問い合わせを受ける人が別なら、公開前に一度同じ画面を確認する。表示文だけを変更して、tagの動きが変わらなければ、説明と実際がずれる。反対にtagを止めても、広告側の設定や計測の確認が残ることがある。文章と設定を別々に終わらせない。

予定されている仕組みを先に使ったことにしない

Googleは、non-personalized adsを表示したいpublisherを支える仕組みを5月までに出す予定だとしている。3月の段階では、機能名、設定画面、利用条件が出そろっているとは限らない。予定を読んで、すでに選べる設定として手順書へ書かない。

今できるのは、選択肢が出たときに判断できるよう、広告を表示するpage、利用しているtag、広告が収益や集客へ果たす役割を確認しておくことだ。たとえば、広告を載せる記事pageがあるなら、広告を外した場合に何が変わるかだけでなく、本文やnavigationが読みやすいかを確認する。広告から問い合わせpageへ送る場合は、広告の結果を数えるために、どのpageで何をconversionとしているかを確認する。

新しい選択肢が提供された後に必要なのは、accountの設定を一度替えることではない。対象になる利用者、広告の表示、tagの送信、reportの数字が、決めた方針どおりかを確認することである。設定後に広告の表示や計測結果が変わっても、同意の選択による変化なのか、pageの変更や配信条件による変化なのかを分けて記録する。

最後に法律の適用範囲と実装を確認する

GDPRが自社siteへどこまで関係するかは、利用者、提供する商品やservice、扱う情報、広告の仕組みによって変わる。Googleの広告サービスに関する案内だけから、自社に必要な法的対応を確定してはいけない。対象範囲や必要な同意の内容は、関係する法令と専門家へ確認する。

ただし、法的な確認を待つ間にも、広告tagの棚卸しはできる。どのpageで、どのcodeが、どこへ何のために送信するのか。誰がaccountとcodeを管理し、利用者の選択を誰が確認するのか。これを残しておけば、専門家へ相談するときにも、制作者へ実装を頼むときにも、必要な範囲を伝えられる。

GDPR対応を、policy pageを一枚増やす仕事にしない。広告の表示、tagの送信、同意を求める画面、accountを管理する人を分けて確認する。まず現状を棚卸しし、必要な説明と選択を決め、実際の画面と設定がそろうまで確かめる。この順序なら、予定だけを頼りに急いで設定を替えるより、運用に残る形で準備できる。