Show Menu
SUJETS×

Privacy request processing in Real-time Customer Profile

Adobe Experience Platform Privacy Service processes customer requests to access, opt out of sale, or delete their personal data as delineated by privacy regulations such as the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA).
This document covers essential concepts related to processing privacy requests for Real-time Customer Profile.

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 des clients pour accéder aux applications Adobe Experience Cloud, les exclure de la vente ou supprimer leurs données personnelles.
  • Service d'identité : Résout le défi fondamental posé par la fragmentation des données d’expérience client en rapprochant les identités entre les périphériques et les systèmes.
  • Profil client en temps réel : Fournit un profil de consommation unifié en temps réel basé sur des données agrégées provenant de plusieurs sources.

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 .

Envoi de requêtes

Les sections ci-dessous décrivent comment effectuer des demandes de confidentialité pour Real-time Customer Profile l’utilisation de l’ Privacy Service API ou de l’interface utilisateur. Before reading these sections, it is strongly recommended that you review the Privacy Service API or Privacy Service UI documentation for complete steps on how to submit a privacy job, including how to properly format submitted user identity data in request payloads.
Le Privacy Service ne peut traiter Profile les données qu’à l’aide d’une stratégie de fusion qui n’effectue pas d’assemblage d’identité. Si vous utilisez l’interface utilisateur pour vérifier si vos demandes de confidentialité sont en cours de traitement, veillez à utiliser une stratégie avec "None" comme type de raccordement d’ ID. En d’autres termes, vous ne pouvez pas utiliser de stratégie de fusion lorsque l’assemblage d’ ID est défini sur "Graphiqueprivé".

Utilisation de l’API

Lors de la création de demandes de tâche dans l’API, les identifiants fournis dans userIDs doivent utiliser un identifiant spécifique namespace et type . Un espace de nommage d' identité valide reconnu par Identity Service doit être fourni pour la namespace valeur, tandis que la type valeur doit être soit standard soit unregistered (pour les espaces de nommage standard et personnalisés, respectivement).
Vous devrez peut-être fournir plusieurs identifiants pour chaque client, en fonction du graphique d’identité et de la manière dont vos fragments de profil sont distribués dans les jeux de données de la plateforme. Pour plus d’informations, voir la section suivante profils .
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 "ProfileService".
La demande suivante crée une nouvelle tâche de confidentialité pour les données d’un client unique dans la Profile boutique. Deux valeurs d'identité sont fournies pour le client de la userIDs baie ; l'un utilise l'espace de nommage Email d'identité standard, l'autre un Customer_ID espace de nommage personnalisé. It also includes the product value for Profile ( ProfileService ) 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}' \
  -H 'x-sandbox-name: {SANDBOX_NAME}' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "{IMS_ORG}"
      }
    ],
    "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",
    "analyticsDeleteMethod": "anonymize",
    "regulation": "ccpa"
}'

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

Fragments de profil dans les demandes de confidentialité

Dans le magasin de Profile données, les données personnelles d’un client individuel sont souvent constituées de plusieurs fragments de profil, qui sont associés à la personne via le graphique d’identité. Lors de l’envoi de requêtes de confidentialité à la Profile boutique, il est important de noter que les requêtes sont traitées uniquement au niveau du fragment de profil, plutôt que sur l’ensemble du profil.
Prenons l’exemple d’un cas où vous stockez des données d’attributs du client dans trois jeux de données distincts, qui utilisent des identifiants différents pour associer ces données à des clients individuels :
Nom du jeu de données
Champ d'identité Principal
Attributs stockés
Jeu de données 1
customer_id
address
Jeu de données 2
email_id
firstName , lastName
Jeu de données 3
email_id
mlScore
L'un des jeux de données utilise customer_id comme identifiant Principal, tandis que les deux autres utilisent email_id . Si vous deviez envoyer une demande de confidentialité (accès ou suppression) en utilisant uniquement email_id comme valeur d’ID utilisateur, seuls les attributs firstName , lastName et mlScore sont traités, mais address ne sont pas affectés.
Pour vous assurer que vos demandes de confidentialité traitent tous les attributs de client pertinents, vous devez fournir les valeurs d’identité Principales pour tous les jeux de données applicables dans lesquels ces attributs peuvent être stockés (jusqu’à neuf identifiants par client). Pour plus d’informations sur les champs d’identité couramment identifiés comme identités, consultez la section relative aux champs d’identité dans les bases de la composition des schémas.
Si vous utilisez des sandbox différents pour stocker vos Profile données, vous devez effectuer une demande de confidentialité distincte pour chaque sandbox, en indiquant le nom de sandbox approprié dans l’ x-sandbox-name en-tête.

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. Les enregistrements sont ensuite supprimés de la Data Lake boutique ou de la Profile boutique une fois la tâche de confidentialité terminée. Bien que la tâche de suppression soit toujours en cours de traitement, les données sont supprimées à l’écran et ne sont donc accessibles à aucun Platform service. Consultez la Privacy Service documentation pour plus d’informations sur le suivi des états des tâches.
Bien qu’une demande de suppression réussie supprime les données d’attribut collectées pour un client (ou un ensemble de clients), la demande ne supprime pas les associations établies dans le graphique d’identité.
Par exemple, une requête de suppression qui utilise une requête de client email_id et customer_id supprime toutes les données d’attribut stockées sous ces identifiants. Toutefois, les données qui seront ensuite assimilées sous la même customer_id forme seront toujours associées aux données appropriées email_id , car l'association existe toujours.
In future releases, Platform will send confirmation to Privacy Service after data has been physically deleted.

É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 dans Experience Platform. 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é.
For information on processing privacy requests for Platform resources not used by Profile, see the document on privacy request processing in the Data Lake .