Stitching
Die Identitätszuordnung (oder einfach das Stitching) ist eine leistungsstarke Funktion, die die Eignung eines Ereignis-Datensatzes für die kanalübergreifende Analyse erhöht. Die kanalübergreifende Analyse ist ein Hauptanwendungsfall, den Customer Journey Analytics handhaben kann. So können Sie Berichte basierend auf einer gemeinsamen Kennung (Personen-ID) nahtlos mit mehreren Datensätzen aus verschiedenen Kanälen kombinieren und ausführen.
Wenn Sie Datensätze mit ähnlichen Personen-IDs kombinieren, wird die Attribution geräte- und kanalübergreifend übernommen. Beispiel: Ein Benutzer besucht Ihre Site zum ersten Mal über eine Werbeanzeige auf seinem Desktop. Dieser Benutzer stößt bei seiner Bestellung auf ein Problem und ruft dann Ihren Kundendienst an, um das Problem zu beheben. Mit der kanalübergreifenden Analyse können Sie Callcenter-Ereignisse der Anzeige zuordnen, auf die sie ursprünglich geklickt haben.
Leider sind nicht alle ereignisbasierten Datensätze, die Teil Ihrer Customer Journey Analytics-Verbindung sind, ausreichend mit Daten gefüllt, um diese Attribution standardmäßig zu unterstützen. Insbesondere verfügen Web- oder mobile-basierte Erlebnisdatensätze häufig nicht über tatsächliche Personen-ID-Informationen für alle Ereignisse.
Die Zuordnung ermöglicht die Neuzuordnung von Identitäten in den Zeilen eines Datensatzes und stellt sicher, dass die Personen-ID (zugeordnete ID) für jedes Ereignis verfügbar ist. Beim Zuordnen werden Benutzerdaten aus authentifizierten und nicht authentifizierten Sitzungen untersucht, um den allgemeinen Wert für die vorübergehende ID (Personen-ID) zu ermitteln, der als zugeordnete ID verwendet werden kann. Diese Neuzuweisung ermöglicht die Auflösung verschiedener Datensätze zu einer einzigen zugeordneten ID, die auf der Personenebene und nicht auf der Geräte- oder Cookie-Ebene analysiert werden kann.
Customer Journey Analytics unterstützt zwei Arten von Stitching: feldbasiertes Stitching und grafisches Stitching.
Voraussetzungen
Stellen Sie vor der Verwendung von Stitching sicher, dass Ihr Unternehmen wie folgt vorbereitet ist:
-
Die Zuordnung umfasst das Zusammenführen authentifizierter und nicht authentifizierter Benutzerdaten. Stellen Sie sicher, dass Sie die geltenden Gesetze und Vorschriften einhalten, einschließlich der Erlangung der erforderlichen Endbenutzerberechtigungen, bevor Sie die Zuordnung für einen Ereignis-Datensatz aktivieren. Weitere Informationen finden Sie unter Definieren von Identitätsfeldern in der Benutzeroberfläche.
-
Importieren Sie die gewünschten Daten in Adobe Experience Platform:
- Informationen zu Adobe Analytics-Daten finden Sie unter Verwenden von Adobe Analytics Report Suite-Daten in Customer Journey Analytics.
- Informationen zu anderen Datentypen finden Sie unter Erstellen eines Schemas und Aufnehmen von Daten in der Adobe Experience Platform-Dokumentation.
Sie profitieren von einer kanalübergreifenden Analyse, wenn Sie einen oder mehrere Ihrer zugeordneten Datensätze mit anderen Datensätzen, z. B. Callcenter-Daten, kombinieren, um Ihre Customer Journey Analytics-Verbindung zu definieren. Bei dieser Verbindungskonfiguration wird davon ausgegangen, dass diese anderen Datensätze bereits in jeder Zeile eine Personen-ID enthalten, die der zugeordneten ID ähnelt.
Einschränkungen
-
Die Verwendung von
identityMap
als beständige ID wird nicht unterstützt. Sie müssen eine bestimmte Kennung im Datensatz (z. B.ECID
) als beständige ID definieren. -
Wenden Sie alle Änderungen, die Sie an dem Quellereignis-Datensatzschema vornehmen, auch auf das neue zugeordnete Datensatzschema an. Andernfalls wird der zugeordnete Datensatz beschädigt.
-
Wenn Sie den Quelldatensatz entfernen, stoppt der zugeordnete Datensatz die Verarbeitung und wird vom System entfernt.
-
Datennutzungsbezeichnungen werden nicht automatisch in das zugeordnete Datensatzschema übertragen. Wenn Sie Datennutzungsbezeichnungen auf das Quelldatensatzschema angewendet haben, müssen Sie diese Datennutzungsbezeichnungen manuell auf das zugeordnete Datensatzschema anwenden. Weitere Informationen finden Sie unter Verwalten von Datennutzungsbezeichnungen in Experience Platform .
Das Stitching ist eine innovative und zuverlässige Funktion, die jedoch Einschränkungen hinsichtlich der Verwendung aufweist.
- Es werden nur Ereignis-Datensätze unterstützt. Andere Datensätze, wie beispielsweise Lookup-Datensätze, werden nicht unterstützt.
- Beim Stitching wird das für das Stitching verwendete Feld in keiner Weise umgewandelt. Beim Zuordnen wird der Wert im angegebenen Feld verwendet, da er im nicht zugeordneten Datensatz im Data Lake vorhanden ist.
- Beim Zuordnen wird zwischen Groß- und Kleinschreibung unterschieden. Wenn beispielsweise manchmal das Wort "Bob"im Feld erscheint und manchmal das Wort "BOB"erscheint, werden diese IDs als zwei separate Personen behandelt.
Vergewissern Sie sich, dass Sie die Zuordnung nicht mit Folgendem verwechseln:
-
Die Zusammenführung von zwei oder mehr Datensätzen. Die Zuordnung gilt nur für einen Datensatz. Die Zusammenführung von Datensätzen erfolgt durch Einrichtung einer Customer Journey Analytics-Verbindung und Auswahl derselben Personen-ID für die ausgewählten Datensätze in der Verbindung.
-
Der Join zweier Datensätze. Unter Customer Journey Analytics wird häufig ein Join für Suchen oder Klassifizierungen in Analysis Workspace verwendet. Obwohl das Stitching die Join-Funktion verwendet, umfasst der Prozess selbst mehr als nur Joins.
Feldbasiertes Stitching
Sie geben einen Ereignis-Datensatz sowie die beständige ID (Cookie) und die vorübergehende ID (Personen-ID) für diesen Datensatz an. Beim feldbasierten Stitching wird im neuen zugeordneten Datensatz eine neue Spalte für die zugeordnete ID erstellt und diese Spalte für die zugeordnete ID basierend auf Zeilen mit einer vorübergehenden ID für diese bestimmte beständige ID aktualisiert.
Sie können feldbasiertes Stitching verwenden, wenn Sie Customer Journey Analytics als eigenständige Lösung verwenden (ohne Zugriff auf den Experience Platform Identity-Dienst und das zugehörige Identitätsdiagramm). Oder wenn Sie das verfügbare Identitätsdiagramm nicht verwenden möchten.
Funktionsweise der feldbasierten Zuordnung
Durch die Zuordnung werden mindestens zwei Durchgänge an Daten in einem bestimmten Datensatz durchgeführt.
-
Live-Stitching: versucht, jeden Treffer (Ereignis) beim Eintreten zuzuordnen. Treffer von Geräten, die dem Datensatz "neu"sind (sich noch nie authentifiziert haben), werden normalerweise nicht auf dieser Ebene zugeordnet. Treffer von bereits erkannten Geräten werden sofort zugeordnet.
-
Wiederholungszuordnung wiedergeben: wiederholt Daten basierend auf eindeutigen Kennungen (vorübergehenden IDs), die gelernt wurden. In dieser Phase werden Treffer von zuvor unbekannten Geräten (beständigen IDs) zugeordnet (zu vorübergehenden IDs). Die Wiederholung wird durch zwei Parameter bestimmt: frequency und Lookback-Fenster. Adobe bietet die folgenden Kombinationen dieser Parameter:
- Täglicher Lookback mit täglicher Häufigkeit: Die Daten werden täglich mit einem 24-Stunden-Lookback-Fenster wiederholt. Diese Option bietet den Vorteil, dass Wiederholungen viel häufiger vorkommen. Nicht authentifizierte Besucher müssen sich jedoch an dem Tag authentifizieren, an dem sie Ihre Website besuchen.
- Wöchentliches Lookback mit wöchentlicher Häufigkeit: Die Daten werden einmal wöchentlich mit einem wöchentlichen Lookback-Fenster wiederholt (siehe options). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefasst 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.
- Zweiwöchiges Lookback mit wöchentlicher Häufigkeit: Daten werden wöchentlich einmal mit einem zweiwöchigen Lookback-Fenster wiederholt (siehe options). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefasst 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 options). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefasst 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 nicht nur die angeforderte Identität entfernt werden, sondern auch die Zuordnung dieser Identität zu nicht authentifizierten Ereignissen rückgängig gemacht werden.
note important IMPORTANT Die Aufhebung der Zuordnung als Teil von Datenschutzanfragen wird Anfang 2025 geändert. Der aktuelle Auftrennungsprozess löst Ereignisse anhand der neuesten Version bekannter Identitäten zurück. Diese Umbenennung von Ereignissen zu einer anderen Identität könnte unerwünschte rechtliche Folgen haben. Um diese Bedenken auszuräumen, aktualisiert der neue Auftrennungsprozess ab 2025 Ereignisse, die Gegenstand der Datenschutzanfrage sind, mit der beständigen ID.
Daten, die über das Lookback-Fenster hinausgehen, werden nicht wiederholt. Ein Besucher muss sich in einem gegebenen Lookback-Fenster authentifizieren, damit ein nicht authentifizierter Besuch und ein authentifizierter Besuch gemeinsam identifiziert werden können. Sobald ein Gerät erkannt wurde, wird es von diesem Punkt an live zugeordnet.
Schritt 1: Live-Stitching
Die Live-Zuordnung versucht, jedes Ereignis bei der Erfassung bekannten Geräten und Kanälen zuzuordnen.
Im folgenden Beispiel zeichnet Bob verschiedene Ereignisse als Teil eines Ereignis-Datensatzes auf.
Daten, wie sie am Tag der Erfassung erschienen:
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 | Beständige ID (Cookie-ID) | Verlaufs-ID (Anmelde-ID) | Zugeordnete ID (nach der Live-Zuordnung) |
1 | 12.05.2023 12:01 | 246
|
– | 246 |
2 | 2023-05-12 12:02 | 246 |
Bob
|
Bob |
3 | 2023-05-12 12:03 | 246 |
Bob
|
Bob
|
4 | 2023-05-12 12:04 | 246 |
– | Bob |
5 | 2023-05-12 12:05 | 246 |
Bob
|
Bob
|
6 | 2023-05-12 12:06 | 246 |
– | Bob |
7 | 2023-05-12 12:07 | 246 |
Bob
|
Bob |
8 | 2023-05-12 12:03 | 3579
|
– | 3579 |
9 | 2023-05-12 12:09 | 3579
|
– | 3579 |
10 | 2023-05-12 12:02 | 81911
|
– | 81911 |
11 | 2023-05-12 12:05 | 81911 |
Bob
|
Bob
|
12 | 2023-05-12 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 identifizierende benutzerdefinierte Variable 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 zugeordnete ID für die Ereignisse 4, 6 und 12 auf.
Verzögerte Daten (Daten mit einem Zeitstempel über 24 Stunden) werden nach bestem Wissen und Gewissen verarbeitet, wobei die Zuordnung aktueller Daten für die höchste Qualität priorisiert wird.
Schritt 2: Wiederholungszuordnung
In regelmäßigen Abständen (einmal pro Woche oder einmal pro Tag, je nach ausgewähltem Lookback-Fenster) berechnet die Wiederholungszuordnung historische Daten basierend auf Geräten, die sie jetzt erkennt, neu. Wenn ein Gerät anfänglich Daten sendet, ohne authentifiziert zu sein, und sich dann anmeldet, werden diese nicht authentifizierten Ereignisse bei der Wiederholungszuordnung der richtigen Person zugeordnet.
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 | Beständige ID (Cookie-ID) | Verlaufs-ID (Anmelde-ID) | Zugeordnete ID (nach der Live-Zuordnung) | Zugeordnete ID (nach der Wiederholung) |
1 | 12.05.2023 12:01 | 246 |
– | 246 |
Bob |
2 | 2023-05-12 12:02 | 246 |
Bob
|
Bob |
Bob
|
3 | 2023-05-12 12:03 | 246 |
Bob
|
Bob
|
Bob |
4 | 2023-05-12 12:04 | 246 |
– | Bob |
Bob |
5 | 2023-05-12 12:05 | 246 |
Bob
|
Bob
|
Bob |
6 | 2023-05-12 12:06 | 246 |
– | Bob |
Bob |
7 | 2023-05-12 12:07 | 246 |
Bob
|
Bob |
Bob |
8 | 2023-05-12 12:03 | 3579
|
– | 3579 |
3579 |
9 | 2023-05-12 12:09 | 3579
|
– | 3579 |
3579 |
10 | 2023-05-12 12:02 | 81911 |
– | 81911 |
Bob |
11 | 2023-05-12 12:05 | 81911 |
Bob
|
Bob
|
Bob
|
12 | 2023-05-12 12:12 | 81911 |
– | Bob |
Bob |
3 Geräte | 4 Personen:246 , Bob , 3579 , 81911 |
2 Personen:Bob , 3579 |
Die Attribution funktioniert, wenn die identifizierende benutzerdefinierte Variable an ein Gerät gebunden ist. Im obigen Beispiel werden die Ereignisse 1 und 10 als Ergebnis der Wiederholung zugeordnet, wobei nur die Ereignisse 8 und 9 aufgetrennt bleiben. und die (kumulative) Personenzahl auf 2 zu reduzieren.
Schritt 3: Datenschutzanfrage
Wenn Sie eine Datenschutzanfrage erhalten, wird die zugeordnete ID in allen Datensätzen für den Benutzer gelöscht, der der Datenschutzanfrage unterliegt.
Die folgende Tabelle stellt dieselben Daten wie oben dar, zeigt jedoch die Auswirkungen einer Datenschutzanfrage für Bob auf die Daten nach deren Verarbeitung. Die Zeilen, in denen Bob authentifiziert ist, werden entfernt (2, 3, 5, 7 und 11) sowie Bob als vorübergehende 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 | Beständige ID (Cookie-ID) | Verlaufs-ID (Anmelde-ID) | Zugeordnete ID (nach der Live-Zuordnung) | Zugeordnete ID (nach der Wiederholung) | Verlaufs-ID (Anmelde-ID) | Zugeordnete ID (nach Datenschutzanfrage) |
1 | 12.05.2023 12:01 | 246 |
– | 246 |
Bob |
– | 246 |
2 | 2023-05-12 12:02 | 246 |
Bob | Bob |
Bob
|
246 |
|
3 | 2023-05-12 12:03 | 246 |
Bob | Bob
|
Bob |
246 |
|
4 | 2023-05-12 12:04 | 246 |
– | Bob |
Bob |
– | 246 |
5 | 2023-05-12 12:05 | 246 |
Bob | Bob
|
Bob |
246 |
|
6 | 2023-05-12 12:06 | 246 |
– | Bob |
Bob |
– | 246 |
7 | 2023-05-12 12:07 | 246 |
Bob
|
Bob |
Bob |
246 |
|
8 | 2023-05-12 12:03 | 3579
|
– | 3579 |
3579 |
– | 3579 |
9 | 2023-05-12 12:09 | 3579
|
– | 3579 |
3579 |
– | 3579 |
10 | 2023-05-12 12:02 | 81911 |
– | 81911 |
Bob |
– | 81911 |
11 | 2023-05-12 12:05 | 81911 |
Bob
|
Bob
|
Bob
|
81911 |
|
12 | 2023-05-12 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 feldbasiertes Stitching:
-
Der Ereignisdatensatz in Adobe Experience Platform, auf den Sie die Zuordnung anwenden möchten, muss über zwei Spalten verfügen, mit denen Besucher identifiziert werden können:
- Eine beständige ID, eine Kennung, die in jeder Zeile verfügbar ist. Beispielsweise eine Besucher-ID, die von einer Adobe Analytics-AppMeasurement-Bibliothek generiert wurde, oder eine ECID, die vom Adobe Experience Platform Identity-Dienst generiert wurde.
- Eine vorübergehende ID, eine Kennung, die nur für einige Zeilen verfügbar ist. Beispiel: ein/e gehashte/r Benutzername oder E-Mail-Adresse, wenn sich ein Besucher authentifiziert. Sie können praktisch jede beliebige Kennung verwenden. Beim Stitching wird dieses Feld für die tatsächlichen Personen-ID-Informationen berücksichtigt. Für optimale Zuordnungsergebnisse sollte für jede beständige ID mindestens einmal innerhalb der Ereignisse des Datensatzes eine vorübergehende ID gesendet werden. Wenn Sie diesen Datensatz in eine Customer Journey Analytics-Verbindung einschließen möchten, sollten die anderen Datensätze ebenfalls eine ähnliche gemeinsame Kennung aufweisen.
-
Beide Spalten (beständige ID und vorübergehende ID) müssen als Identitätsfeld mit einem Identitäts-Namespace im Schema für den Datensatz definiert werden, den Sie zuordnen möchten. Bei Verwendung der Identitätszuordnung in Real-time Customer Data Platform müssen Sie mithilfe der
identityMap
-Feldergruppe weiterhin Identitätsfelder mit einem Identitäts-Namespace hinzufügen. Diese Identifizierung von Identitätsfeldern ist erforderlich, da das Customer Journey Analytics-Stitching die FeldergruppeidentityMap
nicht unterstützt. Legen Sie beim Hinzufügen eines Identitätsfelds zum Schema und bei Verwendung der FeldergruppeidentityMap
das zusätzliche Identitätsfeld nicht als primäre Identität fest. Das Festlegen eines zusätzlichen Identitätsfelds als primäre Identität behindert die für Real-time Customer Data Platform verwendete FeldgruppeidentityMap
.
Einschränkungen
Die folgenden Einschränkungen gelten speziell für feldbasiertes Stitching:
- Die aktuellen Funktionen zur Neuzuweisung sind auf einen Schritt beschränkt (beständige ID auf vorübergehende ID). Eine mehrstufige Neuzuweisung wird nicht unterstützt, beispielsweise beständige ID zu vorübergehender ID und dann zu einer weiteren vorübergehenden ID.
- Wenn ein Gerät von mehreren Personen gemeinsam genutzt wird und die Gesamtzahl der Übergänge zwischen Benutzern 50.000 überschreitet, stoppt Customer Journey Analytics die Zuordnung von Daten für dieses Gerät.
- Benutzerdefinierte ID-Maps, die in Ihrem Unternehmen verwendet werden, werden nicht unterstützt.
- Beim Stitching wird zwischen Groß- und Kleinschreibung unterschieden. Für Datensätze, die über den Analytics-Quell-Connector generiert werden, empfiehlt Adobe die Überprüfung aller VISTA-Regeln oder Verarbeitungsregeln, die für das vorübergehende ID-Feld gelten. Diese Überprüfung stellt sicher, 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 vorübergehende ID nur für einen Teil der Ereignisse Kleinschreibung verwendet wird.
- Beim Stitching werden keine Felder kombiniert oder verkettet.
- Das Feld für die vorübergehende ID sollte einen einzelnen ID-Typ (IDs aus einem einzelnen Namespace) enthalten. Das Feld für die vorübergehende ID sollte beispielsweise keine Kombination aus Anmelde-IDs und E-Mail-IDs enthalten.
- Wenn mehrere Ereignisse mit demselben Zeitstempel für dieselbe beständige ID auftreten, aber unterschiedliche Werte im Feld der vorübergehenden ID vorhanden sind, wird bei der Zuordnung die ID basierend auf der alphabetischen Reihenfolge ausgewählt. Wenn also eine beständige ID A zwei Ereignisse mit demselben Zeitstempel aufweist und eines der Ereignisse "Bob"und das andere "Ann"angibt, wählt "Zuordnen"Ann.
- Seien Sie vorsichtig bei Szenarien, in denen die vorübergehenden IDs Platzhalterwerte enthalten, z. B.
Undefined
. Weitere Informationen finden Sie in den FAQ .
Grafikbasierte Zuordnung
Sie geben einen Ereignis-Datensatz sowie die beständige ID (Cookie) und den Namespace der vorübergehenden ID (Personen-ID) für diesen Datensatz an. Durch die Diagrammbasierte Zuordnung wird eine neue Spalte für die zugeordnete ID im neuen zugeordneten Datensatz erstellt. Anschließend verwendet die beständige ID, um das Identitätsdiagramm mithilfe des angegebenen Namespace vom Experience Platform Identity-Dienst abzurufen, um die zugeordnete ID zu aktualisieren.
So funktioniert das grafikbasierte Stitching
Durch die Zuordnung werden mindestens zwei Durchgänge an Daten in einem bestimmten Datensatz durchgeführt.
-
Live-Stitching: versucht, jeden eingehenden Treffer (Ereignis) zuzuordnen, indem die beständige ID verwendet wird, um die vorübergehende ID für den ausgewählten Namespace nachzuschlagen, indem das Identitätsdiagramm abgefragt wird. Wenn die vorübergehende ID aus der Suche verfügbar ist, wird diese vorübergehende ID sofort zugeordnet.
-
Wiederholte Zuordnung wiedergeben: wiederholt Daten basierend auf aktualisierten Identitäten aus dem Identitätsdiagramm. In dieser Phase werden Treffer von zuvor unbekannten Geräten (beständigen IDs) zugeordnet, da das Identitätsdiagramm die Identität für einen Namespace aufgelöst hat. Die Wiederholung wird durch zwei Parameter bestimmt: frequency und Lookback-Fenster. Adobe bietet die folgenden Kombinationen dieser Parameter:
- Täglicher Lookback mit täglicher Häufigkeit: Die Daten werden täglich mit einem 24-Stunden-Lookback-Fenster wiederholt. Diese Option bietet den Vorteil, dass Wiederholungen viel häufiger vorkommen. Nicht authentifizierte Besucher müssen sich jedoch an dem Tag authentifizieren, an dem sie Ihre Website besuchen.
- Wöchentliches Lookback mit wöchentlicher Häufigkeit: Die Daten werden einmal wöchentlich mit einem wöchentlichen Lookback-Fenster wiederholt (siehe options). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefasst 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.
- Zweiwöchiges Lookback mit wöchentlicher Häufigkeit: Daten werden wöchentlich einmal mit einem zweiwöchigen Lookback-Fenster wiederholt (siehe options). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefasst 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 options). Diese Option bietet den Vorteil, dass nicht authentifizierte Sitzungen über einen weniger eng gefasst 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 nicht nur die angeforderte Identität aus dem Quelldatensatz entfernt werden, sondern auch die Zuordnung dieser Identität zu nicht authentifizierten Ereignissen rückgängig gemacht werden. Außerdem muss die Identität aus dem Identitätsdiagramm entfernt werden, um das zukünftige grafikbasierte Stitching für diese spezifische Identität zu verhindern.
note important IMPORTANT Die Aufhebung der Zuordnung als Teil von Datenschutzanfragen wird Anfang 2025 geändert. Der aktuelle Auftrennungsprozess löst Ereignisse anhand der neuesten Version bekannter Identitäten zurück. Diese Umbenennung von Ereignissen zu einer anderen Identität könnte unerwünschte rechtliche Folgen haben. Um diese Bedenken auszuräumen, aktualisiert der neue Auftrennungsprozess ab 2025 Ereignisse, die Gegenstand der Datenschutzanfrage sind, mit der beständigen ID.
Daten, die über das Lookback-Fenster hinausgehen, werden nicht wiederholt. Ein Besucher muss sich in einem gegebenen Lookback-Fenster authentifizieren, damit ein nicht authentifizierter Besuch und ein authentifizierter Besuch gemeinsam identifiziert werden können. Sobald ein Gerät erkannt wurde, wird es von diesem Punkt an live zugeordnet.
Betrachten Sie die folgenden beiden Identitätsdiagramme für die beständige ID 246
und 3579
, wie diese Identitätsdiagramme im Laufe der Zeit aktualisiert werden und wie sich diese Aktualisierungen auf die Schritte beim grafikbasierten Stitching auswirken.
Mit dem Identitätsdiagramm-Viewer können Sie ein Identitätsdiagramm für ein bestimmtes Profil im Zeitverlauf anzeigen. Siehe auch Logik zur Verknüpfung des Identitätsdienstes , um ein besseres Verständnis der Logik zu erhalten, die beim Verknüpfen von Identitäten verwendet wird.
Schritt 1: Live-Stitching
Die Live-Zuordnung versucht, jedes Ereignis bei der Erfassung bekannten Informationen zu diesem Zeitpunkt aus dem Identitätsdiagramm zuzuordnen.
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 1-align-right 7-align-right 13-align-right 19-align-right 25-align-right 31-align-right 37-align-right 43-align-right layout-auto | ||||
---|---|---|---|---|
Zeit | Beständige IDECID |
NamespaceEmail
|
Zugeordnete ID (nach der Live-Zuordnung) | |
1 | 12.05.2023 11:00 | 246 |
246
undefined
|
246 |
2 | 2023-05-12 14:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
3 | 2023-05-12 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
4 | 12.05.2023 17:00 | 3579 |
3579
undefined
|
3579 |
5 | 12.05.2023 19:00 | 3579 |
3579
ted.w@gmail.com
|
ted.w@gmail.com |
6 | 13.05.2023 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
7 | 13.05.2023 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
a.b@yahoo.co.uk |
Sie können sehen, wie die zugeordnete ID für jedes Ereignis aufgelöst wird. Basierend auf der Zeit, der beständigen ID und der Suche des Identitätsdiagramms für den angegebenen Namespace (zur selben Zeit).
Wenn die Suche zu mehr als einer zugewiesenen ID aufgelöst wird (z. B. Ereignis 7), wird die vom Identitätsdiagramm zurückgegebene lexikografische erste ID ausgewählt (a.b@yahoo.co.uk
im Beispiel).
Schritt 2: Wiederholungszuordnung
In regelmäßigen Abständen (je nach ausgewähltem Lookback-Fenster) berechnet die Wiederholungszuordnung historische Daten basierend auf der neuesten Version des Identitätsdiagramms zum Zeitpunkt des Intervalls neu.
Da eine Wiederholungszuordnung zwischen 2023-05-13 16:30 Uhr mit einer 24-Stunden-Lookback-Fensterkonfiguration erfolgt, werden einige Ereignisse aus dem Beispiel neu zugeordnet (gekennzeichnet durch ).
table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 layout-auto | |||||
---|---|---|---|---|---|
Zeit | Beständige IDECID |
NamespaceEmail
|
Zugeordnete ID (nach der Live-Zuordnung) |
Verbundene ID (nach 24 Stunden Wiederholung) |
|
2 | 2023-05-12 14:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
bob.a@gmail.com |
3 | 2023-05-12 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
bob.a@gmail.com |
4 | 12.05.2023 17:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
ted.w@gmail.com |
5 | 12.05.2023 19:00 | 3579 |
3579
ted.w@gmail.com
|
ted.w@gmail.com |
ted.w@gmail.com |
6 | 13.05.2023 15:00 | 246 |
246
a.b@yahoo.co.uk
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
7 | 13.05.2023 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
a.b@yahoo.co.uk |
a.b@yahoo.co.uk |
Da die Wiederholungszuordnung 2023-05-13 16:30 Uhr mit einer 7-tägigen Lookback-Fensterkonfiguration erfolgt, werden alle Ereignisse aus dem Beispiel erneut zugeordnet.
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 layout-auto | |||||
---|---|---|---|---|---|
Zeit | Beständige IDECID |
NamespaceEmail
|
Zugeordnete ID (nach der Live-Zuordnung) |
Zugeordnete ID (nach der Wiederholung 7 Tage) |
|
1 | 12.05.2023 11:00 | 246 |
246
undefined
|
246 |
a.b@yahoo.co.uk |
2 | 2023-05-12 14:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
3 | 2023-05-12 15:00 | 246 |
246
bob.a@gmail.com
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
4 | 12.05.2023 17:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
ted.w@gmail.com |
5 | 12.05.2023 19:00 | 3579 |
3579
ted.w@gmail.com
|
ted.w@gmail.com |
ted.w@gmail.com |
6 | 13.05.2023 15:00 | 246 |
246
a.b@yahoo.co.uk
|
bob.a@gmail.com |
a.b@yahoo.co.uk |
7 | 13.05.2023 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
a.b@yahoo.co.uk |
a.b@yahoo.co.uk |
Schritt 3: Datenschutzanfrage
Wenn Sie eine Datenschutzanfrage erhalten, wird die zugeordnete ID in allen Datensätzen für den Benutzer gelöscht, der der Datenschutzanfrage unterliegt.
Die folgende Tabelle stellt dieselben Daten wie oben dar, zeigt jedoch den Effekt, den eine Datenschutzanfrage (z. B. 2023-05-13 18:00 Uhr) für die Beispielereignisse hat.
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 1-align-right 7-align-right 13-align-right 19-align-right 25-align-right 31-align-right 37-align-right 43-align-right layout-auto | ||||
---|---|---|---|---|
Zeit | Beständige IDECID |
NamespaceEmail
|
Zugeordnete ID (nach Datenschutzanfrage) | |
1 | 12.05.2023 11:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
2 | 2023-05-12 14:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
3 | 2023-05-12 15:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
4 | 12.05.2023 17:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
5 | 12.05.2023 19:00 | 3579 |
3579
ted.w@gmail.com
|
3579 |
6 | 13.05.2023 15:00 | 246 |
246
a.b@yahoo.co.uk
|
246 |
7 | 13.05.2023 16:30 | 246 |
246
a.b@yahoo.co.uk 246
bob.ab@gmail.com
|
246 |
Voraussetzungen
Die folgenden Voraussetzungen gelten speziell für das grafikbasierte Stitching:
- Der Ereignisdatensatz in Adobe Experience Platform, auf den Sie die Zuordnung anwenden möchten, muss über eine Spalte verfügen, die einen Besucher in jeder Zeile identifiziert, die beständige ID. Beispielsweise eine Besucher-ID, die von einer Adobe Analytics-AppMeasurement-Bibliothek generiert wurde, oder eine ECID, die vom Experience Platform Identity-Dienst generiert wurde.
- Die beständige ID muss auch als Identität definiert im Schema sein.
- Das Identitätsdiagramm vom Experience Platform Identity Service muss über einen Namespace verfügen (z. B.
Email
oderPhone
), den Sie beim Stitching verwenden möchten, um die vorübergehende ID aufzulösen. Weitere Informationen finden Sie unter Experience Platform Identity Service .
Einschränkungen
Die folgenden Einschränkungen gelten speziell für das grafikbasierte Stitching:
-
Zeitstempel werden bei der Abfrage nach der vorübergehenden ID unter Verwendung des angegebenen Namespace nicht berücksichtigt. So ist es möglich, dass eine beständige ID mit einer vorübergehenden ID aus einem Datensatz mit einem früheren Zeitstempel verknüpft wird.
-
Keine Unterstützung für freigegebene Geräte Wenn mehrere Identitäten zurückgegeben werden, wird durch Abfrage des Identitätsdiagramms mithilfe eines Namespace die erste lexikografische Identität verwendet.
-
Das Aufstocken von Identitäten in das Identitätsdiagramm ist auf drei Monate begrenzt. Sie würden Identitäten aufstocken, falls Sie keine Experience Platform-Anwendung wie Real-time Customer Data Platform verwenden, um das Identitätsdiagramm zu füllen.
-
Es gelten die Limits des Identitätsdienstes. Siehe beispielsweise die folgenden statischen Beschränkungen:
- Maximale Anzahl von Identitäten in einem Diagramm: 50.
- Maximale Anzahl der Links zu einer Identität für eine Batch-Erfassung: 50.
- Maximale Anzahl von Identitäten in einem XDM-Datensatz für die Diagrammaufnahme: 20.
- Mindestanzahl von Identitäten in einem XDM-Datensatz für die Diagrammaufnahme: 2.
Stitching verwenden
Sobald Ihr Unternehmen alle Voraussetzungen erfüllt und die gängigen Einschränkungen und Stitching-Methodenspezifischen (feldbasiert und grafikbasiert) Einschränkungen versteht, können Sie diese Schritte ausführen, um mit dem Stitching in Customer Journey Analytics zu beginnen.
Optionen auswählen
Das Customer Journey Analytics-Paket, für das Sie berechtigt sind, legt die verfügbaren Stitching-Methoden, Optionen für die anfängliche Aufstockungsdauer, das Lookback-Fenster, die Wiederholungshäufigkeit und die maximale Anzahl der für das Stitching zulässigen Datensätze fest. Weitere Informationen finden Sie in der Customer Journey Analytics-Produktbeschreibung . Entscheiden Sie sich für die verfügbaren Optionen, bevor Sie Support anfordern.
Select
Prime
Ultimate
- Feldbasiertes Stitching
-
Feldbasiertes Stitching
-
Grafikbasierte Zuordnung
-
Feldbasiertes Stitching
-
Grafikbasierte Zuordnung
-
1 Tag, jeden Tag
-
bis zu 7 Tage, wöchentlich
-
1 Tag, jeden Tag
-
bis zu 14 Tage, wöchentlich
-
1 Tag, jeden Tag
-
bis zu 30 Tage, wöchentlich
Support anfordern
-
Wenden Sie sich mit den folgenden Informationen an den Adobe-Support:
- Eine Anfrage zum Aktivieren der Zuordnung.
- Die Datensatz-ID für den Datensatz, den Sie neu zuweisen möchten.
- Der Spaltenname (Identitätspfad und Namespace) der beständigen ID für den gewünschten Datensatz (die Kennung, die in jeder Zeile angezeigt wird).
- Beim feldbasierten Stitching ist der Spaltenname der vorübergehenden ID für den gewünschten Datensatz (die Personenkennung, die auch als Verknüpfung zwischen Datensätzen im Kontext einer Verbindung dient). Bei der grafikbasierten Zuordnung der Identitäts-Namespace, der zum Abfragen des Identitätsdiagramms verwendet werden soll.
- Ihre Voreinstellung für das Lookback-Fenster und die Wiederholungshäufigkeit. In Ihrem Customer Journey Analytics-Paket finden Sie die verfügbaren options.
- Sandbox-Name.
-
Der Adobe-Kundensupport arbeitet mit Adobe-Engineering zusammen, um das Stitching nach Erhalt Ihrer Anfrage zu aktivieren. Nach der Aktivierung wird in Adobe Experience Platform ein neuer neu zugewiesener Datensatz mit einer neuen Spalte für die zugeordnete ID angezeigt. Der Adobe-Kundensupport kann die ID des neuen Datensatzes angeben.
-
Wenn die Option zum ersten Mal aktiviert ist, stellt Adobe eine Aufstockung der zugewiesenen Daten bereit. In Ihrem Customer Journey Analytics-Paket finden Sie die verfügbare Option.
-
Wenn Sie den neuen zugewiesenen Datensatz in einer kanalübergreifenden Analyse verwenden möchten, müssen Sie den neuen zugewiesenen Datensatz zu einer connection in Customer Journey Analytics hinzufügen. Fügen Sie dann alle weiteren Datensätze hinzu, die für die kanalübergreifende Analyse erforderlich sind, und wählen Sie die richtige Personen-ID für jeden Datensatz aus.
-
Erstellen Sie eine Datenansicht auf Grundlage der Verbindung.
Sobald die Datenansicht eingerichtet ist, können Sie Ihre Customer Journey Analytics-Berichtsanalyse kanalübergreifend und geräteübergreifend ausführen.