Classe XDM ExperienceEvent
XDM ExperienceEvent est une classe XDM (Experience Data Model) standard. Utilisez cette classe pour créer un instantané horodaté du système lorsqu’un événement spécifique se produit ou qu’un certain ensemble de conditions a été atteint.
Un événement dʼexpérience est un enregistrement factuel de ce qui s’est passé, y compris le moment et l’identité de la personne impliquée. Les événements peuvent être explicites (actions humaines directement observables) ou implicites (obtenus sans action humaine directe) et sont enregistrés sans agrégation ni interprétation. Pour plus d’informations détaillées sur l’utilisation de cette classe dans l’écosystème Platform, consultez la section Présentation du système XDM.
La classe XDM ExperienceEvent elle-même fournit plusieurs champs temporels à un schéma. Deux de ces champs (_id
et timestamp
) sont obligatoires pour tous les schémas basés sur cette classe, tandis que les autres sont facultatifs. Les valeurs de certains champs sont automatiquement renseignées lors de l’ingestion des données.
_id
(Obligatoire)
_id
identifie de manière unique les événements individuels ingérés dans Adobe Experience Platform. Ce champ permet de suivre l’unicité d’un événement individuel, d’éviter la duplication des données et de rechercher cet événement dans les services en aval.Lorsque des événements en double sont détectés, les applications et services de Platform peuvent gérer la duplication différemment. Par exemple, les événements en double dans le service de profil sont ignorés si l’événement ayant le même
_id
existe déjà dans la banque de profils.Dans certains cas,
_id
peut être un identifiant unique universel (UUID) ou un identifiant unique global (GUID).Si vous diffusez des données depuis une connexion source ou que vous ingérez directement depuis un fichier Parquet, vous devez générer cette valeur en concaténant une certaine combinaison de champs qui rendent l’événement unique. Parmi les exemples d’événements pouvant être concaténés, citons l’ID principal, l’horodatage, le type d’événement, etc. La valeur concaténée doit être une chaîne formatée
uri-reference
, ce qui signifie que tout caractère deux-points doit être supprimé. La valeur concaténée doit ensuite être hachée à l’aide de lʼalgorithme SHA-256 ou d’un autre de votre choix.Il est important de distinguer que ce champ ne représente pas une identité liée à une personne individuelle, mais plutôt lʼenregistrement de données lui-même. Les données d’identité relatives à une personne doivent plutôt être reléguées dans des champs d’identité fournis par des groupes de champs compatibles.
eventMergeId
eventType
Les valeurs standard de cette propriété sont fournies dans la section annexe, y compris des descriptions de leur cas d’utilisation prévu. Ce champ est une énumération extensible, ce qui signifie que vous pouvez également utiliser vos propres chaînes de type d’événement pour classer les événements dont vous effectuez le suivi.La propriété
eventType
vous limite à l’utilisation d’un seul événement par accès sur votre application. Par conséquent, vous devez utiliser des champs calculés pour indiquer au système quel événement est le plus important. Pour plus d’informations, consultez la section dédiée aux bonnes pratiques relatives aux champs calculés.producedBy
Certaines valeurs suggérées pour cette propriété sont indiquées dans la section annexe. Ce champ est une énumération extensible, ce qui signifie que vous pouvez également utiliser vos propres chaînes pour représenter différents déclencheurs d’événements.
identityMap
Pour plus d’informations sur les cas d’utilisation des mappages dʼidentités, consultez la section correspondante sur la page consacrée aux principes de base de la composition des schémas.
timestamp
(Obligatoire)
Bonnes pratiques relatives à la modélisation des événements
Les sections suivantes décrivent les bonnes pratiques pour la conception de vos schémas XDM (Modèle de données d’expérience) basés sur des événements dans Adobe Experience Platform.
Horodatages timestamps
Le champ racine timestamp
d’un schéma d’événement peut uniquement représenter l’observation de l’événement lui-même et doit se produire dans le passé. Cependant, l'événement must a lieu à partir de 1970. Si vos cas d’utilisation de segmentation nécessitent l’utilisation d’horodatages qui peuvent se produire dans le futur, ces valeurs doivent être inscrites ailleurs dans votre schéma d’événement d’expérience.
Par exemple, si une entreprise active dans le secteur du voyage et de l’hôtellerie modélise un événement de réservation de vol, le champ timestamp
au niveau de la classe représente lʼheure à laquelle l’événement de réservation a été observé. D’autres horodatages liés à l’événement, tels que la date de début de la réservation de voyage, doivent être capturés dans des champs distincts fournis par des groupes de champs standard ou personnalisés.
En séparant l’horodatage au niveau de la classe des autres valeurs datetime associées dans vos schémas d’événement, vous pouvez implémenter des cas d’utilisation de segmentation flexibles tout en conservant un compte horodaté des parcours client dans votre application d’expérience.
Utiliser des champs calculés calculated
Certaines interactions dans vos applications d’expérience peuvent entraîner plusieurs événements associés partageant techniquement le même horodatage d’événement et pouvant donc être représentés comme un seul enregistrement d’événement. Si, par exemple, un client consulte un produit sur votre site web, un enregistrement d’événement comportant deux valeurs eventType
potentielles peut être généré : un événement « vue du produit » (commerce.productViews
) ou un événement générique « page vue » (web.webpagedetails.pageViews
). Dans ces cas, vous pouvez utiliser des champs calculés pour capturer les attributs les plus importants lors d’une capture de plusieurs événements dans un seul accès.
Utilisez Adobe Experience Platform Data Prep pour mapper, transformer et valider des données vers et depuis XDM. En utilisant les fonctions de mappage fournies par le service, vous pouvez appeler des opérateurs logiques pour prioriser, transformer et/ou consolider des données provenant d’enregistrements multi-événements lors de leur ingestion dans Experience Platform. Dans l’exemple ci-dessus, vous pouvez désigner eventType
comme champ calculé qui donne la priorité à une « vue du produit » plutôt qu’à une « vue de page » lorsquʼelles se produisent toutes les deux.
Si vous ingérez manuellement des données dans Platform via l’interface utilisateur, consultez le guide sur les champs calculés pour obtenir des instructions spécifiques sur la création de champs calculés.
Si vous diffusez des données en continu vers Platform à l’aide d’une connexion source, vous pouvez configurer la source pour qu’elle utilise à la place des champs calculés. Consultez la documentation de votre source spécifique pour obtenir des instructions sur lʼimplémentation de champs calculés lors de la configuration de la connexion.
Groupes de champs de schéma compatibles field-groups
Adobe fournit plusieurs groupes de champs standard à utiliser avec la classe XDM ExperienceEvent. Voici une liste de groupes de champs couramment utilisés pour la classe :
- Extension complète Adobe Analytics ExperienceEvent
- Transferts de solde
- Détails de la campagne marketing
- Actions de carte
- Informations sur le canal
- Informations commerciales
- Détails du dépôt
- Informations sur la reprise des appareils
- Réservation de restaurant
- Informations sur l’identifiant de l’utilisateur final
- Détails de l’environnement
- Réservation de vol
- Consentement IAB TCF 2.0
- Réservation de logement
- Détails de l’interaction MediaAnalytics
- Détails de la demande de devis
- Détails de la réservation
- Détails web
Annexe
La section suivante contient des informations supplémentaires sur la classe XDM ExperienceEvent.
Valeurs acceptées pour eventType
eventType
Le tableau suivant décrit les valeurs acceptées pour eventType
, ainsi que leurs définitions :
advertising.clicks
advertising.completes
advertising.conversions
advertising.federated
advertising.firstQuartiles
advertising.impressions
advertising.midpoints
advertising.starts
advertising.thirdQuartiles
advertising.timePlayed
application.close
application.launch
click
decisioning.propositionInteract
.commerce.backofficeCreditMemoIssued
commerce.backofficeOrderCancelled
commerce.backofficeOrderItemsShipped
commerce.backofficeOrderPlaced
commerce.backofficeShipmentCompleted
commerce.checkouts
commerce.productListAdds
commerce.productListOpens
commerce.productListRemovals
commerce.productListReopens
commerce.productListViews
commerce.productViews
commerce.purchases
commerce.saveForLaters
decisioning.propositionDisplay
decisioning.propositionDismiss
decisioning.propositionFetch
decisioning.propositionInteract
decisioning.propositionSend
decisioning.propositionTrigger
delivery.feedback
directMarketing.emailBounced
directMarketing.emailBouncedSoft
directMarketing.emailClicked
directMarketing.emailDelivered
directMarketing.emailOpened
directMarketing.emailSent
directMarketing.emailUnsubscribed
display
decisioning.propositionDisplay
.inappmessageTracking.dismiss
inappmessageTracking.display
inappmessageTracking.interact
leadOperation.callWebhook
leadOperation.changeCampaignStream
leadOperation.changeEngagementCampaignCadence
leadOperation.convertLead
leadOperation.interestingMoment
leadOperation.mergeLeads
leadOperation.newLead
leadOperation.scoreChanged
leadOperation.statusInCampaignProgressionChanged
listOperation.addToList
listOperation.removeFromList
media.adBreakComplete
media.adBreakStart
media.adComplete
media.adSkip
media.adStart
media.bitrateChange
media.bufferStart
media.bufferStart
est envoyé au début de la mise en mémoire tampon. Il n’existe pas de type d’événement bufferResume
spécifique ; la mise en mémoire tampon est considérée comme ayant repris lorsqu’un événement play
est envoyé suite à un événement bufferStart
.media.chapterComplete
media.chapterSkip
media.chapterStart
media.downloaded
media.error
media.pauseStart
pauseStart
s’est produit. Cet événement est déclenché lorsqu’un utilisateur lance une pause dans la lecture multimédia. Il n’existe aucun type d’événement resume . Une reprise est déduite lorsque vous envoyez un événement de lecture après un pauseStart
.media.ping
media.ping
est utilisé pour indiquer l’état de lecture en cours. Pour le contenu principal, cet événement doit être envoyé toutes les 10 secondes pendant la lecture, en commençant 10 secondes après le début de la lecture. Pour le contenu de la publicité, il doit être envoyé toutes les secondes pendant le suivi publicitaire. Les événements ping ne doivent pas inclure la carte params dans le corps de la requête.media.play
media.play
est envoyé lorsque le lecteur passe à l’état playing
à partir d’un autre état, tel que buffering,
paused
(lorsqu’il est repris par l’utilisateur) ou error
(lorsqu’il est récupéré), y compris les scénarios de lecture automatique. Cet événement est déclenché par le rappel on('Playing')
du lecteur.media.sessionComplete
media.sessionEnd
media.sessionEnd
avertit le serveur principal Media Analytics de fermer immédiatement une session lorsqu’un utilisateur abandonne l’affichage et ne risque pas de revenir. Si cet événement n’est pas envoyé, la session expire après 10 minutes d’inactivité ou 30 minutes sans mouvement du curseur de lecture. Tous les appels de médias suivants avec cet ID de session seront ignorés.media.sessionStart
media.sessionStart
est envoyé avec l’appel de lancement de session. Lors de la réception d’une réponse, l’ID de session est extrait de l’en-tête Emplacement et utilisé pour tous les appels d’événement suivants au serveur de collecte.media.statesUpdate
statesUpdate
s’est produit. Les fonctionnalités de suivi de l’état du lecteur peuvent être associées à un flux audio ou vidéo. Les états standard sont : fullscreen
, mute
, closedCaptioning
, pictureInPicture
et inFocus
.opportunityEvent.addToOpportunity
opportunityEvent.opportunityUpdated
opportunityEvent.removeFromOpportunity
personalization.request
decisioning.propositionFetch
.pushTracking.applicationOpened
pushTracking.customAction
web.formFilledOut
web.webinteraction.linkClicks
web.webpagedetails.pageViews
location.entry
location.exit
Valeurs suggérées pour producedBy
producedBy
Le tableau suivant présente quelques-unes des valeurs acceptées pour producedBy
:
self
system
salesRef
customerRep