Real-time Customer Profileでのプライバシーリクエストの処理

Adobe Experience Platform Privacy Serviceは、EU一般データ保護規則(GDPR)やCalifornia Consumer Privacy Act (CCPA)などのプライバシー規制に基づき、自分の個人データに対するアクセス、販売のオプトアウト、削除の要求を処理します。

このドキュメントでは、Adobe Experience Platform内でのReal-time Customer Profileのプライバシーリクエストの処理に関する基本的な概念について説明します。

メモ

このガイドでは、Experience Platformのプロファイルデータストアに対してプライバシーリクエストを実行する方法についてのみ説明します。 Platformデータレイクに対してもプライバシーリクエストをおこなう予定がある場合は、このチュートリアルに加えて、データレイク🔗のプライバシーリクエストの処理に関するガイドを参照してください。

他のAdobe Experience Cloudアプリケーションにプライバシーリクエストを送信する手順については、Privacy Serviceのドキュメントを参照してください。

はじめに

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

  • Privacy Service ：Adobe Experience Cloud アプリケーションをまたいで、自身の個人データのアクセス、販売のオプトアウト、または削除に対する顧客リクエストを管理します。
  • Identity Service：デバイスやシステムをまたいで ID を結び付けることで、顧客体験のフラグメント化によって発生する基本的な課題を解決します。
  • Real-time Customer Profile：複数のソースからの集計データに基づいて、統合されたリアルタイムの顧客プロファイルを提供します。

ID 名前空間について

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

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

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

リクエストの送信

以下の節では、Privacy Service APIまたはUIを使用してReal-time Customer Profileのプライバシーリクエストをおこなう方法について説明します。 これらの節を読む前に、リクエストペイロードで送信されたPrivacy ServiceIDデータを適切に書式設定する方法など、プライバシーPrivacy Serviceの送信手順の詳細について、 ユーザーAPIまたはユーザーUIのドキュメントを確認することを強くお勧めします。

重要

Privacy Serviceは、IDステッチを実行しない結合ポリシーを使用してProfileデータのみを処理できます。 UIを使用してプライバシーリクエストが処理されているかどうかを確認する場合は、IDステッチタイプが「None」のポリシーを使用していることを確認します。 つまり、IDステッチが「プライベートグラフ」に設定されている結合ポリシーは使用できません。

また、プライバシーリクエストが完了するまでにかかる時間は保証できないことに注意する必要があります。 リクエストの処理中にProfileデータに変更が発生した場合は、それらのレコードが処理されるかどうかも保証できません。

API の使用

APIでジョブリクエストを作成する場合、userIDs内で提供されるIDは、特定のnamespaceとtypeを使用する必要があります。 Identity Serviceの値にはID名前空間を指定し、typeはstandardまたはunregistered（標準名前空間とカスタム名前空間のそれぞれ）を指定する必要があります。namespace

メモ

IDグラフと、プロファイルフラグメントをPlatformデータセットで配布する方法に応じて、各顧客に複数のIDを提供する必要が生じる場合があります。 詳しくは、次のプロファイルフラグメントを参照してください。

さらに、リクエストペイロードの include 配列には、リクエストがおこなわれる別のデータストアの製品値を含める必要があります。Data Lakeにリクエストを送信する場合、配列には「ProfileService」という値を含める必要があります。

次のリクエストは、Profileストア内の1人の顧客のデータに対して新しいプライバシージョブを作成します。 顧客に対してuserIDs配列で2つのID値が提供されます。1つは標準のEmail id名前空間を使用し、もう1つはカスタムのCustomer_ID名前空間を使用します。 Profile (ProfileService)の製品値もinclude配列に含まれます。

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}' \
  -H 'x-sandbox-name: {SANDBOX_NAME}' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "{IMS_ORG}"
      }
    ],
    "users": [
      {
        "key": "user12345",
        "action": ["access","delete"],
        "userIDs": [
          {
            "namespace": "Email",
            "value": "ajones@acme.com",
            "type": "standard"
          },
          {
            "namespace": "Customer_ID",
            "value": "12345678",
            "type": "unregistered"
          }
        ]
      }
    ],
    "include": ["ProfileService"],
    "expandIds": false,
    "priority": "normal",
    "regulation": "ccpa"
}'

UI の使用

UI でジョブリクエストを作成する場合は、「製品」の下の「AEP Data Lake」または「プロファイル」を必ず選択し、Data LakeまたはReal-time Customer Profileに保存されたデータのジョブを処理します。


プライバシーリクエストのプロファイルフラグメント

Profileデータストアでは、個々の顧客の個人データは、多くの場合、IDグラフを通じて個人に関連付けられた複数のプロファイルフラグメントで構成されます。 Profileストアにプライバシーリクエストを送信する場合、リクエストはプロファイル全体ではなく、プロファイルフラグメントレベルでのみ処理されることに注意する必要があります。

例えば、顧客属性データを3つの異なるデータセットに保存し、異なる識別子を使用して個々の顧客に関連付ける場合を考えてみましょう。

データセット名 プライマリIDフィールド 保存済み属性
データセット1 customer_id address
データセット2 email_id firstName、lastName
データセット3 email_id mlScore

データセットの1つは主識別子としてcustomer_idを使用し、他の2つはemail_idを使用します。 ユーザーID値にemail_idのみを使用してプライバシーリクエスト（アクセスまたは削除）を送信する場合、firstName、lastNameおよびmlScore属性のみが処理され、addressは影響を受けません。

プライバシーリクエストですべての関連する顧客属性を確実に処理するには、該当するすべてのデータセットのプライマリID値を指定する必要があります（1人の顧客につき最大9つのID）。 IDとして一般的にマークされるフィールドについて詳しくは、「スキーマ構成の基本」のIDフィールドに関する節を参照してください。

メモ

別のサンドボックスを使用してProfileデータを保存する場合は、x-sandbox-nameヘッダー内の適切なサンドボックス名を示す、各サンドボックスに対して個別のプライバシーリクエストを作成する必要があります。

リクエスト処理の削除

Experience Platform が Privacy Service から削除リクエストを受信すると、Platform は、Privacy Service に対し、リクエストを受信し、影響を受けるデータが削除用にマークされている旨の確認を送信します。プライバシージョブが完了すると、レコードはData LakeまたはProfileストアから削除されます。 削除ジョブが処理中の間、データはソフト削除されるので、Platformサービスからはアクセスできません。 ジョブステータスの追跡について詳しくは、Privacy Service ドキュメントを参照してください。

重要

削除リクエストが成功すると、顧客（または顧客のセット）の収集された属性データが削除されますが、このリクエストでは、IDグラフで確立された関連付けは削除されません。

例えば、顧客のemail_idとcustomer_idを使用する削除リクエストでは、これらのIDの下に保存されているすべての属性データが削除されます。 ただし、同じcustomer_idの下で取り込まれたデータは、関連付けがまだ存在するので、適切なemail_idに関連付けられます。

今後のリリースでは、データが物理的に削除された後、Platform は Privacy Service へと確認を送信します。

次の手順

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

Profileで使用されないPlatformリソースのプライバシーリクエストの処理について詳しくは、データレイク🔗のプライバシーリクエストの処理に関するドキュメントを参照してください。

このページ