Real-Time Customer Profile でのプライバシーリクエストの処理
Adobe Experience Platform Privacy Service は、EU 一般データ保護規則(GDPR)や California Consumer Privacy Act(CCPA)などのプライバシー規制に従って、個人データへのアクセス、販売のオプトアウト、または削除を求める顧客のリクエストを処理します。
このドキュメントでは、Adobe Experience Platform における Real-Time Customer Profile のプライバシーリクエスト処理に関する基本的な概念について説明します。
はじめに
このガイドでは、次の 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 ServiceAPI または Privacy ServiceUI のドキュメントを確認するか、注意する必要があります。 これらのドキュメントは、リクエストペイロードで送信されたユーザー ID データの形式を適切に設定する方法など、プライバシージョブの送信方法に関する完全な手順を提供します。
削除要求時に Platform またはプロファイルサービスから受信するデータを認識するのは、お客様の責任です。このデータはレコードストアに挿入されるからです。 削除中または削除中のデータの取り込みに注意する必要があります。
API の使用
API でジョブリクエストを作成する際は、userIDs
内で指定するいずれの ID に対しても固有の namespace
および type
を使用する必要があります。Identity Service によって認識される有効な ID 名前空間 を namespace
値に指定する必要があり、type
には、standard
または unregistered
のいずれかを(標準名前空間とカスタム名前空間のそれぞれに応じて)指定する必要があります。
さらに、リクエストペイロードの include
配列には、リクエスト対象である別のデータストアの製品値を含める必要があります。ID に関連付けられたプロファイルデータを削除するには、配列に値 ProfileService
を含める必要があります。 顧客の ID グラフの関連付けを削除するには、配列に値 identity
を含める必要があります。
include
配列内で ProfileService
と identity
を使用した場合の影響について詳しくは、このドキュメントの後半の プロファイルリクエストと ID リクエストに関する節を参照してください。次のリクエストは、1 件の顧客データ用の新しいプライバシージョブを Profile ストアに作成します。 顧客の userIDs
配列には、2 つの ID 値が指定されています。1 つは標準の Email
ID 名前空間、もう 1 つはカスタム Customer_ID
名前空間を使用します。 また、include
の配列に Profile (ProfileService
)の製品値も含まれます。
リクエスト
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 または プロファイル を必ず選択し、それぞれ データレイクまたは Real-Time Customer Profile に保存されたデータのジョブを処理します。
プライバシーリクエストのプロファイルフラグメント fragments
Profile データストアでは、個々の顧客の個人データは、多くの場合、複数のプロファイルフラグメントで構成され、ID グラフを通じて人物に関連付けられます。 Profile ストアに対してプライバシーリクエストを行う場合、リクエストは、プロファイル全体ではなく、プロファイルフラグメントレベルでのみ処理されることに注意してください。
例えば、顧客属性データを 3 つの異なるデータセットに格納し、それらのデータセットで異なる識別子を使用してデータを個々の顧客に関連付ける場合を考えてみましょう。
customer_id
address
email_id
firstName
、lastName
email_id
mlScore
データセットの 1 つはプライマリ識別子として customer_id
を使用し、他の 2 つは email_id
を使用します。 ユーザー ID 値として email_id
のみを使用してプライバシーリクエスト(アクセスまたは削除)を送信した場合、firstName
、lastName
、mlScore
属性のみが処理され、address
は影響を受けません。
プライバシーリクエストがすべての関連する顧客属性を処理するようにするには、これらの属性を保存できるすべての適用可能なデータセットにプライマリ ID 値を指定する必要があります(顧客あたり最大 9 つの ID)。 ID として一般的にマークされるフィールドについて詳しくは、 スキーマ構成の基本の ID フィールドに関する節を参照してください。
リクエスト処理の削除 delete
Experience Platform が Privacy Service から削除リクエストを受信すると、Platform は、Privacy Service に対し、リクエストを受信し、影響を受けるデータが削除用にマークされている旨の確認を送信します。その後、プライバシージョブが完了すると、レコードが削除されます。
プロファイル (ProfileService
)のプライバシーリクエストに製品として ID サービス (identity
)とデータレイク (aepDataLake
)も含めたかどうかに応じて、プロファイルに関連する様々なデータセットが、場合によっては異なる時間にシステムから削除されます。
ProfileService
のみProfileService
および identity
ProfileService
および aepDataLake
データレイク製品がリクエストを受信し、現在処理中であることを応答すると、プロファイルに関連付けられたデータはソフト削除されるので、Platform サービスからアクセスできません。 ジョブが完了すると、データはデータレイクから完全に削除されます。
ProfileService
、identity
および aepDataLake
データレイク製品がリクエストを受信し、現在処理中であることを応答すると、プロファイルに関連付けられたデータはソフト削除されるので、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 を使用してプライバシーリクエストが処理されているかどうかを確認する場合は、ID ステッチ タイプとして None を持つポリシーを使用していることを確認してください。 つまり、ID ステッチ が プライベートグラフ に設定されている結合ポリシーは使用できません。
次の手順
このドキュメントでは、Experience Platform におけるプライバシーリクエストの処理に関する重要な概念について説明します。ID データの管理方法とプライバシージョブの作成方法に関する理解を深めるには、引き続きこのガイドに記載されているドキュメントを参照してください。
Profile で使用されない Platform リソースのプライバシーリクエストの処理について詳しくは、 データレイクでのプライバシーリクエストの処理のドキュメントを参照してください。