Behandling av sekretessförfrågningar i Real-time Customer Profile

Adobe Experience Platform Privacy Service behandlar kundförfrågningar om tillgång, avanmälan från försäljning eller radering av personuppgifter enligt sekretessbestämmelser såsom den allmänna dataskyddsförordningen (GDPR), och California Consumer Privacy Act (CCPA).

Det här dokumentet innehåller viktiga begrepp som rör behandling av sekretessförfrågningar för Real-time Customer Profile inom Adobe Experience Platform.

OBSERVERA

Den här handboken beskriver bara hur du gör sekretessförfrågningar för datalagret Profil i Experience Platform. Om du även planerar att göra sekretessförfrågningar för Platform Data Lake, se guiden på behandling av sekretessförfrågningar i Data Lake förutom den här självstudiekursen.

Anvisningar om hur du gör sekretessförfrågningar för andra Adobe Experience Cloud-program finns i Privacy Service.

Komma igång

Vi rekommenderar att du har en fungerande förståelse för följande Experience Platform innan du läser den här guiden:

  • Privacy Service: Hanterar kundförfrågningar om åtkomst, avanmälan eller radering av personuppgifter mellan olika Adobe Experience Cloud-program.
  • Identity Service: Lös den grundläggande utmaning som fragmenteringen av kundupplevelsedata innebär genom att överbrygga identiteter mellan olika enheter och system.
  • Real-time Customer Profile: Ger en enhetlig konsumentprofil i realtid baserad på aggregerade data från flera källor.

Identitetsnamnutrymmen

Adobe Experience Platform Identity Service överbryggar kundidentitetsdata mellan system och enheter. Identity Service använder identitetsnamnutrymmen för att tillhandahålla sammanhang 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").

Identitetstjänsten underhåller ett arkiv 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, se Översikt över namnutrymmet identity.

Skicka begäranden

Avsnitten nedan beskriver hur du gör sekretessförfrågningar för Real-time Customer Profile med Privacy Service API eller gränssnitt. Innan du läser dessa avsnitt bör du granska Privacy Services-API eller Privacy Servicens användargränssnitt dokumentation för fullständiga steg om hur du skickar ett sekretessjobb, inklusive hur inskickade användaridentitetsdata formateras korrekt i begärandenyttolaster.

VIKTIGT

Privacy Servicen kan bara bearbeta Profile data med en sammanfogningsprincip som inte utför identitetssammanfogning. Om du använder användargränssnittet för att bekräfta om dina sekretessförfrågningar behandlas kontrollerar du att du använder en profil med "None" som ID stitching typ. Du kan alltså inte använda en sammanfogningsprincip där ID stitching är inställd på "Private graph".

Sammanfogningsprincipens ID-sammanfogning är inställd på Ingen

Det är också viktigt att notera att det inte går att garantera hur lång tid en sekretessbegäran kan ta att slutföra. Om ändringar inträffar i Profile data medan en begäran fortfarande bearbetas, oavsett om dessa poster bearbetas eller inte kan också garanteras.

Använda API:et

När du skapar jobbförfrågningar i API:t, anges alla ID:n i userIDs måste använda en specifik namespace och type. Ett giltigt identity namespace känns igen av Identity Service måste anges för namespace värde, medan type måste vara antingen standard eller unregistered (för standardnamnutrymmen respektive anpassade namnutrymmen).

OBSERVERA

Du kan behöva ange mer än ett ID för varje kund, beroende på identitetsdiagrammet och hur dina profilfragment distribueras i plattformsdatauppsättningar. Se nästa avsnitt profilfragment för mer information.

Dessutom är include arrayen med nyttolasten för begäran måste innehålla produktvärdena för de olika datalager som begäran görs till. När förfrågningar görs till Data Lakemåste arrayen innehålla värdet "ProfileService".

Följande begäran skapar ett nytt sekretessjobb för en enskild kunds data i Profile butik. Två identitetsvärden anges för kunden i userIDs array, en som använder standarden Email id namespace, and the other using a custom Customer_ID namnutrymme. Den innehåller också produktvärdet för Profile (ProfileService) i include array:

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"],
    "expandIds": false,
    "priority": "normal",
    "regulation": "ccpa"
}'
VIKTIGT

Plattformsprocessernas sekretessförfrågningar för alla sandlådor som tillhör din organisation. Detta resulterar i att x-sandbox-name huvud som ingår i begäran ignoreras av systemet.

Använda gränssnittet

När du skapar jobbförfrågningar i användargränssnittet måste du välja AEP Data Lake och/eller Profile under Products för att bearbeta jobb för data som lagras i Data Lake eller Real-time Customer Profile, respektive.

En begäran om åtkomstjobb skapas i användargränssnittet med alternativet Profil markerat under Produkter

Profilfragment i sekretessförfrågningar

I Profile personuppgifterna för en enskild kund består ofta av flera profilfragment som kopplas till personen via identitetsdiagrammet. När sekretessförfrågningar görs till Profile lagring är det viktigt att tänka på att begäranden bara behandlas på profilfragmentnivån i stället för på hela profilen.

Tänk dig till exempel en situation där du lagrar kundattributdata i tre separata datauppsättningar, som använder olika identifierare för att associera dessa data med enskilda kunder:

Namn på datauppsättning Primärt identitetsfält Lagrade attribut
Datauppsättning 1 customer_id address
Datauppsättning 2 email_id firstName, lastName
Datauppsättning 3 email_id mlScore

En av datauppsättningarna använder customer_id som primär identifierare, medan de andra två använder email_id. Om du skulle skicka en begäran om sekretess (åtkomst eller radering) använder du endast email_id som användar-ID, endast firstName, lastNameoch mlScore attribut skulle bearbetas, medan address inte påverkas.

För att säkerställa att dina sekretessförfrågningar behandlar alla relevanta kundattribut måste du ange de primära identitetsvärdena för alla tillämpliga datauppsättningar där dessa attribut kan lagras (upp till högst nio ID:n per kund). Se avsnittet om identitetsfält i grunderna för schemakomposition för mer information om fält som vanligen markeras som identiteter.

Ta bort bearbetning av begäran

När Experience Platform tar emot en borttagningsbegäran från Privacy Service, Platform skickar bekräftelse till Privacy Service att begäran har tagits emot och att data som påverkas har markerats för borttagning. Posterna tas sedan bort från Data Lake eller Profile lagra när sekretessjobbet är klart. Medan borttagningsjobbet fortfarande bearbetas tas data bort och är därför inte tillgängliga för alla Platform service. Se Privacy Service dokumentation för mer information om spårning av jobbstatus.

VIKTIGT

En begäran om borttagning tar bort insamlade attributdata för en kund (eller en uppsättning kunder), men begäran tar inte bort de associationer som har upprättats i identitetsdiagrammet.

En borttagningsbegäran som använder en kunds email_id och customer_id tar bort alla attributdata som lagras under dessa ID:n. Alla uppgifter som därefter importeras under samma customer_id kommer fortfarande att kopplas till lämplig email_id, eftersom associationen fortfarande finns.

Dessutom kan Privacy Servicen bara bearbeta Profile data med en sammanfogningsprincip som inte utför identitetssammanfogning. Om du använder användargränssnittet för att bekräfta om dina sekretessförfrågningar behandlas kontrollerar du att du använder en profil med "None" som ID stitching typ. Du kan alltså inte använda en sammanfogningsprincip där ID stitching är inställd på "Private graph".

Sammanfogningsprincipens ID-sammanfogning är inställd på Ingen

I framtida versioner Platform skickar bekräftelsen till Privacy Service efter att data har tagits bort fysiskt.

Nästa steg

Genom att läsa det här dokumentet har du introducerat de viktiga begrepp som används för att behandla sekretessförfrågningar i Experience Platform. 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.

För information om behandling av sekretessförfrågningar för Platform resurser som inte används av Profile, se dokumentet på behandling av sekretessförfrågningar i Data Lake.

På denna sida