データレイクでのプライバシーリクエスト処理

Adobe Experience Platform Privacy Service は、法的および組織のプライバシーに関する規則に従って、個人データに対するアクセス、販売のオプトアウト、または削除を求める顧客のリクエストを処理します。

このドキュメントでは、データレイクに保存された顧客データに対するプライバシーリクエストの処理に関連する基本概念について説明します。

はじめに

このガイドを読む前に、次の Experience Platform サービスに関する十分な理解を得ることをお勧めします。

ID 名前空間について namespaces

Adobe Experience Platform Identity Service は、システムやデバイスをまたいで顧客 ID データを結び付けます。Identity Service は ID 名前空間を使用して、ID の値を元のシステムと関連付け、それらの値に対するコンテキストを提供します。名前空間は、電子メールアドレス（「電子メール」）などの一般的な概念を表したり、IDをAdobe Advertising IDやAdobe Target IDなどの特定のアプリケーションに関連付けたりできます。

Identity Service は、グローバルに定義された（標準）ID およびユーザー定義の（カスタム）ID 名前空間を保持します。標準の名前空間はすべての組織（「電子メール」や「ECID」など）で使用できますが、組織は、特定のニーズに合わせてカスタム名前空間を作成することもできます。

Experience Platform の ID 名前空間について詳しくは、 ID 名前空間の概要を参照してください。

ID データをデータセットに追加

データレイクのプライバシーリクエストを作成する場合、個々の顧客がデータを検索して適切に処理できるように、有効なID値（および関連する名前空間）を各顧客に提供する必要があります。 したがって、プライバシーリクエストの対象となるすべてのデータセットには、関連する XDM スキーマに ID 記述子が含まれている必要があります。

この節では、既存のデータセットの XDM スキーマに ID 記述子を追加する手順を説明します。ID 記述子を持つデータセットが既に存在する場合は、次の節に進みます。

データセットスキーマに ID 記述子を追加するには、次の 2 つの方法があります。

UI の使用 identity-ui

Experience Platform ユーザーインターフェイスの​Schemas ワークスペースでは、既存のXDM スキーマを編集できます。 スキーマに ID 記述子を追加するには、リストからスキーマを選択し、Schema Editor チュートリアルのID フィールドとしてスキーマフィールドを設定するの手順に従います。

スキーマ内の適切なフィールドを ID フィールドとして設定したら、プライバシーリクエストの送信に関する次の節に進むことができます。

API の使用 identity-api

Schema Registry API の /descriptors エンドポイントに POST リクエストをおこなうことで、データセットの XDM スキーマに ID 記述子を追加できます。

API 形式

POST /descriptors

リクエスト

次のリクエストでは、スキーマ例の「email address」フィールドに ID 記述子を定義します。

curl -X POST \
  https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {ORG_ID}' \
  -H 'x-sandbox-name: {SANDBOX_NAME}' \
  -H 'Content-Type: application/json' \
  -d '
      {
        "@type": "xdm:descriptorIdentity",
        "xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
        "xdm:sourceVersion": 1,
        "xdm:sourceProperty": "/personalEmail/address",
        "xdm:namespace": "Email",
        "xdm:property": "xdm:code",
        "xdm:isPrimary": false
      }'

応答

応答が成功すると、HTTP ステータス 201（作成済み）と、新しく作成された記述子の詳細が返されます。

{
  "@type": "xdm:descriptorIdentity",
  "xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
  "xdm:sourceVersion": 1,
  "xdm:sourceProperty": "/personalEmail/address",
  "xdm:namespace": "Email",
  "xdm:property": "xdm:code",
  "xdm:isPrimary": false,
  "meta:containerId": "tenant",
  "@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}

リクエストの送信 submit

次の節では、Privacy Service UIまたはAPIを使用して、データレイクに対してプライバシーリクエストを行う方法の概要を説明します。

UI の使用

UIでジョブリクエストを作成する場合は、データレイクに保存されているデータのジョブを処理するために、AEP Data Lake​の下の​ Products ​を選択してください。

API の使用

API でジョブリクエストを作成する場合、提供されるすべての userIDs は、適用するデータストアに応じて、特定の namespace と type を使用する必要があります。ID サービスで認識される有効なID名前空間を、名前空間値に指定する必要があります。 標準の名前空間にはstandardを使用し、カスタム名前空間にはcustomを使用します。

データレイクのIDは、そのunregistered値にtypeを使用し、該当するデータセットに追加されたnamespace プライバシーラベル のいずれかに一致する値を使用する必要があります。

さらに、リクエストペイロードの include 配列には、リクエスト対象である別のデータストアの製品値を含める必要があります。データレイクにリクエストを行う場合、配列に値aepDataLakeを含める必要があります。

次のリクエストは、未登録のemail_label名前空間を使用して、データレイクの新しいプライバシージョブを作成します。 また、include配列のデータレイクの製品値も含まれます。

curl -X POST \
  https://platform.adobe.io/data/core/privacy/jobs \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {ORG_ID}' \
  -H 'Content-Type: application/json' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "{ORG_ID}"
      }
    ],
    "users": [
      {
        "key": "user12345",
        "action": ["access","delete"],
        "userIDs": [
          {
            "namespace": "email_label",
            "value": "ajones@acme.com",
            "type": "custom"
          },
          {
            "namespace": "email_label",
            "value": "jdoe@example.com",
            "type": "custom"
          }
        ]
      }
    ],
    "include": ["aepDataLake"],
    "expandIds": false,
    "priority": "normal",
    "regulation": "ccpa"
}'

リクエスト処理の削除

Experience Platform が Privacy Service から削除リクエストを受信すると、Experience Platform は、Privacy Service に対し、リクエストを受信し、影響を受けるデータが削除用にマークされている旨の確認を送信します。レコードは7日以内にデータレイクから削除されます。 この 7 日間の期間中、データはソフト削除されるので、どの Experience Platform サービスからもアクセスできません。

プライバシーリクエストにProfileServiceまたはidentityも含めた場合、関連するデータは個別に処理されます。 詳しくは、​ プロファイル ​の削除要求処理の節を参照してください。

次の手順

このドキュメントでは、データレイクのプライバシーリクエストの処理に関する重要な概念について説明します。 ID データの管理方法とプライバシージョブの作成方法に関する理解を深めるために、引き続きこのガイド全体に記載されているドキュメントを読むことをお勧めします。

​ ストアのプライバシー要求を処理する手順については、 リアルタイム顧客プロファイルのプライバシー要求の処理Profileに関するドキュメントを参照してください。

付録

次の節では、データレイクでプライバシーリクエストを処理するための追加情報を示します。

ネストされたマップタイプフィールドのラベル付け nested-maps

プライバシーのラベル付けをサポートしないネストされたマップタイプフィールドは、次の 2 種類あります。

上記の 2 つの例のいずれのプライバシージョブの処理も、最終的に失敗します。このため、顧客のプライベートデータを保存する際に、ネストされたマップタイプフィールドを使用しないようにすることをお勧めします。関連する消費者 ID は、レコードベースのデータセットの場合は identityMap フィールド（自身はマップタイプのフィールド）内の非マップデータ型、時系列ベースのデータセットの場合は endUserID フィールドとして保存する必要があります。