Feldbasierte Zuordnung
Bei der feldbasierten Zuordnung geben Sie einen Ereignis-Datensatz sowie die persistente ID (Cookie) und Personen-ID für diesen Datensatz an. Bei der feldbasierten Zuordnung wird versucht, die Personen-ID-Informationen für die Customer Journey Analytics-Datenanalyse bei allen anonymen Ereignissen mit einer bestimmten persistenten ID verfügbar zu machen. Diese Informationen werden aus den Zeilen abgerufen, die eine Personen-ID für diese bestimmte persistente ID haben.
Wenn die Personen-ID-Informationen für ein Ereignis nicht abgerufen werden können, wird stattdessen die persistente ID für dieses (nicht ) verwendet. Daher enthält in einer Datenansicht die mit einer Verbindung“ verknüpft ist, den Datensatz enthält, der für das Zusammenfügen aktiviert ist, die Personen-ID-Komponente entweder den Personen-ID-Wert oder den beständigen ID-Wert auf der Ereignisebene.
Sie können das feldbasierte Stitching verwenden, wenn Sie Customer Journey Analytics als eigenständige Lösung verwenden (ohne Zugriff auf den Experience Platform Identity Service und das zugehörige Identitätsdiagramm). Oder wenn Sie das verfügbare Identitätsdiagramm nicht verwenden möchten.
IdentityMap
Die feldbasierte Zuordnung unterstützt die Verwendung der identityMap-Feldergruppe in folgenden Szenarien:
-
Verwendung der primären Identität in
identityMap-Namespaces zur Definition der persistenten ID:- Wenn mehrere primäre Identitäten in verschiedenen Namespaces gefunden werden, werden die Identitäten in den Namespaces lexikografisch sortiert, und die erste Identität wird ausgewählt.
- Wenn mehrere primäre Identitäten in einem einzigen Namespace gefunden werden, wird die lexikografisch erste primäre Identität ausgewählt, die verfügbar ist.
Im folgenden Beispiel führen die Namespaces und Identitäten zu einer sortierten primären Identitätsliste und schließlich zur ausgewählten Identität.
table 0-row-2 1-row-2 2-row-2 layout-auto html-authored Namespaces Liste der Identitäten ECID code language-none [ {"id": "ecid-3"}, {"id": "ecid-2", "primary": true}, {"id": "ecid-1", "primary": true} ]CCID code language-none [ {"id": "ccid-1"}, {"id": "ccid-2", "primary": true} ]table 0-row-2 1-row-2 layout-auto html-authored Sortierte Identitätsliste Ausgewählte Identität code language-none PrimaryIdentities [ {"id": "ccid-2", "namespace": "CCID"}, {"id": "ecid-1", "namespace": "ECID"}, {"id": "ecid-2", "namespace": "ECID"} ] NonPrimaryIdentities [ {"id": "ccid-1", "namespace": "CCID"}, {"id": "ecid-3", "namespace": "ECID"} ]code language-none "id": "ccid-2", "namespace": "CCID" -
Verwendung des
identityMap-Namespace zum Definieren der persistenten ID, der Personen-ID oder beider:- Wenn in einem
identityMap-Namespace mehrere Werte für eine persistente ID oder Personen-ID gefunden werden, wird der lexikografisch erste verfügbare Wert verwendet. - Namespaces für persistente ID und Personen-ID müssen sich gegenseitig ausschließen.
Im folgenden Beispiel haben Sie „ECID“ als zu verwendenden Namespace ausgewählt. Diese Auswahl führt zu einer sortierten Identitätsliste und schließlich zur ausgewählten Identität.
table 0-row-2 1-row-2 2-row-2 layout-auto html-authored Namespaces Liste der Identitäten ECID code language-none [ {"id": "ecid-3"}, {"id": "ecid-2", "primary": true}, {"id": "ecid-1", "primary": true} ]CCID code language-none [ {"id": "ccid-1"}, {"id": "ccid-2", "primary": true} ]table 0-row-2 1-row-2 layout-auto html-authored Sortierte Identitätsliste Ausgewählte Identität code language-none [ "id": "ecid-1", "id": "ecid-2", "id": "ecid-3" ]code language-none "id": "ecid-1", "namespace": "ECID" - Wenn in einem
Funktionsweise der Zuordnung
Beim Zuordnen werden in einem Datensatz mindestens zwei Datendurchläufe durchgeführt.
-
Live-Zuordnung:: Versucht, bei Eingang jeden Treffer (Ereignis) zuzuordnen. Treffer von Geräten, die neu im Datensatz sind (sich noch nie authentifiziert haben), werden in der Regel nicht auf dieser Ebene zugeordnet. Treffer von bereits erkannten Geräten werden sofort zugeordnet.
-
Wiederholte Zuordnung: Wiederholt Daten basierend auf eindeutigen Kennungen (Personen-IDs). In diesem Schritt werden Treffer von zuvor unbekannten Geräten (persistente IDs) zugeordnet (zu Personen-IDs). Zwei Parameter bestimmen die Wiederholung: Häufigkeit und Lookback-Fenster. Adobe bietet die folgenden Kombinationen dieser Parameter:
- Täglicher Lookback mit täglicher Häufigkeit: Daten werden täglich mit einem 24-Stunden-Lookback-Fenster wiederholt. Diese Option bietet den Vorteil, dass Wiederholungen viel häufiger vorkommen. Nicht authentifizierte Personen müssen sich jedoch am selben Tag authentifizieren, an dem sie Ihre Website besuchen.
- Wöchentlicher Lookback in wöchentlicher Häufigkeit: Die Daten werden einmal wöchentlich mit einem wöchentlichen Lookback-Fenster wiederholt (siehe Optionen). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefassten Zeitraum für die Authentifizierung verfügen. Nicht zugeordnete Daten, die weniger als eine Woche alt sind, werden jedoch erst bei der nächsten wöchentlichen Wiederholung erneut verarbeitet.
- Vierzehntägiger Lookback mit wöchentlicher Häufigkeit: Die Daten werden einmal wöchentlich mit einem zweiwöchentlichen Lookback-Fenster wiederholt (siehe Optionen). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefassten Zeitraum für die Authentifizierung verfügen. Nicht zugeordnete Daten, die weniger als zwei Wochen alt sind, werden jedoch erst bei der nächsten wöchentlichen Wiederholung erneut verarbeitet.
- Monatlicher Lookback mit wöchentlicher Häufigkeit: Daten werden wöchentlich mit einem monatlichen Lookback-Fenster wiederholt (siehe Optionen). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefassten Zeitraum für die Authentifizierung verfügen. Nicht zugeordnete Daten, die weniger als einen Monat alt sind, werden jedoch erst bei der nächsten wöchentlichen Wiederholung erneut verarbeitet.
-
Datenschutz: Wenn datenschutzbezogene Anfragen empfangen werden, muss neben dem Entfernen der angeforderten Identität auch jede Zuordnung dieser Identität zu nicht authentifizierten Ereignissen rückgängig gemacht werden.
note important IMPORTANT Das Verfahren zur Aufhebung der Zuordnung im Rahmen von Datenschutzanfragen ändert sich Anfang 2025. Das aktuelle Verfahren ordnet Ereignisse anhand der neuesten Version bekannter Identitäten neu zu. Diese Neuzuweisung von Ereignissen an eine andere Identität kann unerwünschte rechtliche Folgen haben. Um diesen Bedenken zu begegnen, werden Ereignisse, die Gegenstand der Datenschutzanfrage sind, ab 2025 durch das neue Verfahren zur Aufhebung der Zuordnung mit der persistenten ID aktualisiert.
Daten, die über das Lookback-Fenster hinausgehen, werden nicht wiederholt. Ein Profil muss innerhalb eines gegebenen Lookback-Fensters authentifiziert werden, damit ein nicht authentifizierter Besuch und ein authentifizierter Besuch gemeinsam identifiziert werden können. Sobald ein Gerät erkannt wurde, wird dieses Gerät von diesem Punkt an live zugeordnet.
Schritt 1: Live-Zuordnung
Die Live-Zuordnung versucht bei der Erfassung, jedes Ereignis bekannten Geräten und Kanälen zuzuordnen.
Betrachten Sie das folgende Beispiel, bei dem Bob verschiedene Ereignisse als Teil eines Ereignisdatensatzes aufzeichnet.
Daten, wie sie am Tag der Erfassung auftraten:
| table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 6-row-5 7-row-5 8-row-5 9-row-5 10-row-5 11-row-5 12-row-5 13-row-5 | ||||
|---|---|---|---|---|
| Ereignis | Zeitstempel | Persistente ID (Cookie-ID) | Personen-ID | Resultierende ID (nach der Echtzeit-Zuordnung) |
| 1 | 12.05.2023 12:01 | 246
|
- | 246 |
| 2 | 12.05.2023 12:02 | 246 |
Bob
|
Bob |
| 3 | 12.05.2023 12:03 | 246 |
Bob
|
Bob
|
| 4 | 12.05.2023 12:04 | 246 |
- | Bob |
| 5 | 12.05.2023 12:05 | 246 |
Bob
|
Bob
|
| 6 | 12.05.2023 12:06 | 246 |
- | Bob |
| 7 | 12.05.2023 12:07 | 246 |
Bob
|
Bob |
| 8 | 12.05.2023 12:03 | 3579
|
- | 3579 |
| 9 | 12.05.2023 12:09 | 3579
|
- | 3579 |
| 10 | 12.05.2023 12:02 | 81911
|
- | 81911 |
| 11 | 12.05.2023 12:05 | 81911 |
Bob
|
Bob
|
| 12 | 12.05.2023 12:12 | 81911 |
- | Bob |
| 3 Geräte | 4 Personen:246, Bob, 3579, 81911 |
Sowohl nicht authentifizierte als auch authentifizierte Ereignisse auf neuen Geräten werden (vorübergehend) als separate Personen gezählt. Nicht authentifizierte Ereignisse auf erkannten Geräten werden live zugeordnet.
Die Attribution funktioniert, wenn die Identifizierung der benutzerdefinierten Variablen an ein Gerät gebunden ist. Im obigen Beispiel werden alle Ereignisse mit Ausnahme der Ereignisse 1, 8, 9 und 10 live zugeordnet (sie verwenden alle die Kennung Bob). Die Live-Zuordnung „löst“ die resultierende ID für Ereignis 4, 6 und 12 auf.
Verzögerte Daten (Daten mit einem Zeitstempel älter als 24 Stunden) werden „nach bestem Bemühen“ verarbeitet, wobei die Zuordnung aktueller Daten für die höchste Qualität priorisiert wird.
Schritt 2: Wiederholte Zuordnung
In regelmäßigen Abständen (einmal pro Woche oder einmal pro Tag, je nach ausgewähltem Lookback-Fenster) berechnet die wiederholte Zuordnung historische Daten erneut basierend auf Geräten, die es jetzt erkennt. Wenn ein nicht authentifiziertes Gerät anfänglich Daten sendet und sich dann anmeldet, verknüpft die wiederholte Zuordnung diese nicht authentifizierten Ereignisse mit der richtigen Person.
Die folgende Tabelle stellt dieselben Daten wie oben dar, zeigt jedoch unterschiedliche Zahlen basierend auf der Wiederholung der Daten.
Dieselben Daten nach der Wiederholung:
| table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 layout-auto | |||||
|---|---|---|---|---|---|
| Ereignis | Zeitstempel | Persistente ID (Cookie-ID) | Personen-ID | Resultierende ID (nach der Echtzeit-Zuordnung) | Resultierende ID (nach der Wiederholung) |
| 1 | 12.05.2023 12:01 | 246 |
- | 246 |
Bob |
| 2 | 12.05.2023 12:02 | 246 |
Bob
|
Bob |
Bob
|
| 3 | 12.05.2023 12:03 | 246 |
Bob
|
Bob |
Bob |
| 4 | 12.05.2023 12:04 | 246 |
- | Bob |
Bob |
| 5 | 12.05.2023 12:05 | 246 |
Bob
|
Bob
|
Bob |
| 6 | 12.05.2023 12:06 | 246 |
- | Bob |
Bob |
| 7 | 12.05.2023 12:07 | 246 |
Bob
|
Bob |
Bob |
| 8 | 12.05.2023 12:03 | 3579
|
- | 3579 |
3579 |
| 9 | 12.05.2023 12:09 | 3579
|
- | 3579 |
3579 |
| 10 | 12.05.2023 12:02 | 81911 |
- | 81911 |
Bob |
| 11 | 12.05.2023 12:05 | 81911 |
Bob
|
Bob
|
Bob
|
| 12 | 12.05.2023 12:12 | 81911 |
- | Bob |
Bob |
| 3 Geräte | 4 Personen:246, Bob, 3579, 81911 |
2 Personen::Bob, 3579 |
Die Attribution funktioniert, wenn die Identifizierung der benutzerdefinierten Variablen an ein Gerät gebunden ist. Im obigen Beispiel werden Ereignis 1 und 10 als Ergebnis der Wiederholung zugeordnet, sodass nur Ereignis 8 und 9 nicht zugeordnet sind und die Metrik für Personen (kumulativ) auf 2 reduziert wird.
Schritt 3: Datenschutzanfrage
Wenn Sie eine Datenschutzanfrage erhalten, werden alle Kennungsinformationen, die vom Zuordnungsprozess zum Wert der Personen-ID festgelegt wurden, in allen Datensätzen zu einem persistenten ID-Wert für den Benutzer bzw. die Benutzerin, der bzw. die Gegenstand der Datenschutzanfrage ist, aktualisiert.
Die folgende Tabelle stellt dieselben Daten wie oben dar, zeigt jedoch die Auswirkungen, die eine Datenschutzanfrage für Bob nach der Verarbeitung auf die Daten hat. Die Zeilen, in denen Bob authentifiziert ist, werden entfernt (2, 3, 5, 7 und 11), außerdem wird Bob als Personen-ID für andere Zeilen entfernt.
Dieselben Daten nach einer Datenschutzanfrage für Bob:
| table 0-row-8 1-row-8 2-row-8 3-row-8 4-row-8 5-row-8 6-row-8 7-row-8 8-row-8 9-row-8 10-row-8 11-row-8 12-row-8 13-row-8 | |||||||
|---|---|---|---|---|---|---|---|
| Ereignis | Zeitstempel | Persistente ID (Cookie-ID) | Personen-ID | Resultierende ID (nach der Echtzeit-Zuordnung) | Resultierende ID (nach der Wiederholung) | Personen-ID | Ergebnis-ID (nach Datenschutzanfrage) |
| 1 | 12.05.2023 12:01 | 246 |
- | 246 |
Bob |
- | 246 |
| 2 | 12.05.2023 12:02 | 246 |
Bob
|
Bob |
Bob
|
|
246 |
| 3 | 12.05.2023 12:03 | 246 |
Bob
|
Bob
|
Bob |
|
246 |
| 4 | 12.05.2023 12:04 | 246 |
- | Bob |
Bob |
- | 246 |
| 5 | 12.05.2023 12:05 | 246 |
Bob
|
Bob
|
Bob |
|
246 |
| 6 | 12.05.2023 12:06 | 246 |
- | Bob |
Bob |
- | 246 |
| 7 | 12.05.2023 12:07 | 246 |
Bob
|
Bob |
Bob |
|
246 |
| 8 | 12.05.2023 12:03 | 3579
|
- | 3579 |
3579 |
- | 3579 |
| 9 | 12.05.2023 12:09 | 3579
|
- | 3579 |
3579 |
- | 3579 |
| 10 | 12.05.2023 12:02 | 81911 |
- | 81911 |
Bob |
- | 81911 |
| 11 | 12.05.2023 12:05 | 81911 |
Bob
|
Bob
|
Bob
|
|
81911 |
| 12 | 12.05.2023 12:12 | 81911 |
- | Bob |
Bob |
- | 81911 |
| 3 Geräte | 4 Personen: 246, Bob, 3579, 81911 |
2 Personen: Bob, 3579 |
3 Personen:246, 3579, 81911 |
Voraussetzungen
Die folgenden Voraussetzungen gelten speziell für feldbasierte Zuordnung:
-
Der Ereignisdatensatz in Adobe Experience Platform, auf den Sie eine Zuordnung anwenden möchten, muss zwei Spalten aufweisen, die die Identifizierung von Profilen erleichtern:
- Eine persistente ID, eine Kennung, die in jeder Zeile vorhanden ist. Beispielsweise eine Besucher-ID, die von einer Adobe Analytics AppMeasurement-Bibliothek generiert wurde, oder eine vom Adobe Experience Platform Identity Service generierte ECID.
- Eine Personen-ID, eine Kennung, die nur in einigen Zeilen vorhanden ist. Beispielsweise ein gehashter Benutzername oder eine gehashte E-Mail-Adresse, wenn sich ein Profil authentifiziert. Sie können praktisch jede gewünschte Kennung verwenden. Beim Zuordnen wird davon ausgegangen, dass dieses Feld die tatsächlichen Informationen der Personen-ID enthält. Um die besten Ergebnisse beim Zuordnen zu erzielen, sollte eine Personen-ID mindestens einmal für jede persistente ID innerhalb der Ereignisse des Datensatzes gesendet werden. Wenn Sie diesen Datensatz in eine Customer Journey Analytics-Verbindung einbeziehen möchten, sollten die anderen Datensätze auch eine ähnliche gemeinsame Kennung haben.
Einschränkungen
Die folgenden Einschränkungen gelten speziell für die feldbasierte Zuordnung:
- Die aktuellen Funktionen zur Neuzuweisung sind auf einen Schritt beschränkt (persistente ID zu Personen-ID). Eine mehrstufige Neuzuweisung wird nicht unterstützt, beispielsweise persistente ID zu Personen-ID und dann zu einer anderen Personen-ID.
- Wenn mehrere Personen ein Gerät gemeinsam nutzen und die Gesamtzahl der Transitionen zwischen den Benutzern 50.000 überschreitet, stoppt Customer Journey Analytics das Zusammenfügen von Daten für dieses Gerät.
- Benutzerdefinierte ID-Maps, die in Ihrem Unternehmen verwendet werden, werden nicht unterstützt.
- Bei der Zuordnung ist die Groß-/Kleinschreibung zu beachten. Für Datensätze, die über den Analytics-Quell-Connector generiert werden, empfiehlt Adobe die Prüfung aller VISTA-Regeln oder Verarbeitungsregeln, die für das Personen-ID-Feld gelten. Mit dieser Prüfung wird sichergestellt, dass keine dieser Regeln neue Formen derselben ID einführt. So sollten Sie beispielsweise sicherstellen, dass keine VISTA- oder Verarbeitungsregeln dafür sorgen, dass im Feld für die Personen-ID nur für einen Teil der Ereignisse Kleinschreibung verwendet wird.
- Bei der Zuordnung werden Felder nicht kombiniert oder verkettet.
- Das Feld für die Personen-ID sollte nur einen ID-Typ enthalten (IDs aus einem einzigen Namespace). Das Feld für die Personen-ID sollte beispielsweise keine Kombination aus Anmelde-IDs und E-Mail-IDs enthalten.
- Wenn mehrere Ereignisse mit demselben Zeitstempel für dieselbe persistente ID auftreten, jedoch unterschiedliche Werte im Feld für die Personen-ID vorliegen, wird bei der Zuordnung die ID nach alphabetischer Reihenfolge ausgewählt. Wenn also eine persistente ID A zwei Ereignisse mit demselben Zeitstempel hat und eines der Ereignisse „Bob“ und das andere „Ann“ angibt, wählt die Zuordnung „Ann“ aus.
- Seien Sie vorsichtig bei Szenarien, in denen die Personen-IDs Platzhalterwerte enthalten, z. B.
Undefined. Weitere Informationen finden Sie unter Häufig gestellte Fragen. - Sie können nicht denselben Namespace sowohl für die persistente ID als auch für die Personen-ID verwenden. Die Namespaces müssen sich gegenseitig ausschließen.