プライバシーリクエストの処理( Data Lake

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

This document covers essential concepts related to processing privacy requests for customer data stored in the Data Lake.

はじめに

It is recommended that you have a working understanding of the following Experience Platform services before reading this guide:

  • Privacy Service :Adobe Experience Cloud アプリケーションをまたいで、自身の個人データのアクセス、販売のオプトアウト、または削除に対する顧客リクエストを管理します。
  • Catalog Service:データの場所と内の系列のレコードのシステム Experience Platform。 データセットメタデータの更新に使用できる API を提供します。
  • Experience Data Model (XDM) System:顧客体験データを Experience Platform 整理する際に使用される標準化されたフレームワーク。
  • Identity Service:デバイスやシステム間でIDをブリッジ化することによって顧客体験データを断片化することによって生じる基本的な課題を解決します。

ID 名前空間について

Adobe Experience Platform Identity Service bridges customer identity data across systems and devices. Identity Service identity名前空間を使用して、identity値を接触チャネルのシステムに関連付けることで、identity値のコンテキストを提供します。 名前空間では、電子メールアドレス(「電子メール」)などの汎用概念を表したり、ID を特定のアプリケーションに関連付けたりすることができます(Adobe Advertising Cloud ID(「AdCloud」)、Adobe Target ID(「TNTID」)など)。

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

For more information about identity namespaces in Experience Platform, see the identity namespace overview.

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

のプライバシーリクエストを作成する場合 Data Lake、データを見つけて処理するために、有効なID値(および関連する名前空間)を各顧客に提供する必要があります。 したがって、プライバシー要求の対象となるすべてのデータセットには、関連するXDMスキーマにID記述子が含まれている必要があります。

NOTE

現在、ID記述子メタデータ(アドホックデータセットなど)をサポートしないスキーマに基づくデータセットは、プライバシー要求で処理できません。

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

IMPORTANT

IDとして設定するスキーマフィールドを決定する場合は、入れ子のマップタイプフィールドを使用する 制限事項に注意してください

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

UI の使用

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

スキーマ内の適切なフィールドをIDフィールドとして設定したら、次のセクションに進んで、プライバシー 要求の送信に関するセクション

API の使用

NOTE

この節では、データセットのXDMスキーマの固有のURI ID値を把握していることを前提としています。 この値がわからない場合は、 Catalog Service APIを使用して取得できます。 開発者ガイドの「 はじめに 」の節を読んだら、に示す 手順に従って 一覧表示するか Catalog 、データセットを見つけるオブジェクトを調べます。 スキーマIDは、 schemaRef.id

この節には、スキーマレジストリAPIの呼び出しが含まれます。 APIの使用に関する重要な情報(コンテナの概念や概念を把握する {TENANT_ID} など)については、開発者ガイドの はじめに (英語のみ)の節を参照してください。

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

API 形式

POST /descriptors

リクエスト

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

curl -X POST \
  https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {IMS_ORG}' \
  -H 'x-sandbox-name: {SANDBOX_NAME}' \
  -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
      }'
プロパティ 説明
@type 作成する記述子の型です。 ID記述子の場合、値は"xdm:descriptorIdentity"にする必要があります。
xdm:sourceSchema データセットのXDMスキーマの一意のURI ID。
xdm:sourceVersion で指定されているXDMスキーマのバージョンで xdm:sourceSchemaす。
xdm:sourceProperty 記述子を適用するスキーマフィールドへのパス。
xdm:namespace が認識する 標準ID名前空間 、 Privacy Serviceまたは組織が定義するカスタム名前空間の1つ。
xdm:property で使用される名前空間に応じて、「xdm:id」または「xdm:code」のいずれか xdm:namespace
xdm:isPrimary オプションのブール値。trueの場合は、フィールドが主IDであることを示します。 スキーマには、1 つのプライマリ ID のみを含めることができます。含めない場合のデフォルトは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"
}

リクエストの送信

NOTE

This section covers how to format privacy requests for the Data Lake. It is strongly recommended that you review the Privacy Service UI or Privacy Service API documentation for complete steps on how to submit a privacy job, including how to properly format submitted user identity data in request payloads.

次の節では、 Data LakePrivacy Service UIまたはAPIを使用してプライバシーをリクエストする方法について概説します。

IMPORTANT

プライバシー要求が完了するまでに要する時間を保証することはできません。 要求の処理中にデータレーク内で変更が発生した場合、それらのレコードが処理されるかどうかも保証できません。

UI の使用

When creating job requests in the UI, be sure to select AEP Data Lake and/or Profile under Products in order to process jobs for data stored in the Data Lake or Real-time Customer Profile, respectively.


API の使用

API でジョブリクエストを作成する場合、提供されるすべての userIDs は、適用するデータストアに応じて、特定の namespacetype を使用する必要があります。IDs for the Data Lake must use "unregistered" for their type value, and a namespace value that matches one the privacy labels that have been added to applicable datasets.

さらに、リクエストペイロードの include 配列には、リクエストがおこなわれる別のデータストアの製品値を含める必要があります。When making requests to the Data Lake, the array must include the value aepDataLake.

The following request creates a new privacy job for the Data Lake, using the unregistered "email_label" namespace. It also includes the product value for the Data Lake in the include array:

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

リクエスト処理の削除

When Experience Platform receives a delete request from Privacy Service, Platform sends confirmation to Privacy Service that the request has been received and affected data has been marked for deletion. The records are then removed from the Data Lake within seven days. During that seven-day window, the data is soft-deleted and is therefore not accessible by any Platform service.

In future releases, Platform will send confirmation to Privacy Service after data has been physically deleted.

次の手順

By reading this document, you have been introduced to the important concepts involved with processing privacy requests for the Data Lake. ID データの管理方法とプライバシージョブの作成方法に関する理解を深めるために、引き続きこのガイド全体に記載されているドキュメントを読むことをお勧めします。

See the document on privacy request processing for Real-time Customer Profile for steps on processing privacy requests for the Profile store.

付録

次の節では、のプライバシー要求を処理するための追加情報について説明し Data Lakeます。

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

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

  • 配列型フィールド内のマップタイプフィールド
  • 別のマップタイプフィールド内のマップタイプフィールド

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

このページ