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

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

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

Komma igång

Handboken kräver en fungerande förståelse av följande Platform-komponenter:

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").

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 finns i översikten över identitetsnamnrymden.

Skicka begäranden submit

Avsnitten nedan beskriver hur du gör sekretessförfrågningar för Real-Time Customer Profile med API:t Privacy Service eller gränssnittet. Innan du läser de här avsnitten bör du granska, eller känna till, dokumentationen för Privacy Services-API eller Privacy Servicens användargränssnitt. Dessa dokument innehåller fullständiga anvisningar om hur du skickar in ett sekretessjobb, inklusive hur inskickade användaridentitetsdata formateras korrekt i begärda nyttolaster.

Använda API:et

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

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. Om du vill ta bort profildata som är associerade med en identitet måste matrisen innehålla värdet ProfileService. Om du vill ta bort kundens identitetsdiagramassociationer måste matrisen innehålla värdet identity.

Följande begäran skapar ett nytt sekretessjobb för en enskild kunds data i Profile-butiken. Det finns två identitetsvärden för kunden i arrayen userIDs. Den ena använder standardnamnutrymmet för identitet Email och den andra använder ett anpassat namnutrymme för Customer_ID. Den innehåller också produktvärdet för Profile (ProfileService) i arrayen include:

Begäran

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"
}'

Produktsvar

När sekretessjobbet har slutförts för profiltjänsten returneras ett svar i JSON-format med information om de användar-ID som efterfrågas.

{
    "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"
                            }
                        ]
                    }
                }
            }
        ]
    }
}

Använda gränssnittet

När du skapar jobbförfrågningar i användargränssnittet måste du markera AEP Data Lake och/eller Profile under Products för att kunna bearbeta jobb för data som lagras i datasjön eller Real-Time Customer Profile.

Profilfragment i sekretessförfrågningar fragments

I datalagret Profile består persondata för en enskild kund ofta av flera profilfragment som är kopplade till personen via identitetsdiagrammet. När du gör sekretessförfrågningar i Profile-arkivet är det viktigt att notera att förfrågningar 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:

En av datauppsättningarna använder customer_id som primär identifierare, medan de andra använder email_id. Om du skulle skicka en sekretessförfrågan (åtkomst eller borttagning) med endast email_id som användar-ID-värde, skulle bara attributen firstName, lastName och mlScore bearbetas, medan address inte skulle 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). Mer information om fält som vanligtvis markeras som identiteter finns i avsnittet om identitetsfält i grunderna för schemakomposition.

Ta bort bearbetning av begäran delete

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. Posterna tas sedan bort när sekretessjobbet har slutförts.

Beroende på om du även inkluderade identitetstjänsten (identity) och datasjön (aepDataLake) som produkter i din sekretessbegäran för profilen (ProfileService), tas olika datauppsättningar som är relaterade till profilen bort från systemet vid potentiellt olika tidpunkter:

Mer information om att spåra jobbstatus finns i Privacy Service dokumentationen.

Profilförfrågningar kontra identitetsförfrågningar profile-v-identity

Om en borttagningsbegäran görs för profilen (ProfileService) men inte för identitetstjänsten (identity), tar det resulterande jobbet bort de insamlade attributdata för en kund (eller en uppsättning kunder), men tar inte bort associationerna 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 data som därefter importeras under samma customer_id kommer dock fortfarande att kopplas till rätt email_id, eftersom associationen fortfarande finns.

Om du vill ta bort profilen och alla identitetsassociationer för en viss kund måste du ta med både profil- och identitetstjänsten som målprodukter i borttagningsförfrågningarna.

Begränsningar för sammanfogningsprincip merge-policy-limitations

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 princip med None som ID stitching-typ. Du kan med andra ord inte använda en sammanfogningsprincip där ID stitching är inställd på Private graph.

Nästa steg

Genom att läsa det här dokumentet har du introducerats till de viktiga begrepp som används för att bearbeta sekretessförfrågningar i Experience Platform. Om du vill få en djupare förståelse för hur du hanterar identitetsdata och skapar sekretessjobb kan du fortsätta att läsa dokumentationen som finns i den här handboken.

Mer information om hur du hanterar sekretessbegäranden för Platform-resurser som inte används av Profile finns i dokumentet om bearbetning av sekretessförfrågningar i datasjön.