資料湖中的隱私權請求處理
Adobe Experience Platform Privacy Service會根據法律和組織隱私權法規的規定,處理客戶存取、選擇退出銷售或刪除其個人資料的請求。
本檔案說明與處理儲存在Data Lake中之客戶資料的隱私權請求相關的重要概念。
快速入門
在閱讀本指南之前,建議您實際瞭解下列Experience Platform服務:
- Privacy Service:管理客戶透過Adobe Experience Cloud應用程式存取、選擇退出銷售或刪除其個人資料的請求。
- Catalog Service: Experience Platform內資料位置和歷程的記錄系統。 提供可用於更新資料集中繼資料的API。
- Experience Data Model (XDM) System: Experience Platform用來組織客戶體驗資料的標準化架構。
- Identity Service:透過跨裝置和系統橋接身分,解決客戶體驗資料分散所造成的根本挑戰。
了解身分命名空間 namespaces
Adobe Experience Platform Identity Service可跨系統和裝置橋接客戶身分資料。 Identity Service使用身分識別名稱空間,透過將身分識別值與其來源系統建立關聯來提供身分識別值的內容。 名稱空間可代表一般概念,例如電子郵件地址(「電子郵件」),或將身分與特定應用程式相關聯,例如Adobe Advertising Cloud ID (「AdCloud」)或Adobe Target ID (「TNTID」)。
Identity Service會維護全域定義(標準)和使用者定義(自訂)的身分名稱空間存放區。 標準名稱空間適用於所有組織(例如「Email」和「ECID」),而您的組織也可以建立自訂名稱空間以滿足其特定需求。
如需Experience Platform中識別名稱空間的詳細資訊,請參閱識別名稱空間概觀。
將身分資料新增至資料集
為Data Lake建立隱私權要求時,必須為每位客戶提供有效的身分值(及其關聯的名稱空間),以便找到其資料並據以處理。 因此,所有遵循隱私權要求的資料集都必須在其相關聯的XDM結構描述中包含身分描述項。
本節逐步說明將身分描述項新增至現有資料集的XDM結構描述的步驟。 如果您已經有具有身分描述項的資料集,您可以跳至下一節。
將身分描述項新增到資料集結構描述的方法有兩種:
使用UI identity-ui
在Experience Platform使用者介面中,方案 工作區可讓您編輯現有的XDM方案。 若要將身分描述項新增至結構描述,請從清單中選取結構描述,並按照Schema Editor教學課程中將結構描述欄位設定為身分欄位的步驟操作。
一旦您在結構描述中將適當的欄位設定為身分欄位後,您就可以繼續進行提交隱私權要求的下一節。
使用 API identity-api
您可以對Schema Registry API中的/descriptors
端點發出POST要求,藉此將身分描述項新增到資料集的XDM結構描述。
API格式
POST /descriptors
要求
以下請求在範例結構描述中的「電子郵件地址」欄位上定義身分描述項。
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
}'
@type
xdm:sourceSchema
xdm:sourceVersion
xdm:sourceSchema
中指定的XDM結構描述版本。xdm:sourceProperty
xdm:namespace
xdm:property
xdm:namespace
下使用的名稱空間。xdm:isPrimary
回應
成功的回應會傳回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向Data Lake提出隱私權請求。
使用UI
在UI中建立工作請求時,請務必在 產品 下選取 AEP資料湖,以便處理儲存在資料湖中的資料工作。
使用 API
在API中建立工作請求時,提供的任何userIDs
都必須根據其套用的資料存放區使用特定的namespace
和type
。 資料湖的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": "unregistered"
},
{
"namespace": "email_label",
"value": "jdoe@example.com",
"type": "unregistered"
}
]
}
],
"include": ["aepDataLake"],
"expandIds": false,
"priority": "normal",
"regulation": "ccpa"
}'
x-sandbox-name
標頭都會被系統忽略。正在處理刪除請求
當Experience Platform收到來自Privacy Service的刪除請求時,Platform會傳送確認給Privacy Service,確認已收到該請求且受影響的資料已標示為刪除。 這些記錄接著會在七天內從資料湖中移除。 在這七天期間,資料會軟刪除,因此無法由任何Platform服務存取。
如果您也將ProfileService
或identity
包含在隱私權請求中,則會分別處理其相關資料。 如需詳細資訊,請參閱有關設定檔🔗的刪除請求處理的章節。
後續步驟
閱讀本檔案後,您便可瞭解處理Data Lake隱私權請求的重要概念。 建議您繼續閱讀本指南提供的檔案,以加深您對如何管理身分資料和建立隱私權工作的瞭解。
如需處理Profile存放區之隱私權要求的步驟,請參閱即時客戶設定檔🔗的隱私權要求處理檔案。
附錄
下節包含在Data Lake中處理隱私權請求的其他資訊。
標籤巢狀對應型別欄位 nested-maps
請務必注意,有兩種巢狀對應型別欄位不支援隱私權標籤:
- 陣列型別欄位中的對應型別欄位
- 另一個對應型別欄位中的對應型別欄位
上述兩個範例的隱私權工作處理最終都將失敗。 因此,建議您避免使用巢狀對應型別欄位來儲存私人客戶資料。 對於以記錄為基礎的資料集,相關的消費者ID應該以非對應資料型別的形式儲存在identityMap
欄位中(本身是對應型別欄位),或是以時間序列為基礎的資料集的endUserID
欄位中。