XDM ExperienceEvent-Klasse:
XDM ExperienceEvent ist eine standardmäßige Experience-Datenmodell (XDM)-Klasse. Verwenden Sie diese Klasse, um einen mit einem Zeitstempel versehenen Schnappschuss des Systems zu erstellen, wenn ein bestimmtes Ereignis auftritt oder eine Reihe von Bedingungen erfüllt worden sind.
Ein Erlebnisereignis ist eine Aufzeichnung des Geschehens in Form von Fakten, einschließlich des Zeitpunkts und der Identität der beteiligten Person. Ereignisse können entweder explizit (direkt beobachtbare menschliche Aktionen) oder implizit (ohne direkte menschliche Aktion ausgelöst) sein und werden ohne Aggregation oder Interpretation aufgezeichnet. Weitere wichtige Informationen zur Verwendung dieser Klasse im Experience Platform-Ökosystem finden Sie im Abschnitt XDM-Übersicht.
Die XDM ExperienceEvent-Klasse selbst stellt mehrere zeitreihenbezogene Felder für ein Schema bereit. Zwei dieser Felder (_id und timestamp) sind erforderlich für alle Schemata, die auf dieser Klasse basieren, während der Rest optional ist. Die Werte einiger Felder werden bei der Datenaufnahme automatisch ausgefüllt.
_id(erforderlich)
_id identifiziert einzelne Ereignisse, die in Adobe Experience Platform aufgenommen werden, eindeutig. Dieses Feld wird verwendet, um die Eindeutigkeit eines einzelnen Ereignisses nachzuverfolgen, Doppelungen von Daten zu verhindern und dieses Ereignis bei nachgelagerten Services nachzuschlagen.Wenn doppelte Ereignisse erkannt werden, können Experience Platform-Programme und -Services die Duplizierung anders handhaben. Beispielsweise werden doppelte Ereignisse im Profil-Service gelöscht, wenn das Ereignis mit demselben
_id bereits im Profilspeicher vorhanden ist. Diese Ereignisse werden jedoch weiterhin im Data Lake aufgezeichnet.In einigen Fällen kann
_id ein Universally Unique Identifier (UUID) ein Globally Unique Identifier (GUID) sein.Wenn Sie Daten aus einer Quellverbindung streamen oder direkt aus einer Parquet-Datei erfassen, sollten Sie diesen Wert generieren, indem Sie eine bestimmte Kombination von Feldern verketten, die das Ereignis eindeutig machen. Beispiele für verkettete Ereignisse sind primäre ID, Zeitstempel, Ereignistyp usw. Der verkettete Wert muss eine formatierte Zeichenfolge des Typs
uri-reference sein, was bedeutet, dass alle Doppelpunkt-Zeichen entfernt werden müssen. Danach sollte der verkettete Wert mit SHA-256 oder einem anderen Algorithmus Ihrer Wahl gehasht werden.Es ist wichtig zu erkennen, dass dieses Feld keine Identität repräsentiert, die mit einer Person in Verbindung steht, sondern den Dateneintrag an sich. Identitätsdaten, die sich auf eine Person beziehen, sollten stattdessen auf Identitätsfelder relegiert werden, die von kompatiblen Feldergruppen bereitgestellt werden.
eventMergeIdeventTypeStandardwerte für diese Eigenschaft sind im Anhang zusammen mit Beschreibungen des vorgesehenen Anwendungsfalls angegeben. Dieses Feld ist eine erweiterbare Aufzählung, d. h. Sie können auch eigene Ereignistyp-Zeichenfolgen verwenden, um die Ereignisse, die Sie nachverfolgen, zu kategorisieren.
eventType beschränkt Sie auf die Verwendung nur eines einzigen Ereignisses pro Treffer in Ihrem Programm. Daher müssen Sie berechnete Felder verwenden, um dem System mitzuteilen, welches Ereignis am wichtigsten ist. Weitere Informationen finden Sie im Abschnitt zu Best Practices für berechnete Felder.producedByEinige empfohlene Werte für diese Eigenschaft sind im Anhang angegeben. Dieses Feld ist eine erweiterbare Aufzählung, d. h. Sie können auch eigene Zeichenfolgen verwenden, um verschiedene Ereignisverursacher darzustellen.
identityMapSiehe Abschnitt zu Identitätszuordnungen in Grundlagen der Schemakomposition für weitere Informationen zu ihrem Anwendungsfall.
timestamp(erforderlich)
Best Practices für die Ereignismodellierung
In den folgenden Abschnitten finden Sie Best Practices zum Entwerfen Ihrer ereignisbasierten Experience-Datenmodell (XDM)-Schemata in Adobe Experience Platform.
Zeitstempel timestamps
Das timestamp-Feld im Stamm eines Ereignisschemas kann nur die Beobachtung des Ereignisses an sich repräsentieren und muss in der Vergangenheit liegen. Die Veranstaltung muss jedoch ab 1970 stattfinden. Wenn Ihre Segmentierungsanwendungsfälle die Verwendung von Zeitstempeln erfordern, die in Zukunft auftreten können, müssen diese Werte an einer anderen Stelle im Erlebnisereignis-Schema eingeschränkt werden.
Beispiel: Wenn ein Unternehmen des Reise- und Beherbergungsgewerbes ein Flugreservierungsereignis modelliert, gibt das timestamp-Feld auf Klassenebene den Zeitpunkt an, zu dem das Reservierungsereignis beobachtet wurde. Andere Zeitstempel, die mit dem Ereignis in Verbindung stehen, wie z. B. das Startdatum der Reisereservierung, sollten in separaten Feldern erfasst werden, die von standardmäßigen oder benutzerdefinierten Feldergruppen bereitgestellt werden.
Indem Sie den Zeitstempel auf Klassenebene von anderen zugehörigen Datums-/Zeitwerten in Ihren Ereignisschemata trennen, können Sie flexible Anwendungsfälle für die Segmentierung implementieren und gleichzeitig ein Kundenkonto mit Zeitstempel in Ihrem Erlebnisprogramm beibehalten.
Verwenden berechneter Felder calculated
Bestimmte Interaktionen in Ihren Erlebnisprogrammen können zu mehreren verwandten Ereignissen führen, die technisch denselben Ereigniszeitstempel aufweisen und daher als ein Ereigniseintrag dargestellt werden. Wenn ein Kunde beispielsweise ein Produkt auf Ihrer Website ansieht, kann dies zu einem Ereigniseintrag führen, der zwei potenzielle eventType-Werte hat: ein „Produktansicht“-Ereignis (commerce.productViews) oder ein generisches „Seitenansicht“-Ereignis (web.webpagedetails.pageViews). In diesen Fällen können Sie berechnete Felder verwenden, um die wichtigsten Attribute zu erfassen, wenn mehrere Ereignisse in einem Treffer erfasst werden.
Verwenden Sie die Adobe Experience PlatformDatenvorbereitung, um Daten von und zu XDM zuzuordnen, umzuwandeln und zu validieren. Mithilfe der verfügbaren Zuordnungsfunktionen, die vom Service bereitgestellt werden, können Sie logische Operatoren aufrufen, um Daten aus Einträgen mit mehreren Ereignissen zu priorisieren, umzuwandeln und/oder zu konsolidieren, wenn sie in Experience Platform aufgenommen werden. Im obigen Beispiel könnten Sie eventType als berechnetes Feld festlegen, das eine „Produktansicht“ gegenüber einer „Seitenansicht“ priorisiert, wenn beide auftreten.
Wenn Sie Daten manuell über die Benutzeroberfläche in Experience Platform erfassen, finden Sie das Handbuch unter Berechnete Felder spezifische Anweisungen zum Erstellen berechneter Felder.
Wenn Sie Daten mithilfe einer Quellverbindung an Experience Platform streamen, können Sie die Quelle so konfigurieren, dass stattdessen berechnete Felder verwendet werden. In der Dokumentation zu Ihrer jeweiligen Quelle finden Sie Anweisungen zur Implementierung berechneter Felder beim Konfigurieren der Verbindung.
Kompatible Schemafeldgruppen field-groups
Adobe bietet mehrere Standardfeldgruppen zur Verwendung mit der XDM ExperienceEvent-Klasse. Im Folgenden finden Sie eine Liste einiger häufig verwendeter Feldergruppen für die Klasse:
- Vollständige Erweiterung für Adobe Analytics ExperienceEvent
- Adobe Advertising Cloud ExperienceEvent Full Extension
- Saldoübertragungen
- Kampagnen-Marketing-Details
- Kartenaktionen
- Kanaldetails
- Handelsdetails
- Einzahlungsdetails
- Details zum Gerätehandel
- Restaurantreservierung
- Details zur Endbenutzer-ID
- Umgebungsdetails
- Flugreservierung
- IAB TCF 2.0-Einverständnis
- Unterkunftsreservierung
- MediaAnalytics Interaction-Details
- Details zur Angebotsanfrage
- Reservierungsdetails
- Web-Details
Anhang
Im folgenden Abschnitt finden Sie weitere Informationen zur XDM ExperienceEvent-Klasse.
Akzeptierte Werte für eventType eventType
In der folgenden Tabelle sind die akzeptierten Werte für eventType zusammen mit ihren Definitionen aufgeführt:
advertising.clicksadvertising.completesadvertising.conversionsadvertising.federatedadvertising.firstQuartilesadvertising.impressionsadvertising.midpointsadvertising.startsadvertising.thirdQuartilesadvertising.timePlayedapplication.closeapplication.launchclickdecisioning.propositionInteract.commerce.backofficeCreditMemoIssuedcommerce.backofficeOrderCancelledcommerce.backofficeOrderItemsShippedcommerce.backofficeOrderPlacedcommerce.backofficeShipmentCompletedcommerce.checkoutscommerce.productListAddscommerce.productListOpenscommerce.productListRemovalscommerce.productListReopenscommerce.productListViewscommerce.productViewscommerce.purchasescommerce.saveForLatersdecisioning.propositionDisplaydecisioning.propositionDismissdecisioning.propositionFetchdecisioning.propositionInteractdecisioning.propositionSenddecisioning.propositionTriggerdelivery.feedbackdirectMarketing.emailBounceddirectMarketing.emailBouncedSoftdirectMarketing.emailClickeddirectMarketing.emailDelivereddirectMarketing.emailOpeneddirectMarketing.emailSentdirectMarketing.emailUnsubscribeddisplaydecisioning.propositionDisplay.inappmessageTracking.dismissinappmessageTracking.displayinappmessageTracking.interactleadOperation.callWebhookleadOperation.changeCampaignStreamleadOperation.changeEngagementCampaignCadenceleadOperation.convertLeadleadOperation.interestingMomentleadOperation.mergeLeadsleadOperation.newLeadleadOperation.scoreChangedleadOperation.statusInCampaignProgressionChangedlistOperation.addToListlistOperation.removeFromListmedia.adBreakCompletemedia.adBreakStartmedia.adCompletemedia.adSkipmedia.adStartmedia.bitrateChangemedia.bufferStartmedia.bufferStart Ereignistyp wird bei Beginn der Pufferung gesendet. Es gibt keinen bestimmten bufferResume Ereignistyp. Die Pufferung wird als fortgesetzt betrachtet, wenn nach einem play Ereignis ein bufferStart Ereignis gesendet wird.media.chapterCompletemedia.chapterSkipmedia.chapterStartmedia.downloadedmedia.errormedia.pauseStartpauseStart Ereignis aufgetreten ist. Dieses Ereignis wird ausgelöst, wenn ein Benutzer eine Pause bei der Medienwiedergabe einleitet. Es gibt keinen Resume-Ereignistyp. Ein Lebenslauf wird abgeleitet, wenn Sie ein Wiedergabeereignis nach einem pauseStart senden.media.pingmedia.ping Ereignistyp wird verwendet, um den aktuellen Wiedergabestatus anzuzeigen. Für Hauptinhalte muss dieses Ereignis während der Wiedergabe alle 10 Sekunden gesendet werden, beginnend 10 Sekunden nach dem Beginn der Wiedergabe. Bei Anzeigen-Inhalten muss sie jede Sekunde beim Anzeigen-Tracking gesendet werden. Ping-Ereignisse sollten die Parameterzuordnung nicht im Anfrageinhalt enthalten.media.playmedia.play-Ereignistyp wird gesendet, wenn der Player von einem anderen Status in den playing wechselt, z. B. buffering, paused (wenn der Benutzer ihn wieder aufnimmt) oder error (wenn er wiederhergestellt wird), einschließlich Szenarien wie der automatischen Wiedergabe. Dieses Ereignis wird durch den on('Playing') Callback des Players ausgelöst.media.sessionCompletemedia.sessionEndmedia.sessionEnd benachrichtigt das Media Analytics-Backend, dass eine Sitzung sofort geschlossen werden soll, wenn ein Benutzer seine Anzeige verlässt, und es unwahrscheinlich ist, dass er zurückkehrt. Wenn dieses Ereignis nicht gesendet wird, wird die Sitzung nach 10 Minuten Inaktivität oder 30 Minuten ohne Abspielkopfbewegung beendet. Alle nachfolgenden Medienaufrufe mit dieser Sitzungs-ID werden ignoriert.media.sessionStartmedia.sessionStart-Ereignistyp wird mit dem Sitzungsinitiierungsaufruf gesendet. Nach Erhalt einer Antwort wird die Sitzungs-ID aus dem Location-Header extrahiert und für alle nachfolgenden Ereignisaufrufe an den Sammlungsserver verwendet.media.statesUpdatestatesUpdate Ereignis aufgetreten ist. Die Player-Status-Tracking-Funktionen können an einen Audio- oder Video-Stream angehängt werden. Die Standardstatus sind: fullscreen, mute, closedCaptioning, pictureInPicture und inFocus.opportunityEvent.addToOpportunityopportunityEvent.opportunityUpdatedopportunityEvent.removeFromOpportunitypersonalization.requestdecisioning.propositionFetch.pushTracking.applicationOpenedpushTracking.customActionweb.formFilledOutweb.webinteraction.linkClicksweb.webpagedetails.pageViewslocation.entrylocation.exitVorgeschlagene Werte für producedBy producedBy
In der folgenden Tabelle sind einige akzeptierte Werte für producedBy angegeben:
selfsystemsalesRefcustomerRep