Traitement des demandes d’accès à des informations personnelles dans le lac de données

Adobe Experience Platform Privacy Service traite les demandes des clients en matière dʼaccès, d’opt-out de vente ou de suppression de leurs données personnelles conformément aux réglementations légales et organisationnelles en matière de confidentialité.

Ce document couvre les concepts essentiels liés au traitement des demandes d’accès à des informations personnelles pour les données clients stockées dans le lac de données.

Prise en main

Une connaissance concrète des services Experience Platform suivants est recommandée avant la lecture de ce guide :

Compréhension des espaces de noms d’identité namespaces

Adobe Experience Platform Identity Service rapproche les données dʼidentité client entre les systèmes et les appareils. Identity Service utilise les espaces de noms d’identité pour fournir un contexte aux valeurs d’identité en les reliant à leur système d’origine. Un espace de noms peut représenter un concept générique tel qu’une adresse e-mail (« E-mail ») ou associer l’identité à une application spécifique telle qu’un identifiant Adobe Advertising Cloud ID (« AdCloud ») ou un identifiant Adobe Target (« TNTID »).

Identity Service conserve un stock d’espaces de noms d’identité définis globalement (standard) et par l’utilisateur (personnalisés). Les espaces de noms standard sont disponibles pour toutes les organisations (par exemple, « E-mail » et « ECID »), tandis que votre organisation peut aussi créer des espaces de noms personnalisés adaptés à ses besoins spécifiques.

Pour plus dʼinformations sur les espaces de noms dʼidentité dans Experience Platform, consultez la présentation de lʼespace de noms dʼidentité.

Ajouter des données dʼidentité aux jeux de données

Lors de la création de demandes d’accès à des informations personnelles pour le lac de données, des valeurs d’identité valides (et leurs espaces de noms associés) doivent être fournies pour chaque client afin de localiser ses données et de les traiter en conséquence. Par conséquent, tous les jeux de données qui font lʼobjet de demandes dʼaccès à des informations personnelles doivent contenir un descripteur dʼidentité dans leur schéma XDM associé.

Cette section vous explique étape par étape comment ajouter un descripteur dʼidentité au schéma XDM dʼun jeu de données existant. Si vous disposez déjà dʼun jeu de données avec un descripteur dʼidentité, vous pouvez passer à la section suivante.

Il existe deux méthodes pour ajouter un descripteur dʼidentité à un schéma de jeu de données :

Utilisation de l’interface utilisateur identity-ui

Dans lʼinterface utilisateur dʼExperience Platform, lʼespace de travail Schémas vous permet de modifier vos schémas XDM existants. Pour ajouter un descripteur dʼidentité à un schéma, sélectionnez le schéma dans la liste et suivez les étapes pour définir un champ de schéma en tant que champ dʼidentité dans le tutoriel de Schema Editor.

Une fois que vous avez défini les champs appropriés dans le schéma en tant que champs dʼidentité, vous pouvez passer à la section suivante sur lʼenvoi de demandes dʼaccès à des informations personnelles.

Utilisation de l’API identity-api

Vous pouvez ajouter un descripteur dʼidentité au schéma XDM dʼun jeu de données en envoyant une requête POST au point d’entrée /descriptors de lʼAPI Schema Registry.

Format d’API

POST /descriptors

Requête

La requête suivante définit un descripteur d’identité dans un champ « adresse e-mail » d’un exemple de schéma.

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

Réponse

Une réponse réussie renvoie un état HTTP 201 (Created) et les détails du nouveau descripteur.

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

Envoi de requêtes submit

La section suivante explique comment effectuer des demandes d’accès à des informations personnelles pour le lac de données à l’aide de la variable Privacy Service Interface utilisateur ou API.

Utilisation de l’interface utilisateur

Lors de la création de requêtes de tâche dans l’interface utilisateur, veillez à sélectionner Lac de données AEP under Produits afin de traiter les tâches pour les données stockées dans le lac de données.

Utilisation de l’API

Lors de la création de requêtes de tâche dans l’API, tout userIDs fourni doit utiliser un namespace et un type spécifiques en fonction de la banque de données concernée. Les identifiants du lac de données doivent utiliser unregistered pour leur type et une valeur namespace qui correspond à l’une des valeurs étiquettes de confidentialité qui ont été ajoutés aux jeux de données applicables.

En outre, le tableau include de la payload de requête doit inclure les valeurs de produit pour les différentes banques de données vers lesquelles la requête est effectuée. Lors de l’envoi de requêtes au lac de données, le tableau doit inclure la valeur aepDataLake.

La requête suivante crée une nouvelle tâche de confidentialité pour le lac de données, en utilisant le paramètre non enregistré email_label espace de noms. Elle inclut également la valeur du produit pour le lac de données dans la variable include tableau :

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

Traitement des demandes de suppression

LorsquʼExperience Platform reçoit une requête DELETE de la part de Privacy Service, Platform envoie une confirmation à Privacy Service pour confirmer que la requête a été reçue et que les données concernées ont été marquées pour suppression. Les enregistrements sont ensuite retirés du lac de données dans les sept jours. Pendant cette période de sept jours, les données subissent une suppression réversible, elles ne sont donc accessibles par aucun service Platform.

Si vous avez également inclus ProfileService ou identity dans la demande d’accès à des informations personnelles, les données qui lui sont associées sont traitées séparément. Voir la section sur traitement des requêtes de suppression pour Profile pour plus d’informations.

Étapes suivantes

En lisant ce document, vous avez découvert les concepts importants liés au traitement des demandes d’accès à des informations personnelles pour le lac de données. Il est recommandé de continuer la lecture de la documentation fournie dans ce guide afin de mieux comprendre comment gérer les données d’identité et créer des tâches concernant la confidentialité.

Consultez le document sur traitement des demandes d’accès à des informations personnelles pour Real-time Customer Profile pour les étapes de traitement des demandes d’accès à des informations personnelles pour Profile magasin.

Annexe

La section suivante contient des informations supplémentaires sur le traitement des demandes d’accès à des informations personnelles dans le lac de données.

Étiquetage des champs imbriqués de type map nested-maps

Il faut souligner qu’il existe deux types de champs imbriqués de type map qui ne prennent pas en charge l’étiquetage de confidentialité :

Le traitement des tâches concernant la confidentialité pour l’un ou l’autre des deux exemples ci-dessus échouera. C’est pourquoi il est recommandé d’éviter d’utiliser des champs imbriqués de type map pour stocker des données clients privées. Les identifiants clients pertinents doivent être stockés sous la forme d’un type de données non mappé dans le champ identityMap (lui-même un champ de type map) pour les jeux de données basés sur des enregistrements, ou dans le champ endUserID pour les jeux de données basés sur des séries temporelles.