アクセス要求および削除要求の送信

顧客（消費者／データ主体）から、お客様がどのような顧客データを管理しているのかを知りたいという要求や、お客様の Analytics プロパティから自分のデータを削除してほしいという要求があった場合は、データ管理者であるお客様には、そうした要求に応える義務があります。データ管理者は、データ主体とのインタラクションの方法（データ主体のユーザーポータルを利用するなど）を決定し、その管理をおこないます。要求を処理するにあたり、データ主体に適切に応対することも、データ管理者の義務です。Adobe Experience Cloud はデータ処理者なので、データ主体から直接要求を受け取ったり、データ主体に直接データを返したりすることはありません。アドビはデータ管理者であるお客様を介してのみ、要求を受け取ったり、データを返したりします。

また、必要に応じてモバイルアプリや Web サイトにポップアップ通知や補足資料を用意することで、個人を直接的または間接的に特定できるデータなど、御社が収集したデータに対してデータ主体が持つ権利について説明することが求められます。

消費者の同意の管理

データ管理者には、データ主体に関するデータ（場合によっては Adobe Analytics データを含む）を収集する前に、データ主体から明示的な同意を得る責任があります。また、Web サイトにオプトアウトメカニズムを実装する責任があります。これにより、データ主体は、以降の Adobe Experience Cloud によるデータ収集をオプトアウトできます。

ユーザーおよびユーザーデータの検証

データ管理者であるお客様には、データ主体が言及されている本人であることと、要求したデータに対する権利をデータ主体が持っていることを確認する義務があります。また、正しいデータをデータ主体に返し、データ主体が誤って他のデータ主体のデータを受け取ることがないようにする義務もあります。

これには、データプライバシーアクセス要求時に Adobe Analytics から返されたデータを、データ主体に送信する前に確認することも含まれます。お客様がユーザー ID を使用しており、その ID が含まれるデータだけでなく、その ID が含まれていたことがある共有デバイス上の他のヒットのデータも返す場合は、特に注意が必要です。詳しくは、ID 拡張を参照してください。

各ファイルですべてのレポートスイートのデータが結合され、レプリケートされたヒットの余分なコピーは自動的に削除されます。お客様は、これらのファイルのうちどれをデータ主体に返すかを決めることができます。例えば、これらのデータの一部を抽出し、他のシステムのデータと組み合わせてからデータ主体に返すことができます。

要求の送信

データプライバシー UI ポータルやデータプライバシー API から、データプライバシーのアクセス要求や削除要求を送信することができます。

JSON 要求のサンプル

以下に、データプライバシー 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 つのブロックがあることに注意してください。

• 最初の要求は、従来の Adobe Analytics Cookie ID（AAID）を使用したアクセス要求です。
• 2 番目の要求もアクセス要求ですが、MCID／ECID Cookie を使用しています。
• 3 番目の要求は、指定した ID に対するアクセスおよび削除の要求です。ID 拡張はすべての要求に指定されていますが、唯一非 Cookie ID を使用するので、この 3 番目の要求が最も大きな影響を受けます。結果として、この要求においても、指定された CRM-ID または電子メールアドレスを使用して任意のデバイスに関連付けられた Cookie ID が検出され、これらの ID も対象とするよう要求が拡張されます。

次の点に注意してください。

• 「companyContexts」セクションにある値「5D7236525AA6D9580A495C6C@AdobeOrg」は、独自の Experience Cloud 組織の値で更新される必要があります。
• 「タイプ」および「名前空間」フィールドについては、「名前空間」の節に記載されています。
• 「説明」フィールドは無視されます。
• 「キー」フィールドには、任意の値を含めることができます。データプライバシー要求の追跡に使用している内部 ID がある場合、その値をここに配置して、アドビのシステムの要求を独自の社内システムの要求と簡単に一致させることができます。

応答の詳細

ここでは、アクセス応答および削除応答の詳細について説明します。

アクセス応答の詳細

データ管理者であるお客様のアクセス要求に対して返されるデータには、お客様が所有する各アドビ製品のディレクトリを含む、ZIP ファイルをダウンロードできる URL が含まれます。Analytics フォルダー内には、次のいずれかまたは両方のファイルが含まれています。

• ユーザーファイル – 一致した ID-PERSON ラベルを含むヒットを基に作成されます。

  • 一致するヒットごとの行と、ACC-ALL または ACC-PERSON ラベルを含むフィールドごとの列で構成される CSV ファイル。タイムスタンプを基準とした並び順になっています。
  • ACC-ALL または ACC-PERSON ラベルごとのエントリで構成される HTML 概要ファイル。各エントリには、そのフィールドのすべての一意の値と、それぞれの値が発生した回数がリストされます。タイムスタンプを含むフィールドは、一意の日付のみを指定するために丸められます。

• デバイスファイル – いずれかのフィールドが指定した ID-DEVICE に一致したが、指定した ID-PERSON には一致しなかったヒットから派生します。

  • 一致するヒットごとの行と、ACC-ALL ラベルを含むフィールドごとの列で構成される CSV ファイル。タイムスタンプを基準とした並び順になっています。
  • ACC-ALL ラベルごとのエントリで構成される HTML 概要ファイル。各エントリには、そのフィールドのすべての一意の値と、それぞれの値が発生した回数がリストされます。タイムスタンプを含むフィールドは、一意の日付のみを指定するために丸められます。

各ファイルですべてのレポートスイートのデータが結合され、レプリケートされたヒットの余分なコピーは自動的に削除されます。

お客様は、これらのうちどのデータをデータ主体に返すかを決めることができます。例えば、これらのデータの一部を抽出し、他のシステムのデータと組み合わせてからデータ主体に返すことができます。

削除応答の詳細

削除要求に対してはデータは返されません。要求が正常に処理されたことを示すステータスがデータプライバシー API に返されます。

お客様のデータに関するデータプライバシー処理のテスト

通常、Analytics をご利用のお客様は、一般公開される前にテストレポートスイートをいくつかセットアップして機能を確認します。実稼動レポートスイートに実際のトラフィックを送信する前に、実稼動前の Webサイトまたはアプリからこれらのテスト／開発／QA レポートスイートにデータを送信して、リリース後のコードの動作を評価します。

ただし、通常の設定では、実稼動レポートスイートに要求を適用する前にこれらのテストレポートスイートで GDPR 要求処理をテストすることはできません。これは、データプライバシー要求が Experience Cloud 組織内のすべてのレポートスイート（多くの場合、会社のすべてのレポートスイート）に自動的に適用されるからです。

それでも、すべてのレポートスイートに適用する前にデータプライバシー処理をテストできる方法がいくつかあります。

• 選択肢の 1 つは、テストレポートスイートのみが含まれる Experience Cloud 組織を別にセットアップすることです。次に、データプライバシーテストに対してこの Experience Cloud 組織を使用し、実際のデータプライバシー処理に対して通常の Experience Cloud 組織を使用します。

• もう 1 つの選択肢は、実稼動レポートスイートとは異なる名前空間をテストレポートスイートの ID に割り当てることです。

  例えば、テストレポートスイートでは、各名前空間に「qa-」というプレフィックスを付けることができます。qa プレフィックスの付いた名前空間のみを持つデータプライバシー要求を送信すると、それらの要求はテストレポートスイートに対してのみ実行されます。その後で、qa プレフィックスを付けずに要求を送信すると、それらの要求は実稼動レポートスイートに対して適用されます。これは、visitorId、AAID、ECID、customVisitorId のいずれの名前空間も使用していない場合に推奨される方法です。これらの名前空間はハードコードされており、テストレポートスイートで別の名前を付けることができないからです。