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 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.

Best practices for event modeling

The following sections cover best practices for designing your event-based Experience Data Model (XDM) schemas in Adobe 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 “product view” event (commerce.productViews) or a generic “page 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 Adobe 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 “product view” over a “page view” whenever they both occur.

If you are manually ingesting data into 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 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

Adobe 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:

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:

Suggested values for producedBy producedBy

The following table outlines some accepted values for producedBy: