Elaborazione delle richieste di privacy nel data lake

Adobe Experience Platform Privacy Service elabora le richieste dei clienti di accedere ai propri dati personali, di rinunciarvi o di eliminarli, in base alle normative legali e organizzative sulla privacy.

Questo documento descrive i concetti essenziali relativi all’elaborazione delle richieste di privacy per i dati dei clienti memorizzati nel data lake.

Introduzione

Prima di leggere questa guida, è consigliabile avere una buona conoscenza dei seguenti servizi Experience Platform:

Comprendere gli spazi dei nomi delle identità namespaces

Adobe Experience Platform Identity Service esegue il bridging dei dati di identità del cliente tra sistemi e dispositivi. Identity Service utilizza gli spazi dei nomi di identità per fornire contesto ai valori di identità tramite la relazione con il rispettivo sistema di origine. Uno spazio dei nomi può rappresentare un concetto generico come un indirizzo e-mail ("E-mail") o associare l’identità a un’applicazione specifica, come un Adobe Advertising Cloud ID ("AdCloud") o un Adobe Target ID ("TNTID").

Identity Service mantiene un archivio di spazi dei nomi di identità definiti a livello globale (standard) e definiti dall'utente (personalizzati). Gli spazi dei nomi standard sono disponibili per tutte le organizzazioni (ad esempio, "E-mail" e "ECID"), mentre l’organizzazione può anche creare spazi dei nomi personalizzati in base alle sue esigenze specifiche.

Per ulteriori informazioni sugli spazi dei nomi delle identità in Experience Platform, vedere panoramica dello spazio dei nomi delle identità.

Aggiunta di dati di identità ai set di dati

Quando si creano richieste di privacy per il data lake, è necessario fornire valori di identità validi (e i namespace associati) per ogni singolo cliente al fine di individuare i propri dati ed elaborarli di conseguenza. Pertanto, tutti i set di dati soggetti a richieste di privacy devono contenere un descrittore di identità nel relativo schema XDM associato.

Questa sezione illustra i passaggi necessari per aggiungere un descrittore di identità allo schema XDM di un set di dati esistente. Se hai già un set di dati con un descrittore di identità, puoi passare alla sezione successiva.

Esistono due metodi per aggiungere un descrittore di identità a uno schema di set di dati:

Utilizzo dell’interfaccia utente identity-ui

Nell'interfaccia utente Experience Platforml'area di lavoro Schemi consente di modificare gli schemi XDM esistenti. Per aggiungere un descrittore di identità a uno schema, selezionarlo dall'elenco e seguire i passaggi per impostare un campo schema come campo di identità nell'esercitazione Schema Editor.

Dopo aver impostato i campi appropriati nello schema come campi di identità, puoi passare alla sezione successiva su invio di richieste di privacy.

Mediante l’API identity-api

È possibile aggiungere un descrittore di identità allo schema XDM di un set di dati effettuando una richiesta POST all'endpoint /descriptors nell'API Schema Registry.

Formato API

POST /descriptors

Richiesta

La seguente richiesta definisce un descrittore di identità in un campo "indirizzo e-mail" in uno schema di esempio.

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

Risposta

In caso di esito positivo, la risposta restituisce lo stato HTTP 201 (Creato) e i dettagli del descrittore appena creato.

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

Invio di richieste submit

La sezione seguente illustra come effettuare richieste di privacy per il data lake utilizzando l'interfaccia utente o l'API Privacy Service.

Utilizzo dell’interfaccia utente

Quando crei richieste di lavoro nell'interfaccia utente, assicurati di selezionare AEP Data Lake in Prodotti per elaborare i processi per i dati memorizzati nel data lake.

Mediante l’API

Quando si creano richieste di processi nell'API, qualsiasi userIDs fornito deve utilizzare un namespace e un type specifici a seconda dell'archivio dati a cui si applicano. Gli ID per il data lake devono utilizzare unregistered per il valore type e un valore namespace che corrisponde a una delle etichette per la privacy aggiunte ai set di dati applicabili.

Inoltre, l'array include del payload della richiesta deve includere i valori del prodotto per i diversi archivi di dati a cui viene effettuata la richiesta. Quando si eseguono richieste al data lake, l'array deve includere il valore aepDataLake.

La richiesta seguente crea un nuovo processo di privacy per il data lake, utilizzando lo spazio dei nomi email_label non registrato. Include inoltre il valore del prodotto per il data lake nell'array 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"
}'

Elaborazione richiesta di eliminazione

Quando Experience Platform riceve una richiesta di eliminazione da Privacy Service, Platform invia una conferma a Privacy Service che la richiesta è stata ricevuta e che i dati interessati sono stati contrassegnati per l'eliminazione. I record vengono quindi rimossi dal data lake entro sette giorni. Durante tale finestra di sette giorni, i dati vengono eliminati in modo non permanente e non sono quindi accessibili da alcun servizio Platform.

Se nella richiesta di accesso a dati personali hai incluso anche ProfileService o identity, i dati associati verranno gestiti separatamente. Per ulteriori informazioni, vedere la sezione relativa all'elaborazione di richieste di eliminazione per il profilo.

Passaggi successivi

Dopo aver letto questo documento, ti vengono presentati i concetti importanti relativi all’elaborazione delle richieste di accesso a dati personali per il data lake. Si consiglia di continuare a leggere la documentazione fornita in questa guida per comprendere meglio come gestire i dati di identità e creare processi sulla privacy.

Per informazioni sulla procedura di elaborazione delle richieste di accesso a dati personali per l'archivio Profile, vedere il documento sull'elaborazione delle richieste di accesso a dati personali per Real-Time Customer Profile🔗.

Appendice

La sezione seguente contiene informazioni aggiuntive per l’elaborazione delle richieste di accesso a dati personali nel data lake.

Etichettatura dei campi di tipo mappa nidificati nested-maps

È importante notare che esistono due tipi di campi di tipo mappa nidificati che non supportano l’etichettatura della privacy:

L’elaborazione del processo di privacy per uno dei due esempi precedenti alla fine avrà esito negativo. Per questo motivo, si consiglia di evitare di utilizzare campi di tipo mappa nidificati per memorizzare dati privati dei clienti. Gli ID consumer rilevanti devono essere memorizzati come tipo di dati non mappa nel campo identityMap (a sua volta un campo di tipo mappa) per i set di dati basati su record o nel campo endUserID per i set di dati basati su serie temporali.