Analytics 変数のデータプライバシーラベル
Adobeのお客様は、データ管理者として、EU 一般データ保護規則(GDPR)やカリフォルニア州消費者プライバシー法(CCPA)など、適用されるデータプライバシー法に準拠する責任を負います。 お客様は、自社の法務チームに相談して、データプライバシー法に準拠するためのデータの処理方法を決定する必要があります。アドビは、各お客様がプライバシーに関連する固有のニーズを持っていることを理解しています。そのため、アドビはお客様がデータプライバシーのデータ処理に関する目的の設定をカスタマイズできるようにしています。これにより、それぞれのお客様が、ブランドのニーズと保有するデータセットに最適な方法でデータプライバシー要求を処理できます。
Adobe Analytics では、計測データのプライバシー性と契約上の制限に従ってデータをラベルで分類するためのツールの提供を開始します。ラベルは、(1)データ主体の識別、(2)アクセスリクエストの一部として返すデータの決定、(3)削除リクエストの一部として削除する必要があるデータフィールドの識別のための重要なステップです。
どの変数やフィールドにどのラベルを適用するかを把握するためには、Analytics データから取得する ID について理解し、データプライバシー要求でどのような ID を使用するかを決める必要があります。
Adobe Analytics のデータプライバシー実装では、識別データ、機密データ、データガバナンス用に以下のラベルを利用できます。
識別データラベル identity-data-labels
識別データの「I」ラベルは、個人を特定できるデータまたは個人に連絡できるデータの分類に使用されます。
- イベントには設定できません。
- マーチャンダイジング eVar には設定できません。
- イベントには設定できません。
- マーチャンダイジング eVar には設定できません。
機密データラベル sensitive-data-labels
機密データの「S」ラベルは、地理データなどの機密データの分類に使用されます。将来的に、他のタイプの機密情報を特定するために、追加の機密データラベルが導入される予定です。
データガバナンスラベル(データプライバシー) data-governance-labels
データガバナンスラベルを使用すると、アドビのお客様が規制や企業のポリシーに引き続き準拠するのに役立つ、プライバシー関連の注意事項や契約条件を反映したデータを分類できます。
データプライバシーアクセスラベル access
ほとんどの変数は他のラベルを受け取りませんが、アクセスラベルが多くの変数に適用されることが期待されます。ただし、自社の法務チームと相談し、収集したデータのうちどれをデータ主体と共有するかを決めるのは、お客様次第です。
データプライバシー削除ラベル delete
他のラベルとは異なり、これらの削除ラベルは相互に排他的ではありません。どちらか、両方、なしを選択できます。どちらの削除オプションもただチェックしなければ「なし」が表示されるので、「なし」ラベルを別途指定する必要はありません。
削除ラベルは、ヒットとデータ主体との関連付けを許可する(つまり、データ主体の識別を許可する)値を含んだフィールドに対してのみ必要です。他の個人情報(お気に入り、閲覧/購入履歴、健康状態など)は、データ主体との関連付けがなくなるので、削除する必要はありません。
- I1、I2 または S1 ラベルも必要です。
- イベントには設定できません。
- マーチャンダイジング eVar には設定できません。
- 分類には設定できません。
- ID-DEVICE を使用して要求を送信するか、expandIDs を true に設定する必要があります。そうでない場合、このラベルは適用されません。
- I1、I2 または S1 ラベルも必要です。
- イベントには設定できません。
- マーチャンダイジング eVar には設定できません。
- 分類には設定できません。
- また、このレポートスイート内の何らかの変数に設定された ID-PERSON ラベルを使用してリクエストを送信し、その ID を使用してリクエストを送信する必要があります。そうでない場合、このラベルは適用されません。
データプライバシー ID ラベル identity
I1 または I2 ラベルも必要です。
- イベントには設定できません。
- マーチャンダイジング eVar には設定できません。
- 分類には設定できません。
- I1 または I2 ラベルも必要です。
- イベントには設定できません。
- マーチャンダイジング eVar には設定できません。
- 分類には設定できません。
変数を ID-DEVICE または ID-PERSON としてラベル設定する際の名前空間の提供 provide-namespace
変数を ID-DEVICE または ID-PERSON としてラベル設定する場合、名前空間を提供するよう指示されます。以前定義した名前空間を使用することも、新しい名前空間を定義することもできます。
以前定義した名前空間の使用 previously-defined
以前、ログイン会社の任意のレポートスイートの他の変数に ID ラベルを割り当てたことがある場合は、これらの既存の名前空間の 1 つを選択できます。名前空間で既にラベル付けされている他の変数と同じタイプの ID がこの変数に含まれている場合、また要求を送信する際に、それらの ID をすべて検索する必要がある場合、その名前空間を再利用してください。
- 「名前空間を選択」をクリックして、既存の名前空間の 1 つを選択します。
- 「適用」をクリックします。
新しい名前空間の定義 define
また、新しい名前空間を定義することもできます。名前空間文字列は、英数字、アンダースコア、ダッシュおよびスペースに制限することをお勧めします。すべて小文字に変換されます。
-
「名前空間を選択」をクリックして、名前空間のタイトルを入力します。
-
Enter キーを押してこの名前空間を追加します。これで「適用」ボタンがアクティブになります。
-
「適用」をクリックします。
名前空間として指定した文字列は、データプライバシー API で要求を「名前空間」パラメーターの値として送信する際に使用する必要がある文字列と同じです。次に、リクエストにより、Adobe Analytics は、リクエストで指定した ID のこの名前空間を共有するすべてのレポートスイート内のすべての変数を検索します。
ID を含むすべての変数に ID-DEVICE ラベルまたは ID-PERSON ラベルを指定する必要はありません(このために I1/I2 ラベルがあります)。この変数に保存された ID を使用してデータプライバシー要求を送信し、特定の ID についてこの変数を検索したい場合に、このラベルを使用します。例えば、eVar1 に電子メールアドレスを、eVar2 にログインユーザー名を含むことができるが、ユーザー名のみを使用して要求を送信する場合、eVar1 には I1、ACC-PERSON、DEL-PERSON とラベル設定しますが、eVar2 は名前空間「ユーザー名」と共に、I2、ACC-PERSON、DEL-PERSON、ID-PERSON とラベル設定します。次に、以下のようにユーザーセクション JSON ブロックを使用して要求を送信します。
{
"namespace": "user name",
"type": "analytics",
"value": "rocketman123"
}
同じレポートスイート内の異なる変数に同じ名前空間を使用することもできます。例えば、一部のカスタム実装は、prop と eVar の両方に CRM-ID を保存します。CRM-ID が常にこれらのどちらか(eVar など)にあり、まれに他方(prop)にあるが、eVar にもないときに prop にない場合、アドビは、ID をその eVar でのみ検索できるので、eVar のみ ID ラベルおよび名前空間が必要です。ただし、CRM-ID が一方の変数にあることも、もう一方の変数にあることもある場合、両方が同じ名前空間を持つ必要があり、アドビは、この名前空間を持つ、データプライバシー要求の一環として指定した ID について、両方の変数を検索します。それでも、これらのすべての変数に対して DEL ラベルを設定する必要があります。それにより、どこで出現しても値が匿名化されます。
別の例として、eVar1 を使用して送信されることも、prop7 を使用して送信されることもある CRM ID があるとします。また、eVar1 から eVar3(存在する場合)に値をコピーする処理ルールがあります。そうでない場合は、prop7 から eVar3 に値をコピーします。このシナリオでは、CRM ID がわかっている場合、必ずそれが eVar3 に格納されるので、ID-PERSON ラベルが必要なのは eVar3 のみとなります。
変数のタイプとそれぞれが対応しているデータプライバシーラベル variable-types
データプライバシーのラベル設定は、Analytics 変数の 4 つの主要クラスに影響します。すべての変数ですべてのラベルを利用できるわけではありません。以下の表には、各変数で利用できるラベルと利用できないラベルがまとめられています。
- カスタム成功イベント
- マーチャンダイジング eVar
- 複数値の変数(mvVar)
- 階層変数
- S1/S2
- ACC-ALL、ACC-PERSON
- I1/I2
- ID-DEVICE、ID-PERSON
- DEL-DEVICE、DEL-PERSON
- I1/I2、S1/S2
- ACC-ALL、ACC-PERSON
- ID-DEVICE、ID-PERSON
- DEL-DEVICE、DEL-PERSON
- トラフィック変数(prop)
- コマース変数(非マーチャンダイジング eVar)
- I1/I2、S1/S2
- ID-DEVICE、ID-PERSON
- DEL-DEVICE、DEL-PERSON)
ACC-ALL/ACC-PERSON 以外のラベルを割り当てる/変更することができる変数 variables
- コンバージョンディメンション
- カスタムトラフィックディメンション
なし/I1/I2
なし/S1/S2
Activity Map リンク,
Activity Map ページ
なし/I1/I2
なし/DEL-DEVICE/DEL-PERSON
変数に、個人を直接的または間接的に特定できるデータを含む URL パラメーターが追加される場合があります。これらの変数で個人を直接的または間接的に特定できるデータを収集しない実装の場合は、識別ラベルおよび削除ラベルは不要です。
削除によって URL パラメーターはクリアされますが、元の URL は保持されます。
ID-DEVICE/ID-PERSON
DEL-DEVICE/DEL-PERSON
ID または DEL ラベルを削除(なしに設定)することはできませんが、カスタム ID 実装に応じて、DEVICE バリアントまたは PERSON バリアントに変更できます。
カスタム訪問者 ID を使用しない場合、設定は関係ありません。
- 標準のディメンション
- データ処理ディメンション
IP アドレス
IP アドレス 2
ClickMap アクション(従来)、
ClickMap コンテキスト(従来)、
ページ、
ページ URL、
オリジナル入口ページ URL、
リファラー、
訪問開始ページ URL
なし/I1/I2
なし/DEL-DEVICE/DEL-PERSON
変数に、個人を直接的または間接的に特定できるデータを含む URL パラメーターが追加される場合があります。これらの変数で個人を直接的または間接的に特定できるデータを収集しない実装の場合は、識別ラベルおよび削除ラベルは不要です。
削除によって URL パラメーターはクリアされますが、元の URL は保持されます。
削除処理 deletion
Adobe Analytics でのデータプライバシー削除要求は、レポートへの影響を最小限に抑えるように設計されています。ほとんどの場合、レポートに表示される指標は変わりません。データプライバシー削除の前に実行された履歴レポートは、削除の後に実行された同じレポートと一致します。これは、削除されたデータをデータ主体から完全に切り離し、個人を特定できないデータを保持してレポートの値の一貫性を保つことで実現されます。
次の表に、様々な変数の「削除」方法を示します。ここでは一部のみをリストしています。
- トラフィック変数(prop)
- コマース変数(eVar)
既存の値は、「Data Privacy-356396D55C4F9C7AB3FBB2F2FA223482」という形式の新しい値に置き換わります。ここで、「Data Privacy-」プレフィックスの後の 32 桁の 16 進数値は、暗号論的に強固な 128 ビット疑似乱数です。
基本的にはランダムな文字列に置き換わるので、この新しい値から元の値を決定する方法はなく、新しい値をたどって元の値を知ることはできません。特定の変数について、置き換えられる値と同一の値が、同じデータプライバシー要求の一部として削除される他のヒット内に存在する場合、その値のすべてのインスタンスが同じ新しい値に置き換えられます。
値の一部のインスタンスがある削除要求で置き換えられる場合で、後の要求が元の値の他の(新しい)インスタンスを削除する場合、新しく置き換えられる値は、元の置き換えられる値とは違うものになります。
既存の値は、「G-7588FCD8642718EC50」という形の新しい値で置き換えられます。ここで、「G-」プレフィックスの後の 18 桁の 16 進数は、暗号として強固な 128 bit 疑似乱数の最初の 18 桁です。トラフィックおよびコマース変数の削除に適用されるすべてのコメントは、ここにも適用されます。
購入 ID はトランザクション ID で、購入確認ページの表示を更新する場合など、購入の二重処理が行われていないことを確認することが主な目的です。ID 自体は、購入が記録される独自の DB 内の行に購入を関連付けている場合があります。ほとんどの場合、この ID を削除する必要はないので、デフォルトでは削除されません。
独自のデータのデータプライバシー削除要求の後でもまだ購入をユーザーに関連付けできる場合、この訪問者の Analytics データを購入者に関連付けできないように、このフィールドを削除する必要がある場合があります。
- MCID
- カスタム訪問者 ID
- IP アドレス
- IP アドレス 2
- ClickMap アクション(従来)
- ClickMap コンテキスト(従来)
- ページ
- ページ URL
- オリジナル入口ページ URL
- リファラー
- 訪問開始ページ URL
- 緯度
- 経度
想定される削除ラベルをサポートしていない変数 no-delete-support
この節では、削除に対応していない Analytics 変数について説明します。これらの変数は、変数に含まれているデータのタイプを理解しておらず、変数の名前に基づいて不適切な判断をしかねない Analytics 以外のユーザー(法務チームなど)によって削除されてしまう可能性があります。
ラベル設定や削除に関する決定を行う前に、各変数に含まれるデータのタイプを理解し、変数名のみに依存しないようにすることが重要です。ここでは、これらの変数の一部をリストします。また、削除が不要な理由や、特定の削除ラベルを必要としない理由も示します。
郵便番号
位置情報の郵便番号
位置情報の緯度
位置情報の経度
訪問者 ID
MCID/ECID
これらの ID には DEL-DEVICE ラベルが設定されていますが、DEL-PERSON ラベルを追加することはできません。各リクエストで ID 拡張を指定した場合は、ID-PERSON を使用しているリクエストも含め、すべての削除リクエストについて、これらの ID が自動的に削除されます。
ID 拡張を使用しないが、一致する ID が prop または eVar に含まれているヒットでこれらの Cookie ID を匿名化したい場合は、実際にユーザーを特定できる場合でも、prop または eVar に ID-DEVICE ラベルを設定することで、このラベル設定の制限を回避できます(すべての DEL-PERSON ラベルを DEL-DEVICE ラベルに変更する必要があります)。この場合、訪問者 ID または ECID の一部のインスタンスのみが匿名化されるので、履歴レポートでは個別訪問者数が変更されます。
アクセスリクエストのデータフィールド access-requests
5 つのタイムスタンプを含む標準変数があります。
データプライバシーアクセス要求用に返されたファイルを生成するコードでは、少なくとも最初の 3 つのタイムスタンプ変数のいずれかがアクセス要求に含まれている(この要求のタイプに適用する ACC ラベルを持つ)必要があります。これらがいずれも含まれていない場合、「カスタムヒット時刻 (UTC)」が ACC-ALL ラベルを持つかのように扱われます。
データプライバシーアクセスリクエストに対して返されたヒットレベル CSV ファイルでは、これらのフィールドの値を Unix タイムスタンプから形式 YYYY-MM-DD HH:MM:SS
の日付/時刻フィールド(例:2018-05-01 13:49:22
)に変換します。 概要HTMLファイルでは、これらのタイムスタンプ値は、日付 YYYY-MM-DD
のみを含むように切り捨てられて、これらのフィールドに発生する一意の値の数を減らします。