顧客(消費者/データ主体)から、お客様がどのような顧客データを管理しているのかを知りたいという要求や、お客様の Analytics プロパティから自分のデータを削除してほしいという要求があった場合は、データ管理者であるお客様には、そうした要求に応える義務があります。データ管理者は、データ主体とのインタラクションの方法(データ主体のユーザーポータルを利用するなど)を決定し、その管理をおこないます。要求を処理するにあたり、データ主体に適切に応対することも、データ管理者の義務です。Adobe Experience Cloud はデータ処理者なので、データ主体から直接要求を受け取ったり、データ主体に直接データを返したりすることはありません。アドビはデータ管理者であるお客様を介してのみ、要求を受け取ったり、データを返したりします。
また、必要に応じてモバイルアプリや Web サイトにポップアップ通知や補足資料を用意することで、個人を直接的または間接的に特定できるデータなど、御社が収集したデータに対してデータ主体が持つ権利について説明することが求められます。
データ管理者には、データ主体に関するデータ(場合によっては Adobe Analytics データを含む)を収集する前に、データ主体から明示的な同意を得る責任があります。また、Web サイトにオプトアウトメカニズムを実装する責任があります。これにより、データ主体は、以降の Adobe Experience Cloud によるデータ収集をオプトアウトできます。
データ管理者であるお客様には、データ主体が言及されている本人であることと、要求したデータに対する権利をデータ主体が持っていることを確認する義務があります。また、正しいデータをデータ主体に返し、データ主体が誤って他のデータ主体のデータを受け取ることがないようにする義務もあります。
これには、データプライバシーアクセス要求時に Adobe Analytics から返されたデータを、データ主体に送信する前に確認することも含まれます。お客様がユーザー ID を使用しており、その ID が含まれるデータだけでなく、その ID が含まれていたことがある共有デバイス上の他のヒットのデータも返す場合は、特に注意が必要です。詳しくは、ID 拡張を参照してください。
各ファイルですべてのレポートスイートのデータが結合され、レプリケートされたヒットの余分なコピーは自動的に削除されます。お客様は、これらのファイルのうちどれをデータ主体に返すかを決めることができます。例えば、これらのデータの一部を抽出し、他のシステムのデータと組み合わせてからデータ主体に返すことができます。
プライバシーサービス UI やプライバシーサービス API を使用して、データプライバシーのアクセスリクエストや削除リクエストを送信することができます。
データプライバシー API は、単一の要求の複数のユーザーに対する一括送信をサポートしています。現在サポートされている制限は、単一の要求 JSON ファイルで 1,000 人の個別のユーザー(ユーザーごとに複数の ID を持つ可能性がある)です。
以下に、データプライバシー API または UI を使用して送信される、3 人のユーザーにデータプライバシー処理を要求する JSON を示します。
{
"companyContexts": [
{
"namespace": "imsOrgID",
"value": "5D7236525AA6D9580A495C6C@AdobeOrg"
}
],
"users": [
{
"key": "Data Privacy-1234",
"action": ["access"],
"userIDs": [
{
"namespace": "AAID",
"namespaceId", 10,
"type": "standard",
"description": "Legacy Visitor ID",
"value": "2D783E5885312539-4000010360000181",
}
]
},
{
"key": "Data Privacy-1235",
"action": ["access"],
"userIDs": [
{
"namespace": "ECID",
"namespaceId": 4,
"type": "standard",
"description": "This is the ID generated by the Adobe ID service.",
"value": "22470866493385587460528148368265592748",
}
]
},
{
"key": "Data Privacy-1236",
"action": ["access","delete"],
"userIDs": [
{
"namespace": "CRM-ID",
"type": "analytics",
"description": "namespace defined on eVar17 in some report suites",
"value": "ACME-12345678"
},
{
"namespace": "email address",
"type": "analytics",
"description": "namespace defined on eVar23 in some report suites",
"value": "john@mail.com"
}
]
}
],
"expandIds": true
}
ユーザーのセクションに、(おそらく 3 人の個別のデータ主体に対する)3 つの個別の要求を表す 3 つのブロックがあることに注意してください。
次の点に注意してください。
ここでは、アクセス応答および削除応答の詳細について説明します。
アクセス応答の詳細
データ管理者であるお客様のアクセス要求に対して返されるデータには、お客様が所有する各アドビ製品のディレクトリを含む、ZIP ファイルをダウンロードできる URL が含まれます。Analytics フォルダー内には、次のいずれかまたは両方のファイルが含まれています。
ユーザーファイル – 一致した ID-PERSON ラベルを含むヒットを基に作成されます。
デバイスファイル – いずれかのフィールドが指定した ID-DEVICE に一致したが、指定した ID-PERSON には一致しなかったヒットから派生します。
各ファイルですべてのレポートスイートのデータが結合され、レプリケートされたヒットの余分なコピーは自動的に削除されます。
お客様は、これらのうちどのデータをデータ主体に返すかを決めることができます。例えば、これらのデータの一部を抽出し、他のシステムのデータと組み合わせてからデータ主体に返すことができます。
削除応答の詳細
削除要求に対してはデータは返されません。要求が正常に処理されたことを示すステータスがデータプライバシー API に返されます。
通常、Analytics をご利用のお客様は、一般公開される前にテストレポートスイートをいくつかセットアップして機能を確認します。実稼動レポートスイートに実際のトラフィックを送信する前に、実稼動前の Webサイトまたはアプリからこれらのテスト/開発/QA レポートスイートにデータを送信して、リリース後のコードの動作を評価します。
ただし、通常の設定では、実稼動レポートスイートに要求を適用する前にこれらのテストレポートスイートで GDPR 要求処理をテストすることはできません。これは、データプライバシー要求が Experience Cloud 組織内のすべてのレポートスイート(多くの場合、会社のすべてのレポートスイート)に自動的に適用されるからです。
それでも、すべてのレポートスイートに適用する前にデータプライバシー処理をテストできる方法がいくつかあります。
選択肢の 1 つは、テストレポートスイートのみが含まれる Experience Cloud 組織を別にセットアップすることです。次に、データプライバシーテストに対してこの Experience Cloud 組織を使用し、実際のデータプライバシー処理に対して通常の Experience Cloud 組織を使用します。
もう 1 つの選択肢は、実稼動レポートスイートとは異なる名前空間をテストレポートスイートの ID に割り当てることです。
例えば、テストレポートスイートでは、各名前空間に「qa-」というプレフィックスを付けることができます。qa プレフィックスの付いた名前空間のみを持つデータプライバシー要求を送信すると、それらの要求はテストレポートスイートに対してのみ実行されます。その後で、qa プレフィックスを付けずに要求を送信すると、それらの要求は実稼動レポートスイートに対して適用されます。これは、visitorId、AAID、ECID、customVisitorId のいずれの名前空間も使用していない場合に推奨される方法です。これらの名前空間はハードコードされており、テストレポートスイートで別の名前を付けることができないからです。