Show Menu
SUJETS×

Traitement de la demande de confidentialité dans Data Lake

L’Adobe Experience Platform Privacy Service traite les demandes d’accès, de 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é.
This document covers essential concepts related to processing privacy requests for customer data stored in the Data Lake.

Prise en main

It is recommended that you have a working understanding of the following Experience Platform services before reading this guide:
  • Privacy Service  : gère les demandes de clients souhaitant accéder à leurs données personnelles, en refuser la vente ou les effacer dans différentes applications Adobe Experience Cloud.
  • Catalog Service : Système d’enregistrement pour l’emplacement et le lignage des données dans Experience Platform. Fournit une API qui peut être utilisée pour mettre à jour les métadonnées des jeux de données.
  • Experience Data Model (XDM) System : Cadre normalisé selon lequel Experience Platform organiser les données d’expérience client.
  • Identity Service  : résout le problème fondamental de la fragmentation des données d’expérience client en rapprochant les identités entre les appareils et les systèmes.

Compréhension des espaces de noms d’identité

Adobe Experience Platform Identity Service bridges customer identity data across systems and devices. 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 électronique (« 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 nom 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.
For more information about identity namespaces in Experience Platform, see the identity namespace overview .

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

Lors de la création de demandes de confidentialité pour les Data Lakeclients, des valeurs d'identité valides (et leurs espaces de nommage 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 de confidentialité doivent contenir un descripteur d’ identité dans leur schéma XDM associé.
Les jeux de données basés sur des schémas qui ne prennent pas en charge les métadonnées des descripteurs d’identité (tels que les jeux de données ad hoc) ne peuvent pas actuellement être traités dans les demandes de confidentialité.
Cette section décrit les étapes à suivre pour 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 Étiquetage des champs imbriqués de type map suivante.
Lorsque vous décidez des champs de schéma à définir en tant qu’identités, gardez à l’esprit les limites de l’utilisation de champs de type mappage imbriqués.
Il existe deux méthodes pour ajouter un descripteur d'identité à un schéma de jeux de données :

Utilisation de l’interface utilisateur

Dans l'interface Experience Platformutilisateur, 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 leSchema Editordidacticiel.
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 lors de l’ envoi des demandes de confidentialité.

Utilisation de l’API

Cette section suppose que vous connaissez la valeur d'ID URI unique du schéma XDM de votre jeu de données. Si vous ne connaissez pas cette valeur, vous pouvez la récupérer à l’aide de l’ Catalog Service API. Après avoir lu la section prise en main du guide du développeur, suivez les étapes décrites dans la section pour répertorier ou rechercher des objets Catalog pour trouver votre jeu de données. L'ID de schéma se trouve sous schemaRef.id
Cette section comprend des appels à l'API de registre du Schéma. Pour obtenir des informations importantes sur l’utilisation de l’API, y compris la connaissance de votre concept {TENANT_ID} et du concept de conteneur, consultez la section prise en main du guide du développeur.
Vous pouvez ajouter un descripteur d'identité au schéma XDM d'un jeu de données en exécutant une requête POST sur le point de /descriptors terminaison de l' Schema Registry API.
Format d’API
POST /descriptors

Requête
La requête suivante définit un descripteur d’identité dans un champ « adresse électronique » d’un exemple de schéma.
curl -X POST \
  https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {IMS_ORG}' \
  -H 'x-sandbox-name: {SANDBOX_NAME}' \
  -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
      }'

Propriété
Description
@type
Type de descripteur en cours de création. Pour les descripteurs d’identité, la valeur doit être "xdm:descriptorIdentity".
xdm:sourceSchema
ID URI unique du schéma XDM de votre jeu de données.
xdm:sourceVersion
Version du schéma XDM spécifiée dans xdm:sourceSchema .
xdm:sourceProperty
Chemin d’accès au champ de schéma auquel le descripteur est appliqué.
xdm:namespace
L'un des espaces de nommage d'identité standard reconnus par Privacy Serviceou un espace de nommage personnalisé défini par votre organisation.
xdm:property
"xdm:id" ou "xdm:code", selon l’espace de nommage utilisé sous xdm:namespace .
xdm:isPrimary
Une valeur booléenne facultative. Lorsque la valeur est true, cela indique que le champ est une identité principale. Les schémas ne peuvent contenir qu’une seule identité principale. La valeur par défaut est false si elle n’est pas incluse.
Réponse
Une réponse réussie renvoie l’état HTTP 201 (Créé) et les détails du descripteur nouvellement créé.
{
  "@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

This section covers how to format privacy requests for the Data Lake. It is strongly recommended that you review the Privacy Service UI or Privacy Service API documentation for complete steps on how to submit a privacy job, including how to properly format submitted user identity data in request payloads.
La section suivante décrit comment effectuer des demandes de confidentialité pour l’ Data Lake utilisation de l’ Privacy Service interface utilisateur ou de l’API.

Utilisation de l’interface utilisateur

Lors de la création de requêtes de tâche dans l’interface utilisateur, veillez à bien sélectionner AEP et/ou Profile sous _Produits_afin de traiter les tâches pour les données stockées respectivement dans le lac de données ou dans .Data Lake​Real-time Customer Profile

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. IDs for the Data Lake must use "unregistered" for their type value, and a namespace value that matches one the privacy labels that have been added to applicable datasets.
En outre, le tableau include du 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. When making requests to the Data Lake, the array must include the value aepDataLake .
The following request creates a new privacy job for the Data Lake, using the unregistered "email_label" namespace. It also includes the product value for the Data Lake in the include array:
curl -X POST \
  https://platform.adobe.io/data/core/privacy/jobs \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {IMS_ORG}' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "{IMS_ORG}"
      }
    ],
    "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

When Experience Platform receives a delete request from Privacy Service, Platform sends confirmation to Privacy Service that the request has been received and affected data has been marked for deletion. The records are then removed from the Data Lake within seven days. During that seven-day window, the data is soft-deleted and is therefore not accessible by any Platform service.
In future releases, Platform will send confirmation to Privacy Service after data has been physically deleted.

Étapes suivantes

By reading this document, you have been introduced to the important concepts involved with processing privacy requests for the Data Lake. 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 à propos du traitement des requêtes de confidentialité pour Real-time Customer afin de connaître les étapes du traitement des demandes d’accès à des informations personnelles pour la banque de profils.Profile

Annexe

La section suivante contient des informations supplémentaires pour le traitement des demandes de confidentialité dans le Data Lake.

Étiquetage des champs imbriqués de type map

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é :
  • Champ de type map dans un champ de type tableau
  • Champ de type map dans un autre champ de type map
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.