Verarbeitung von Datenschutzanfragen im Data Lake

Adobe Experience Platform Privacy Service bearbeitet Anfragen von Kunden, auf ihre personenbezogenen Daten zuzugreifen, sich gegen deren Verkauf zu wenden oder sie zu löschen, wie in den gesetzlichen und organisatorischen Datenschutzbestimmungen festgelegt.

In diesem Dokument werden wesentliche Konzepte zur Verarbeitung von Datenschutzanfragen für im Data Lake gespeicherte Kundendaten behandelt.

Erste Schritte

Sie sollten über Grundkenntnisse zu folgenden Experience Platform-Services verfügen, bevor Sie dieses Handbuch lesen:

Identitäts-Namespaces verstehen namespaces

Adobe Experience Platform Identity Service führt Identitätsdaten von Kunden über Systeme und Geräte hinweg zusammen. Identity Service verwendet Identitäts-Namespaces, um einen Kontext zu Identitätswerten bereitzustellen, indem sie mit dem System ihrer Herkunft verknüpft werden. Ein Namespace kann ein allgemeines Konzept wie eine E-Mail-Adresse („E-Mail“) sein oder die Identität einer bestimmten Anwendung zuordnen, wie z. B. eine Adobe Advertising Cloud-ID („AdCloud“) oder eine Adobe Target-ID („TNTID“).

Identity Service verwaltet einen Speicher global definierter (standardmäßiger) und benutzerdefinierter Identitäts-Namespaces. Standardmäßige Namespaces (z. B. „E-Mail“ und „ECID“) stehen für alle Unternehmen zur Verfügung, während Ihr Unternehmen außerdem benutzerdefinierte Namespaces erstellen kann, die den jeweiligen Anforderungen entsprechen.

Weitere Informationen zu Identitäts-Namespaces in Experience Platform finden Sie unter Identitäts-Namespaces – Übersicht.

Hinzufügen von Identitätsdaten zu Datensätzen

Bei der Erstellung von Datenschutzanfragen für den Data Lake müssen für jeden einzelnen Kunden gültige Identitätswerte (und die zugehörigen Namespaces) angegeben werden, um seine Daten zu lokalisieren und entsprechend zu verarbeiten. Daher müssen alle Datensätze, die Datenschutzanfragen unterliegen, einen Identitätsdeskriptor in ihrem zugehörigen XDM-Schema enthalten.

In diesem Abschnitt werden die Schritte zum Hinzufügen eines Identitätsdeskriptors zum XDM-Schema eines vorhandenen Datensatzes beschrieben. Wenn Sie bereits über einen Datensatz mit einem Identitätsdeskriptor verfügen, können Sie zum nächsten Abschnitt springen.

Es gibt zwei Methoden zum Hinzufügen eines Identitätsdeskriptors zu einem Datensatzschema:

Verwenden der Benutzeroberfläche identity-ui

In der Experience Platform-Benutzeroberfläche können Sie mit dem Arbeitsbereich Schemata Ihre vorhandenen XDM-Schemata bearbeiten. Um einem Schema einen Identitätsdeskriptor hinzuzufügen, wählen Sie das Schema in der Liste aus und befolgen Sie die Schritte zum Einrichten eines Schema-Felds als Identitätsfeld im Tutorial Schema Editor.

Nachdem Sie die entsprechenden Felder im Schema als Identitätsfelder festgelegt haben, können Sie mit dem nächsten Abschnitt zum Senden von Datenschutzanfragen fortfahren.

Verwenden der API identity-api

Sie können dem XDM-Schema eines Datensatzes einen Identitätsdeskriptor hinzufügen, indem Sie eine POST-Anfrage an den /descriptors-Endpunkt in der Schema Registry-API stellen.

API-Format

POST /descriptors

Anfrage

Die folgende Anfrage definiert einen Identitätsdeskriptor für ein Feld „E-Mail-Adresse“ in einem Beispielschema.

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

Antwort

Eine erfolgreiche Antwort gibt den HTTP-Status 201 (Erstellt) sowie die Details des neu erstellten Deskriptors zurück.

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

Übermitteln von Anfragen submit

Im folgenden Abschnitt wird beschrieben, wie Sie mithilfe der Privacy Service -Benutzeroberfläche oder -API Datenschutzanfragen für den Data Lake ausführen.

Verwenden der Benutzeroberfläche

Stellen Sie beim Erstellen von Auftragsanfragen in der Benutzeroberfläche sicher, dass Sie unter Produkte die Option AEP Data Lake auswählen, um Aufträge für Daten zu verarbeiten, die im Data Lake gespeichert sind.

Verwenden der API

Beim Erstellen von Auftragsanfragen in der API müssen alle angegebenen userIDs einen bestimmten namespace und type nutzen, je nach dem Datenspeicher, für den sie gelten. IDs für den Data Lake müssen für ihren type -Wert unregistered und einen namespace -Wert verwenden, der mit einer der Datenschutzbezeichnungen übereinstimmt, die den entsprechenden Datensätzen hinzugefügt wurden.

Darüber hinaus muss das include-Array der Anfrage-Payload die Produktwerte für die verschiedenen Datenspeicher enthalten, an die die Anfrage gesendet wird. Bei Anfragen an den Data Lake muss das Array den Wert aepDataLake enthalten.

Mit der folgenden Anfrage wird ein neuer Datenschutzauftrag für den Data Lake mit dem nicht registrierten Namespace email_label erstellt. Sie enthält auch den Produktwert für den Data Lake im 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"
}'

Verarbeitung von Löschanfragen

Wenn Experience Platform von Privacy Service eine DELETE-Anfrage erhält, sendet Platform eine Bestätigung an Privacy Service, dass die Anfrage empfangen wurde und die betroffenen Daten zum Löschen markiert wurden. Die Datensätze werden dann innerhalb von sieben Tagen aus dem Data Lake entfernt. Während dieses 7-Tage-Fensters werden die Daten vorläufig gelöscht und stehen somit keinem Platform-Service mehr zur Verfügung.

Wenn Sie auch ProfileService oder identity in die Datenschutzanfrage aufgenommen haben, werden die zugehörigen Daten separat verarbeitet. Weitere Informationen finden Sie im Abschnitt zum Löschen der Anforderungsverarbeitung für Profil .

Nächste Schritte

Durch Lesen dieses Dokuments haben Sie sich mit den wichtigen Konzepten der Verarbeitung von Datenschutzanfragen für den Data Lake vertraut gemacht. Wir empfehlen Ihnen, die Dokumentation in diesem Handbuch weiterzulesen, um Ihr Verständnis hinsichtlich der Verwaltung von Identitätsdaten und Erstellung von Datenschutzaufträgen zu vertiefen.

Anweisungen zur Verarbeitung von Datenschutzanfragen für den Profile-Store finden Sie im Dokument zur Verarbeitung von Datenschutzanfragen für das Echtzeit-Kundenprofil 🔗.

Anhang

Der folgende Abschnitt enthält zusätzliche Informationen zur Verarbeitung von Datenschutzanfragen im Data Lake.

Kennzeichnen verschachtelter Felder vom Typ Zuordnung nested-maps

Beachten Sie, dass es zwei Arten von verschachtelten Feldern des Typs Zuordnung gibt, die keine Datenschutzkennzeichnung unterstützen:

Die Verarbeitung von Datenschutzaufträgen für beide obigen Beispiele schlägt letztendlich fehl. Aus diesem Grund wird empfohlen, verschachtelte Felder vom Typ Zuordnung nicht zum Speichern vertraulicher Kundendaten zu verwenden. Relevante Kundenkennungen sollten bei datensatzbasierten Datensätzen als Nicht-Zuordnungs-Datentyp im identityMap-Feld (selbst ein Feld vom Typ Zuordnung) bzw. bei zeitreihenbasierten Datensätzen im endUserID-Feld gespeichert werden.