GDPR準拠の要件を満たすため、Adobe Analyticsにも保持期間の設定とそれを超えたデータの自動削除機能が実装されました。Googleアナリティクスの場合は一部の集計データのみ残るという仕様ですが、Adobe Analyticsの場合はざくっと月単位で全部消えます。一方、個人から受け付けるGDPR要求の対応に関しては、返すべきデータと消すべきデータを細かく設定できます。

保持期間は契約次第

Adobe Analyticsのデータ保持期間は、Adobeとの契約書で25ヶ月などと定められています。2018年5月23日よりも前に契約した場合、1年間のオマケがついるはずです。

まず、保持期間がどう設定されているかの現状を確認してみましょう。Analyticsにログインし、「管理者」メニューの中にある「データガバナンス」をクリックします。

  • この例では37ヶ月になっています
  • 保持期間の変更はAdobeに依頼する必要があります
  • 短縮は無償、延長には追加の費用がかかります

月単位で全部消える

削除は月単位で行われます。毎月一度、期限を過ぎた月のデータが消えていきます。
例えば2018年6月2日現在、以下のように2015年3月31日までのデータが削除されてレポートに表示されなくなっていることを確認できました。

参考:データ保持に関する公式FAQ

GDPR要求の対象データを特定するラベル付け

個人(データ主体)からのデータのアクセスや削除要求への対応については、細かい設定が可能です。「可能」というより、設定は必須です。全てのデータ(ディメンションと指標)に、方針を表すラベルを設定しておく必要があります。

データガバナンスの画面でレポートスイートをクリックすると、その設定を確認・変更できます。

標準的なディメンションと指標のみ、便宜的にデフォルトでいくつかの設定がされた状態になっていますが、Adobeが法的な責任を持つ訳ではないので、導入企業が判断して追加や変更する必要があります。特にカスタムディメンション(eVar, Prop)や指標(event)は、全て無設定の状態になっているはずです。

ラベルで分類すべきデータ

  • IDデータ:個人を直接・間接的に特定できるデータ
  • 機密データ:地理情報などプライバシーに関わるデータ(センシティブなデータの誤訳)
  • データガバナンス:GDPR要求を受けた際に対象とするデータ
    • 個人データのアクセス・削除を要求した個人を特定するためのキーとするデータ
    • アクセス(開示・送付)要求を受けた場合に返送すべきデータ
    • 削除要求を受けた場合に削除すべきデータ

すべてのディメンションと指標を、これらの3カテゴリごとに分類します。GDPR対応に直接的に必要なのは3つ目の「データガバナンス」ですが、その設定のために「IDデータ」と「機密データ」も設定しておく必要があります。

参考:GDPRラベル関する公式ヘルプ

1. IとID - どのディメンションで個人を特定するか?

まず、個人を特定できるデータにI1またはI2ラベルをつけます。

  • I1(個人を直接的に特定可能):名前やEmailアドレス、住所など、それだけで個人を特定できるデータ
  • I2(個人を間接的に特定可能):会員IDやオンライン識別子(訪問者ID、ECID、MCID)など、社外のデータを含む他のデータと組み合わせることで個人を特定できるデータ

アナリティクスの場合、I1のデータを収集することは基本的に無く、オンライン識別子はデフォルトでI2が設定されているので、実際には会員IDなどをeVarに入れている場合のみ追加でI2を付与することになると思います。

次に、アクセスや削除の要求をした本人(データ主体)を特定するためのID(キー)を選定します。本人確認をしないと、他人のセンシティブなデータを送付してしまい、データ漏えいにつながるリスクがあるためです。本人確認をどの程度どのようにして行うかの運用フローは、慎重な検討が必要です。例えば、IPアドレスは個人を間接的に特定できるI2に該当しますが、同じIPが別のデバイスで流用・共有されることがあるので、単体では本人確認できません。
Cookieに保存されるオンライン識別子も同様で、ブラウザまでしか特定できません。同じデバイスの同じブラウザを別の人が使うこともあるからです。
ログイン後に取得する会員IDなら個人レベルまで特定できますが、ログインしないサイトでは使えません。

このように、個人レベルで本人を認証できたのか、それともブラウザやデバイスまでしか特定できていないのか、によって、返信や削除するデータの種類を変える必要があります。以下のラベルによって、このレベルを区別した上で本人特定に使えるディメンションを指定します。

  • ID-PERSON:認証済みユーザー(特定のユーザー)の識別に使用するID
  • ID-DEVICE:デバイス(ブラウザ)の識別に使用するID

I1やI2のラベルをつけたディメンションの中から慎重に選んだ1〜2個のディメンションのみに、データガバナンスの以下のラベルを付与することになります。

参考:GDPRラベル設定のIDに関する公式ヘルプ

2. ACC - どのデータを返送すべきか?

GDPRでは、自分の個人データにアクセスする(送付してもらう)権利が保障されています。このデータのアクセス要求を個人から受け付けた場合に、どのデータを抽出して返送するのかを決めて、それぞれにデータガバナンスのACCラベルを付与します。

  • ACC-ALL:ECIDなどID-DEVICEが付与されたディメンションでゆるくデータを特定できた場合に返送するデータ
  • ACC-PERSON:会員IDなどID-PERSONが付与されたディメンションで本人を認証できた場合のみ返送するデータ

この設定もまた、他人のセンシティブなデータを送付してしまわないよう、慎重な検討が必要です。そのため、デフォルト設定では、最低限の標準ディメンションにのみACC-ALLが設定されています。それだけでは足りないので、残りの標準・カスタムディメンションにもACC-ALLまたはACC-PERSONを設定する必要があります。

オンライン識別子だけでアクセス要求を受け付けた場合にどこまでデータを開示すべきかは判断が必要です。Adobeの公式ヘルプでは以下のように説明されているのみで、どのデータにACC-ALLを付与すべきかの方針については書かれていません。

アクセスラベルが多くの変数に適用されることが期待されます。ただし、自社の法務チームと相談し、収集したデータのうちどれをデータ主体と共有するかを決めるのは、お客様次第です。

日本語がわかりにくいですが、「ほぼ全てのデータにACC-ALLまたはACC-PERSONのどちらかを付与するのが良いと思うけど自己判断でよろしく」という意味だと私は解釈しています。社内で議論し、例えば「全てのデータを隠さず返送するのが基本、ただし重複や類似データは省略、地域や検索キーワードや閲覧商品などセンシティブなデータは確実に本人認証できた場合のみ返送する」というようなポリシーを決める必要があります。どこまでをセンシティブとみなすのかがポイントですね。サイトによっては、閲覧したページもセンシティブな情報になり得ます。リファラや広告用パラメータなども、普段のオンライン行動癖が漏洩するので、微妙なところです。

3. DEL - データの削除はIDとの紐付け解除が目的

データの削除(匿名化)はデータと個人(ブラウザ)を紐付けできなくするのが目的なので、削除対象はディメンションのみ、その数はACCよりも圧倒的に少なくなるはずです。該当ディメンションの値はランダムな値で置き換えられ、同じヒットで送信されるその他のデータはそのまま残ります。元の値とランダム値は1:1の関係になるので、ユニーク性や連続性は維持されます。

どのデータを匿名化すればヒットと個人やブラウザが紐付かなくなるのかを調査・検討し、データガバナンスのDELラベルを付与します。

  • DEL-DEVICE:ECIDなどID-DEVICEが付与されたディメンションでゆるく特定できた場合に匿名化すべきディメンション(I1, I2, S1のいずれかも必要)
  • DEL-PERSON:会員IDなどID-PERSONが付与されたディメンションで本人を認証できた場合にのみ匿名化すべきディメンション(I1, I2, S1のいずれかも必要)

参照:ラベルを付与してアクセスや削除を実行するとどんなデータがどう変わるのかの具体例 - Adobe公式ヘルプ

まとめ

以上、Adobe AnalyticsのGDPR対策としての新機能について紹介しました。取得・保管する全てのデータを吟味し、2段階でプライバシー性(センシティブ性)を定義した上で、アクセスや削除要求に1ヶ月以内に対応できる運用プロセスを構築する必要があります。準備や社内調整に時間がかかるので、実際のリクエストが来る前に決めておくと良いでしょう。

なお、Googleアナリティクスの場合は、期限を過ぎたデータは個人やブラウザとの紐付けができなくなるようなデータの匿名化を行い、削除依頼があった場合はそのデータを完全削除するようです。期限を過ぎたら全部消し、削除依頼があったデータは個人やブラウザとの紐付けができなくなるようなデータの匿名化を行う、という逆のアプローチですね。GDPR施工の直前になって、それぞれが前例のない中で仕様を決めたためでしょう。GDPRの解釈はまだ曖昧なので、追加情報や前例が増えるにつれて仕様も変わっていくと思われます。