Behandling av förfrågningar om skydd av privatlivet i datasjön
Adobe Experience Platform Privacy Service bearbetar kundförfrågningar om åtkomst, avanmälan från försäljning eller radering av deras personuppgifter enligt juridiska och organisatoriska sekretessbestämmelser.
Det här dokumentet innehåller viktiga begrepp som rör behandling av sekretessförfrågningar för kunddata som lagras i datasjön.
Komma igång
Vi rekommenderar att du har en fungerande förståelse för följande Experience Platform-tjänster innan du läser den här handboken:
- Privacy Service: Hanterar kundförfrågningar om åtkomst, avanmälan från försäljning eller borttagning av deras personuppgifter mellan Adobe Experience Cloud-program.
- Catalog Service: Postsystemet för dataplats och datalinje inom Experience Platform. Tillhandahåller ett API som kan användas för att uppdatera datauppsättningsmetadata.
- Experience Data Model (XDM) System: Det standardiserade ramverket som Experience Platform organiserar kundupplevelsedata med.
- Identity Service: Lös den grundläggande utmaning som fragmenteringen av kundupplevelsedata innebär genom att överbrygga identiteter mellan enheter och system.
Identitetsnamnutrymmen namespaces
Adobe Experience Platform Identity Service förenar data för kundidentitet mellan system och enheter. Identity Service använder identitetsnamnutrymmen för att ge kontext till identitetsvärden genom att koppla dem till deras ursprungssystem. Ett namnutrymme kan representera ett allmänt koncept, t.ex. en e-postadress ("E-post") eller associera identiteten med ett visst program, t.ex. ett Adobe Advertising Cloud-id ("AdCloud") eller ett Adobe Target-id ("TNTID").
Identity Service underhåller ett lager med globalt definierade (standard) och användardefinierade (anpassade) identitetsnamnutrymmen. Standardnamnutrymmen är tillgängliga för alla organisationer (till exempel"E-post" och"ECID"), medan din organisation också kan skapa anpassade namnutrymmen som passar organisationens behov.
Mer information om identitetsnamnutrymmen i Experience Platform finns i översikten över identitetsnamnrymden.
Lägga till identitetsdata i datauppsättningar
När du skapar sekretessförfrågningar för datasjön måste giltiga identitetsvärden (och tillhörande namnutrymmen) anges för varje enskild kund för att deras data ska kunna hittas och bearbetas därefter. Därför måste alla datauppsättningar som omfattas av sekretessförfrågningar innehålla en identitetsbeskrivning i det associerade XDM-schemat.
I det här avsnittet går vi igenom stegen för att lägga till en identitetsbeskrivare i ett befintligt datamängds XDM-schema. Om du redan har en datauppsättning med en identitetsbeskrivning kan du hoppa fram till nästa avsnitt.
Det finns två metoder för att lägga till en identitetsbeskrivning i ett dataset-schema:
Använda gränssnittet identity-ui
I Experience Platformanvändargränssnittet kan du redigera befintliga XDM-scheman med arbetsytan i Schemas. Om du vill lägga till en identitetsbeskrivning till ett schema väljer du schemat från listan och följer stegen för att ange ett schemafält som ett identitetsfält i självstudiekursen Schema Editor.
När du har angett rätt fält i schemat som identitetsfält kan du fortsätta till nästa avsnitt om att skicka sekretessförfrågningar.
Använda API:et identity-api
schemaRef.id
{TENANT_ID}
och konceptet med behållare, finns i avsnittet Komma igång i API-handboken.Du kan lägga till en identitetsbeskrivning i en datamängds XDM-schema genom att göra en POST-förfrågan till /descriptors
-slutpunkten i Schema Registry API.
API-format
POST /descriptors
Begäran
Följande begäran definierar en identitetsbeskrivning i ett e-postadressfält i ett exempelschema.
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:sourceProperty
xdm:namespace
xdm:property
xdm:namespace
.xdm:isPrimary
Svar
Ett lyckat svar returnerar HTTP-status 201 (Skapad) och information om den nyskapade beskrivningen.
{
"@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"
}
Skicka begäranden submit
I följande avsnitt beskrivs hur du gör sekretessförfrågningar för datasjön med hjälp av användargränssnittet eller API:t Privacy Service.
Använda gränssnittet
När du skapar jobbbegäranden i användargränssnittet måste du markera AEP Data Lake under Products för att kunna bearbeta jobb för data som lagras i datasjön.
Använda API:et
När du skapar jobbförfrågningar i API:t måste alla userIDs
som anges använda en specifik namespace
och type
beroende på vilket datalager de gäller för. ID:n för datasjön måste använda unregistered
för sitt type
-värde och ett namespace
-värde som matchar en av de sekretessetiketter som har lagts till i tillämpliga datamängder.
Dessutom måste matrisen include
för nyttolasten för begäran innehålla produktvärden för de olika datalager som begäran görs till. När du gör förfrågningar till datasjön måste matrisen innehålla värdet aepDataLake
.
Följande begäran skapar ett nytt sekretessjobb för datasjön med det oregistrerade namnområdet email_label
. Den innehåller också produktvärdet för datasjön i arrayen 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
-huvuden som ingår i begäran av systemet.Ta bort bearbetning av begäran
När Experience Platform tar emot en borttagningsbegäran från Privacy Service, skickar Platform en bekräftelse till Privacy Service om att begäran har tagits emot och att data som påverkas har markerats för borttagning. Registren tas sedan bort från sjön inom sju dagar. Under det sju dagar långa fönstret tas data bort utan att vara tillgängliga för någon Platform-tjänst.
Om du även inkluderade ProfileService
eller identity
i sekretessbegäran hanteras deras associerade data separat. Mer information finns i avsnittet Ta bort begärandebearbetning för profilen.
Nästa steg
Genom att läsa det här dokumentet har du lagts till i de viktiga koncept som rör behandling av sekretessförfrågningar för datasjön. Vi rekommenderar att du fortsätter att läsa dokumentationen som finns i den här handboken för att få en djupare förståelse för hur du hanterar identitetsdata och skapar sekretessjobb.
I dokumentet om behandling av sekretessförfrågningar för kundprofil i realtid finns anvisningar om hur du hanterar sekretessförfrågningar för butiken Profile.
Bilaga
Följande avsnitt innehåller ytterligare information för att behandla sekretessförfrågningar i datasjön.
Märka kapslade mappningsfält nested-maps
Det är viktigt att komma ihåg att det finns två typer av kapslade mappningsfält som inte har stöd för sekretessetiketter:
- Ett mappningsfält i ett matristypsfält
- Ett mappningsfält i ett annat mappningsfält
Bearbetning av sekretessjobb för något av de två exemplen ovan kommer så småningom att misslyckas. Därför rekommenderar vi att du undviker att använda kapslade mappningsfält för att lagra privata kunddata. Relevanta konsument-ID:n ska lagras som en datatyp som inte är mappad i fältet identityMap
(i sig ett mappningsfält) för postbaserade datamängder, eller i fältet endUserID
för tidsseriebaserade datamängder.