Analytics 変数のデータプライバシーラベル

アドビのお客様は、データ管理者として、EU 一般データ保護規則（GDPR）やカリフォルニア州消費者プライバシー法（CCPA）など、適用されるデータプライバシー法に準拠する責任を負います。お客様は、自社の法務チームに相談して、データプライバシー法に準拠するためのデータの処理方法を決定する必要があります。アドビは、各お客様がプライバシーに関連する固有のニーズを持っていることを理解しています。そのため、アドビはお客様がデータプライバシーのデータ処理に関する目的の設定をカスタマイズできるようにしています。これにより、それぞれのお客様が、ブランドのニーズと保有するデータセットに最適な方法でデータプライバシー要求を処理できます。

Adobe Analytics では、計測データのプライバシー性と契約上の制限に従ってデータをラベルで分類するためのツールの提供を開始します。ラベルは、（1）データ主体の識別、（2）アクセスリクエストの一部として返すデータの決定、（3）削除リクエストの一部として削除する必要があるデータフィールドの識別のための重要なステップです。

どの変数やフィールドにどのラベルを適用するかを把握するためには、Analytics データから取得する ID について理解し、データプライバシー要求でどのような ID を使用するかを決める必要があります。

Adobe Analytics のデータプライバシー実装では、識別データ、機密データ、データガバナンス用に以下のラベルを利用できます。

識別データラベル identity-data-labels

識別データの「I」ラベルは、個人を特定できるデータまたは個人に連絡できるデータの分類に使用されます。

機密データラベル sensitive-data-labels

機密データの「S」ラベルは、地理データなどの機密データの分類に使用されます。将来的に、他のタイプの機密情報を特定するために、追加の機密データラベルが導入される予定です。

データガバナンスラベル（データプライバシー） data-governance-labels

データガバナンスラベルを使用すると、アドビのお客様が規制や企業のポリシーに引き続き準拠するのに役立つ、プライバシー関連の注意事項や契約条件を反映したデータを分類できます。

データプライバシーアクセスラベル access

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

データプライバシー削除ラベル delete

他のラベルとは異なり、これらの削除ラベルは相互に排他的ではありません。 両方またはゼロを選択できます。 どちらの削除オプションもただチェックしなければ「なし」が表示されるので、「なし」ラベルを別途指定する必要はありません。

削除ラベルは、ヒットとデータ主体との関連付けを許可する（つまり、データ主体の識別を許可する）値を含んだフィールドに対してのみ必要です。他の個人情報（お気に入り、閲覧／購入履歴、健康状態など）は、データ主体との関連付けがなくなるので、削除する必要はありません。

データプライバシー ID ラベル identity

変数を ID-DEVICE または ID-PERSON としてラベル設定する際の名前空間の提供 provide-namespace

変数を ID-DEVICE または ID-PERSON としてラベル設定する場合、名前空間を提供するよう指示されます。以前定義した名前空間を使用することも、新しい名前空間を定義することもできます。

以前定義した名前空間の使用 previously-defined

以前、ログイン会社の任意のレポートスイートの他の変数に ID ラベルを割り当てたことがある場合は、これらの既存の名前空間の 1 つを選択できます。この変数に、この名前空間で既にラベル付けされている他の変数と同じタイプのIDが含まれており、リクエストの送信時にすべてを検索する必要がある場合は、名前空間を再利用する必要があります。

新しい名前空間の定義 define

新しい名前空間を定義することもできます。 名前空間文字列は、英数字に加えて、アンダースコア、ダッシュ、スペースに制限することをお勧めします。 すべての小文字に変換されます。

名前空間として指定した文字列は、データプライバシー 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 ラベルを付ける必要があります。これにより、値がどこで発生しても匿名化されます。

別の例として、CRM IDがeVar 1経由で送信されることもあれば、prop7経由で送信されることもあります。 次に、値をeVar1からeVar3にコピーする処理ルールがあります。 そうでない場合は、prop7 から eVar3 に値をコピーします。このシナリオでは、CRM ID がわかっている場合、必ずそれが eVar3 に格納されるので、ID-PERSON ラベルが必要なのは eVar3 のみとなります。

変数のタイプとそれぞれが対応しているデータプライバシーラベル variable-types

データプライバシーのラベル設定は、Analytics 変数の 4 つの主要クラスに影響します。すべての変数ですべてのラベルを利用できるわけではありません。以下の表には、各変数で利用できるラベルと利用できないラベルがまとめられています。

ACC-ALL／ACC-PERSON 以外のラベルを割り当てる／変更することができる変数 variables

削除処理 deletion

Adobe Analytics でのデータプライバシー削除要求は、レポートへの影響を最小限に抑えるように設計されています。ほとんどの場合、レポートに表示される指標は変わりません。データプライバシー削除の前に実行された履歴レポートは、削除の後に実行された同じレポートと一致します。これは、削除されたデータをデータ主体から完全に切り離し、個人を特定できないデータを保持してレポートの値の一貫性を保つことで実現されます。

次の表に、様々な変数の「削除」方法を示します。完全なリストではありません。

想定される削除ラベルをサポートしていない変数 no-delete-support

この節では、削除に対応していない Analytics 変数について説明します。これらの変数は、変数に含まれているデータのタイプを理解しておらず、変数の名前に基づいて不適切な判断をしかねない Analytics 以外のユーザー（法務チームなど）によって削除されてしまう可能性があります。

ラベル設定や削除に関する決定を行う前に、各変数に含まれるデータのタイプを理解し、変数名のみに依存しないようにすることが重要です。ここでは、これらの変数の一部をリストします。また、削除が不要な理由や、特定の削除ラベルを必要としない理由も示します。

アクセスリクエストのデータフィールド 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 のみを含むように切り捨てられて、これらのフィールド用に発生する一意の値の数を減らします。