Show Menu
THEMEN×

Verarbeitung von Datenschutzanfragen im Data Lake

Adobe Experience Platform Privacy Service verarbeitet Anfragen von Kunden, um auf ihre personenbezogenen Daten zuzugreifen, sie Opt-out zu verkaufen oder sie zu löschen, wie in den gesetzlichen und organisatorischen Datenschutzbestimmungen festgelegt.
In diesem Dokument werden wesentliche Konzepte zur Verarbeitung von Datenschutzanforderungen für im Data Lake gespeicherte Kundendaten behandelt.

Erste Schritte

Es wird empfohlen, die folgenden Experience Platformen zu verstehen, bevor Sie dieses Handbuch lesen:
  • Privacy Service : Verwaltet Kundenanforderungen für den Zugriff auf, die Einstellung des Verkaufs oder das Löschen ihrer personenbezogenen Daten in allen Adobe Experience Cloud-Anwendungen.
  • Katalogdienst : Das Datensatzsystem für die Datenposition und -linie innerhalb der Experience Platform. Stellt eine API bereit, mit der die Metadaten des Datensatzes aktualisiert werden können.
  • Erlebnis-Datenmodell (XDM)-System : Das standardisierte Framework, mit dem Experience Platform Kundenerlebnisdaten organisiert.
  • Identitätsdienst : Löst die grundlegende Herausforderung, die sich aus der Fragmentierung von Kundenerlebnisdaten ergibt, indem Identitäten zwischen Geräten und Systemen überbrückt werden.

Identitäts-Namensräume

Der Identitätsdienst für Adobe Experience Platformen überbrückt Identitätsdaten von Kunden über Systeme und Geräte hinweg. Der Identitätsdienst nutzt Identitätskennungen , um einen Kontext für Identitätswerte bereitzustellen, indem er sie mit ihrem System der Herkunft verknüpft. Ein Namensraum kann ein allgemeines Konzept wie eine E-Mail-Adresse ("E-Mail") oder die Identität einer bestimmten Anwendung zuordnen, z. B. einer Adobe-Advertising Cloud-ID ("AdCloud") oder einer Adobe Target-ID ("TNTID").
Der Identitätsdienst verwaltet einen Store von global definierten (Standard-) und benutzerdefinierten (benutzerdefinierten) Identitäts-Namensräumen. Standardmäßige Namensraum stehen für alle Unternehmen zur Verfügung (z. B. "E-Mail"und "ECID"), während Ihr Unternehmen benutzerdefinierte Namensraum erstellen kann, die den jeweiligen Anforderungen entsprechen.
Weitere Informationen zu Identitäts-Namensräumen in der Experience Platform finden Sie in der Übersicht über den Identitäts-Namensraum .

Hinzufügen von Identitätsdaten zu Datensätzen

Beim Erstellen von Datenschutzanforderungen für den Data Lake müssen für jeden einzelnen Kunden gültige Identitätswerte (und die zugehörigen Namensraum) angegeben werden, um die Daten zu finden und entsprechend zu verarbeiten. Daher müssen alle Datensätze, die Datenschutzanforderungen unterliegen, einen Identitätsdeskriptor in ihrem zugehörigen XDM-Schema enthalten.
Datensätze, die auf Schemas basieren, die keine Identitätsdeskriptordaten unterstützen (z. B. Ad-hoc-Datensätze), können derzeit nicht in Datenschutzanforderungen verarbeitet werden.
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 mit dem nächsten Abschnitt fortfahren.
Berücksichtigen Sie bei der Entscheidung, welche Schema-Felder als Identitäten festgelegt werden sollen, die Einschränkungen bei der Verwendung verschachtelter Kartenfelder .
Es gibt zwei Methoden zum Hinzufügen eines Identitätsdeskriptors zu einem DataSet-Schema:

Verwenden der Benutzeroberfläche

In der Benutzeroberfläche "Experience Platform"können Sie mit dem Arbeitsbereich " Schemas "Ihre vorhandenen XDM-Schema bearbeiten. Um einem Schema einen Identitätsdeskriptor hinzuzufügen, wählen Sie das Schema in der Liste aus und befolgen Sie die Schritte zum Festlegen eines Schema-Felds als Identitätsfeld im Schema-Editor-Lernprogramm.
Nachdem Sie die entsprechenden Felder im Schema als Identitätsfelder festgelegt haben, können Sie mit dem nächsten Abschnitt zum Senden von Datenschutzanforderungen fortfahren.

Verwenden der API

In diesem Abschnitt wird davon ausgegangen, dass Sie den eindeutigen URI-ID-Wert des XDM-Schemas Ihres Datensatzes kennen. Wenn Sie diesen Wert nicht kennen, können Sie ihn mithilfe der Katalogdienst-API abrufen. Nachdem Sie den Abschnitt "Erste Schritte "im Entwicklerhandbuch gelesen haben, führen Sie die Schritte aus, die unter zur Auflistung oder Suche von Katalogobjekten nach dem Datensatz beschrieben werden. Die Schema-ID finden Sie unter schemaRef.id
Dieser Abschnitt enthält Aufrufe der Schema Registry API. Wichtige Informationen zur Verwendung der API, einschließlich der Kenntnisse über Ihre {TENANT_ID} und das Konzept der Container, finden Sie im Abschnitt Erste Schritte im Entwicklerhandbuch.
Sie können dem XDM-Schema eines Datasets einen Identitätsdeskriptor hinzufügen, indem Sie eine POST-Anforderung an den /descriptors Endpunkt in der Schema Registry-API senden.
API-Format
POST /descriptors

Anfrage
Die folgende Anforderung definiert einen Identitätsdeskriptor für ein "E-Mail-Adresse"-Feld in einem Beispiel-Schema.
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
      }'

Eigenschaft
Beschreibung
@type
Der Typ des zu erstellenden Deskriptors. Bei Identitätsdeskriptoren muss der Wert "xdm:descriptorIdentity"lauten.
xdm:sourceSchema
Die eindeutige URI-ID des XDM-Schemas Ihres Datensatzes.
xdm:sourceVersion
Die Version des XDM-Schemas, die in xdm:sourceSchema .
xdm:sourceProperty
Der Pfad zum Schema, auf das der Deskriptor angewendet wird.
xdm:namespace
Einer der vom Privacy Service erkannten Identitäts-Namensraum oder ein von Ihrem Unternehmen definierter benutzerspezifischer Namensraum.
xdm:property
Entweder "xdm:id"oder "xdm:code", je nach Namensraum, der unter xdm:namespace verwendet wird.
xdm:isPrimary
Ein optionaler boolescher Wert. Wenn "true", bedeutet dies, dass das Feld eine primäre Identität ist. Schema dürfen nur eine primäre Identität enthalten. Die Standardeinstellung lautet "false"(falsch), wenn sie nicht enthalten ist.
Antwort
Eine erfolgreiche Antwort gibt HTTP-Status 201 (Erstellt) und 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"
}

Einreichen von Anträgen

In diesem Abschnitt wird beschrieben, wie Sie Datenschutzanforderungen für den Data Lake formatieren. Es wird dringend empfohlen, die Dokumentation zur Benutzeroberfläche des Privacy Service oder zur Privacy Service-API zu lesen, um die Grundlagen zum Senden eines Datenschutzauftrags zu erläutern, einschließlich der richtigen Formatierung gesendeter Benutzeridentitätsdaten in Anforderungs-Nutzdaten.
Im folgenden Abschnitt wird beschrieben, wie Sie mithilfe der Benutzeroberfläche oder API des Privacy Service Datenschutzanforderungen für den Data Lake durchführen.

Verwenden der Benutzeroberfläche

Wählen Sie beim Erstellen von Auftragsanforderungen in der Benutzeroberfläche AEP Data Lake und/oder Profil unter Products aus, um Aufträge für Daten zu verarbeiten, die im Data Lake bzw. im Real-Time Customer Profil gespeichert werden.

Verwenden der API

Beim Erstellen von Auftragsanforderungen in der API müssen alle userIDs bereitgestellten Aufträge einen bestimmten namespace und type je nach Datenspeicher verwenden, für den sie gelten. IDs für den Data Lake müssen für ihren type Wert "nicht registriert"und einen namespace Wert verwenden, der mit einer der Datenschutzbeschriftungen übereinstimmt, die den entsprechenden Datensätzen hinzugefügt wurden.
Darüber hinaus muss das include Array der Anforderungs-Nutzlast die Produktwerte für die verschiedenen Datenspeicher enthalten, an die die Anforderung gesendet wird. Bei Anforderungen an den Data Lake muss das Array den Wert "aepDataLake"enthalten.
Die folgende Anforderung erstellt einen neuen Datenschutzauftrag für den Data Lake mit dem nicht registrierten Namensraum "email_label". Er enthält außerdem den Produktwert für den Data Lake im 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"
}'

Anforderungsverarbeitung löschen

Wenn die Experience Platform eine Löschanfrage von Privacy Service erhält, sendet die Platform eine Bestätigung an den Privacy Service, dass die Anforderung eingegangen ist 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 siebentägigen Fensters werden die Daten weich gelöscht und stehen daher keinem Platform-Dienst zur Verfügung.
In zukünftigen Versionen sendet Platform eine Bestätigung an Privacy Service, nachdem die Daten physisch gelöscht wurden.

Nächste Schritte

Durch das Lesen dieses Dokuments wurden Sie zu den wichtigen Konzepten der Verarbeitung von Datenschutzanforderungen für den Data Lake vorgestellt. Es wird empfohlen, die Dokumentation in diesem Handbuch weiter zu lesen, um Ihr Verständnis für die Verwaltung von Identitätsdaten und die Erstellung von Datenschutzaufträgen zu vertiefen.
Anweisungen zur Verarbeitung von Datenschutzanforderungen für den Profil Store finden Sie im Dokument zur Verarbeitung von Datenschutzanfragen für Echtzeit-Kundendaten .

Anhang

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

Bezeichnen verschachtelter Kartenfelder

Beachten Sie, dass es zwei Arten von verschachtelten Kartenfeldern gibt, die keine Datenschutzkennzeichnung unterstützen:
  • Ein Feld vom Typ "map"in einem Feld vom Typ "array"
  • Ein Feld vom Typ "Map"in einem anderen Feld vom Typ "map"
Die Verarbeitung von Datenschutzaufträgen für eines der beiden obigen Beispiele schlägt schließlich fehl. Aus diesem Grund wird empfohlen, verschachtelte Felder vom Typ "Map"nicht zum Speichern von Daten privater Kunden zu verwenden. Relevante Kunden-IDs sollten als Nicht-Map-Datentyp innerhalb des identityMap Felds (selbst ein Zuordnungsfeld) für Datensatzdatasets oder als endUserID Feld für zeitreihenbasierte Datensätze gespeichert werden.