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 コンポーネントに関する十分な知識が必要です。
- Privacy Service :Adobe Experience Cloud アプリケーションをまたいで、自身の個人データのアクセス、販売のオプトアウト、または削除に対する顧客リクエストを管理します。
- Identity Service:デバイスやシステムをまたいで ID を結び付けることで、顧客体験データの断片化によって発生する根本的な課題を解決します。
- Real-Time Customer Profile:複数のソースからの集計データに基づいて、統合されたリアルタイムの顧客プロファイルを提供します。
ID 名前空間について namespaces
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 名前空間の概要を参照してください。
リクエストの送信 submit
以下のセクションでは、Privacy Service の API または UI を使用して Real-Time Customer Profile に対しプライバシーリクエストを行う方法について概説しています。これらのセクションを読む前に、Privacy Service API または Privacy Service UI のドキュメントを確認するか認識しておく必要があります。 これらのドキュメントは、リクエストペイロードで送信されたユーザー ID データの形式を適切に設定する方法など、プライバシージョブの送信方法に関する完全な手順を提供します。
お客様は、削除依頼の際にExperience Platformまたはプロファイルサービスから受信するデータを把握する責任を負います。このデータは、お客様のレコードストアに挿入されるからです。 削除中または削除中のデータの取り込みに注意する必要があります。
API の使用
API でジョブリクエストを作成する際は、userIDs 内で指定するいずれの ID に対しても固有の namespace および type を使用する必要があります。ID サービスによって認識される有効な ID 名前空間 を名前空間値に指定する必要があります。 標準名前空間には standard を使用し、カスタム名前空間には custom を使用します。
さらに、リクエストペイロードの include 配列には、リクエスト対象である別のデータストアの製品値を含める必要があります。ID に関連付けられたプロファイルデータを削除するには、配列に値 ProfileService を含める必要があります。 顧客の ID グラフの関連付けを削除するには、配列に値 identity を含める必要があります。
ProfileService を使用した場合の影響について詳しくは、このドキュメントの後半の identity プロファイルリクエストと ID リクエスト include に関する節を参照してください。次のリクエストは、1 件の顧客データ用の新しいプライバシージョブを Profile ストアに作成します。 顧客の 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 '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",
"value": "ajones@acme.com",
"type": "standard"
},
{
"namespace": "Customer_ID",
"value": "12345678",
"type": "unregistered"
}
]
}
],
"include": ["ProfileService","identity"],
"expandIds": false,
"priority": "normal",
"regulation": "ccpa"
}'
x-sandbox-name ヘッダーはシステムによって無視されます。製品の反応
プロファイルサービスの場合、プライバシージョブが完了すると、要求されたユーザー ID に関する情報を含んだ応答が JSON 形式で返されます。
{
"privacyResponse": {
"jobId": "7467850f-9698-11ed-8635-355435552164",
"response": [
{
"sandbox": "prod",
"mergePolicyId": "none",
"result": {
"person": {
"gender": "female"
},
"personalEmail": {
"address": "ajones@acme.com",
},
"identityMap": {
"crmid": [
{
"id": "5b7db37a-bc7a-46a2-a63e-2cfe7e1cc068"
}
]
}
}
},
{
"sandbox": "prod",
"mergePolicyId": "none",
"result": {
"person": {
"gender": "male"
},
"id": 12345678,
"identityMap": {
"crmid": [
{
"id": "e9d439f2-f5e4-4790-ad67-b13dbd89d52e"
}
]
}
}
}
]
}
}
UI の使用
UI でジョブリクエストを作成する場合は、AEP Data Lake の下の Profile や Products を必ず選択し、データレイクまたは Real-Time Customer Profile に保存されたデータのジョブを処理します。
プライバシーリクエストのプロファイルフラグメント fragments
Profile データストアでは、個々の顧客の個人データは、多くの場合、複数のプロファイルフラグメントで構成され、ID グラフを通じて人物に関連付けられます。 Profile ストアに対してプライバシーリクエストを行う場合、リクエストは、プロファイル全体ではなく、プロファイルフラグメントレベルでのみ処理されることに注意してください。
例えば、顧客属性データを 3 つの異なるデータセットに格納し、それらのデータセットで異なる識別子を使用してデータを個々の顧客に関連付ける場合を考えてみましょう。
customer_idaddressemail_idfirstName, lastNameemail_idmlScoreデータセットの 1 つはプライマリ識別子として customer_id を使用し、他の 2 つは email_id を使用します。 ユーザー ID 値として email_id のみを使用してプライバシーリクエスト(アクセスまたは削除)を送信した場合、firstName、lastName、mlScore 属性のみが処理され、address は影響を受けません。
プライバシーリクエストがすべての関連する顧客属性を処理するようにするには、これらの属性を保存できるすべての適用可能なデータセットにプライマリ ID 値を指定する必要があります(顧客あたり最大 9 つの ID)。 ID として一般的にマークされるフィールドについて詳しくは、 スキーマ構成の基本 の ID フィールドに関する節を参照してください。
リクエスト処理の削除 delete
Experience Platform が Privacy Service から削除リクエストを受信すると、Experience Platform は、Privacy Service に対し、リクエストを受信し、影響を受けるデータが削除用にマークされている旨の確認を送信します。その後、プライバシージョブが完了すると、レコードが削除されます。
プロファイル (identity)のプライバシーリクエストに製品として ID サービス (aepDataLake)とデータレイク (ProfileService)も含めたかどうかに応じて、プロファイルに関連する様々なデータセットが、場合によっては異なる時間にシステムから削除されます。
ProfileService のみProfileService および identityProfileService および aepDataLakeデータレイク製品がリクエストを受信し、現在処理中であることを応答すると、プロファイルに関連付けられたデータはソフト削除されるので、Experience Platform サービスからアクセスできません。 ジョブが完了すると、データはデータレイクから完全に削除されます。
ProfileService、identity および aepDataLakeデータレイク製品がリクエストを受信し、現在処理中であることを応答すると、プロファイルに関連付けられたデータはソフト削除されるので、Experience Platform サービスからアクセスできません。 ジョブが完了すると、データはデータレイクから完全に削除されます。
ジョブステータスのトラッキングについて詳しくは、Privacy Service ドキュメント を参照してください。
プロファイルリクエストと ID リクエスト profile-v-identity
プロファイル(ProfileService)に対して削除リクエストが行われたが、ID サービス(identity)に対して削除リクエストが行われなかった場合、生成されるジョブでは、顧客(または一連の顧客)について収集された属性データは削除されますが、ID グラフで確立された関連付けは削除されません。
例えば、顧客の ID を使用する削除リクエストで、それらの email_id に保存されてい customer_id すべての属性データを削除するとします。 ただし、その後、同じ customer_id で取り込まれたデータは、関連付けがまだ存在するので、引き続き適切な email_id に関連付けられます。
特定の顧客のプロファイルとすべての ID の関連付けを削除するには、必ずプロファイルと ID サービスの両方を削除リクエストのターゲット製品として含めてください。
結合ポリシーの制限 merge-policy-limitations
Privacy Serviceは、ID ステッチを実行しない結合ポリシーを使用してのみ Profile データを処理できます。 UI を使用してプライバシーリクエストが処理されているかどうかを確認する場合は、None を ID stitching タイプとして使用するポリシーを使用していることを確認してください。 つまり、ID stitching が Private graph に設定されている結合ポリシーは使用できません。
次の手順
このドキュメントでは、Experience Platform におけるプライバシーリクエストの処理に関する重要な概念について説明します。ID データの管理方法とプライバシージョブの作成方法に関する理解を深めるには、引き続きこのガイドに記載されているドキュメントを参照してください。
Experience Platform で使用されない Profile リソースのプライバシーリクエストの処理について詳しくは、 データレイクでのプライバシーリクエストの処理 のドキュメントを参照してください。