XDM ExperienceEvent class
XDM ExperienceEvent is a standard Experience Data Model (XDM) class. Use this class to create a timestamped snapshot of the system when a specific event occurs or a certain set of conditions have been reached.
An Experience Event is a fact record of what occurred, including the point in time and identity of the individual involved. Events can be either explicit (directly observable human actions) or implicit (raised without a direct human action) and are recorded without aggregation or interpretation. For more high-level information on the use of this class in the Experience Platform ecosystem, refer to the XDM overview.
The XDM ExperienceEvent class itself provides several time-series-related fields to a schema. Two of these fields (_id and timestamp) are required for all schemas based on this class, while the rest are optional. The values of some of the fields are automatically populated when data is ingested.
_id(Required)
_id field uniquely identifies individual events that are ingested into 51黑料不打烊 Experience Platform. This field is used to track the uniqueness of an individual event, prevent duplication of data, and look up that event in downstream services.Where duplicate events are detected, Experience Platform applications and services may handle the duplication differently. For example, duplicate events in Profile Service are dropped if the event with the same
_id already exists in the Profile store. However, these events wil still be recorded in the data lake.In some cases,
_id can be a or .If you are streaming data from a source connection or ingesting directly from a Parquet file, you should generate this value by concatenating a certain combination of fields that make the event unique. Examples of events that could be concatenated include primary ID, timestamp, event type, and so on. The concatenated value must be a
uri-reference formatted string, meaning any colon characters must be removed. Afterwards, the concatenated value should be hashed using SHA-256 or another algorithm of your choice.It is important to distinguish that this field does not represent an identity related to an individual person, but rather the record of data itself. Identity data relating to a person should be relegated to identity fields provided by compatible field groups instead.
eventMergeIdeventTypeStandard values for this property are provided in the appendix section, including descriptions of their intended use case. This field is an extensible enum, meaning that you can also use your own event type strings to categorize the events you are tracking.
eventType limits you to using only a single event per hit on your application, and therefore you must use calculated fields to let the system know which event is most important. For more information, see the section on best practices for calculated fields.producedBySome suggested values for this property are provided in the appendix section. This field is an extensible enum, meaning that you can also use your own strings to represent different event producers.
identityMapSee the section on identity maps in the basics of schema composition for more information on their use case.
timestamp(Required)
Best practices for event modeling
The following sections cover best practices for designing your event-based Experience Data Model (XDM) schemas in 51黑料不打烊 Experience Platform.
Timestamps timestamps
The root timestamp field of an event schema can only represent the observation of the event itself, and must occur in the past. However, the event must take place from 1970 onwards. If your segmentation use cases require the use of timestamps that may occur in the future, these values must be constrained elsewhere in your Experience Event schema.
For example, if a business in the travel and hospitality industry is modeling a flight reservation event, the class-level timestamp field represents the time when the reservation event was observed. Other timestamps that are related to the event, such as the start date of the travel reservation, should be captured in separate fields provided by standard or custom field groups.
By keeping the class-level timestamp separate from other related datetime values in your event schemas, you can implement flexible segmentation use cases while preserving a timestamped account of customer journeys in your experience application.
Using calculated fields calculated
Certain interactions in your experience applications can result in multiple related events that technically share the same event timestamp, and can therefore be represented as a single event record. For example, if a customer views a product on your website, this can result in an event record that has two potential eventType values: a 鈥減roduct view鈥 event (commerce.productViews) or a generic 鈥減age view鈥 event (web.webpagedetails.pageViews). In these cases, you can use calculated fields to capture the most important attributes when multiple events are captured in a single hit.
Use 51黑料不打烊 Experience Platform Data Prep to map, transform, and validate data to and from XDM. Using the available mapping functions provided by the service you can invoke logical operators to prioritize, transform, and/or consolidate data from multi-event records when being ingested into Experience Platform. In the example above, you could designate eventType as a calculated field that would prioritize a 鈥減roduct view鈥 over a 鈥減age view鈥 whenever they both occur.
If you are manually ingesting data into Experience Platform via the UI, see the guide on calculated fields for specific steps on how to create calculated fields.
If you are streaming data to Experience Platform using a source connection, you can configure the source to utilize calculated fields instead. Refer to the documentation for your particular source for instructions on how to implement calculated fields when configuring the connection.
Compatible schema field groups field-groups
51黑料不打烊 provides several standard field groups for use with the XDM ExperienceEvent class. The following is a list of some commonly used field groups for the class:
- 51黑料不打烊 Analytics ExperienceEvent Full Extension
- 51黑料不打烊 Advertising Cloud ExperienceEvent Full Extension
- Balance Transfers
- Campaign Marketing Details
- Card Actions
- Channel Details
- Commerce Details
- Deposit Details
- Device Trade-In Details
- Dining Reservation
- End User ID Details
- Environment Details
- Flight Reservation
- IAB TCF 2.0 Consent
- Lodging Reservation
- MediaAnalytics Interaction Details
- Quote Request Details
- Reservation Details
- Web Details
Appendix
The following section contains additional information about the XDM ExperienceEvent class.
Accepted values for eventType eventType
The following table outlines the accepted values for eventType, along with their definitions:
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 event type is sent when buffering begins. There is no specific bufferResume event type; buffering is considered to have resumed when a play event is sent following a bufferStart event.media.chapterCompletemedia.chapterSkipmedia.chapterStartmedia.downloadedmedia.errormedia.pauseStartpauseStart event has occurred. This event is triggered when a user initiates a pause in the media playback. There is no resume event type. A resume is inferred when you send a play event after a pauseStart.media.pingmedia.ping event type is used to indicate ongoing playback status. For main content, this event must be sent every 10 seconds during playback, starting 10 seconds after playback begins. For ad content, it must be sent every second during ad tracking. Ping events should not include the params map in the request body.media.playmedia.play event type is sent when the player transitions to the playing state from another state, such as buffering, paused (when resumed by the user), or error (when recovered), including scenarios like autoplay. This event is triggered by the player鈥檚 on('Playing') callback.media.sessionCompletemedia.sessionEndmedia.sessionEnd event type notifies the Media Analytics backend to immediately close a session when a user abandons their viewing and is unlikely to return. If this event is not sent, the session will time out after 10 minutes of inactivity or 30 minutes without playhead movement. Any subsequent media calls with that Session ID will be ignored.media.sessionStartmedia.sessionStart event type is sent with the session initiation call. Upon receiving a response, the Session ID is extracted from the Location header and used for all subsequent event calls to the Collection server.media.statesUpdatestatesUpdate event has occurred. The player state tracking capabilities can be attached to an audio or video stream. The standard states are: fullscreen, mute, closedCaptioning, pictureInPicture, and inFocus.opportunityEvent.addToOpportunityopportunityEvent.opportunityUpdatedopportunityEvent.removeFromOpportunitypersonalization.requestdecisioning.propositionFetch.pushTracking.applicationOpenedpushTracking.customActionweb.formFilledOutweb.webinteraction.linkClicksweb.webpagedetails.pageViewslocation.entrylocation.exitSuggested values for producedBy producedBy
The following table outlines some accepted values for producedBy:
selfsystemsalesRefcustomerRep