2.2 Unitary Event Triggers & Schema Requirements

2.2 Unitary Event Triggers and Schema Requirements

A unitary event starts or advances an individual journey execution. The business practitioner does not need to implement the ingestion SDK for this exam, but must recognize what a valid event configuration needs and how to diagnose a signal that never reaches the canvas.

System-generated and rule-based events

Journey Optimizer supports two event configuration approaches.

A system-generated event is produced through the Adobe Experience Platform data collection and ingestion ecosystem and is identified by the event configuration. A rule-based event applies a configured rule to incoming events so the journey listens only when the rule is satisfied.

Both approaches point to an XDM schema and expose selected payload fields. The distinction is about how the incoming signal is recognized, not whether the event belongs to one person.

XDM event structure

Behavioral events use an XDM ExperienceEvent-style, time-series model. Each occurrence represents something that happened at a time. An event ID helps distinguish the occurrence, and a timestamp establishes when it happened. The schema and ingestion payload must conform to the configured structure and datatypes.

For an individual journey, configure the identity and namespace needed to associate execution with the person. Identity selection is especially important if the journey later retrieves profile attributes. The namespace on the event must match the namespace expected by the event configuration; a valid value under the wrong namespace does not resolve as intended.

Do not reduce this to “identityMap is always the only valid location.” XDM supports identity fields and identity maps according to schema design. The practitioner should verify the configured identity path, namespace, and people-identity meaning.

Payload fields and event context

During event configuration, select the fields the journey may use. Keeping the payload focused reduces ambiguity and makes expressions easier to maintain. Selected contextual fields can support conditions or content later in the path.

Example:

• event ID and timestamp identify the occurrence;
• a customer identity establishes the individual;
• order ID, amount, store, and status provide context;
• profile fields such as loyalty tier come from Real-Time Customer Profile, not magically from the event.

A payload field is not automatically a persistent profile attribute. If the business wants a value available on later, unrelated journeys, the data architecture must ingest it into an appropriate profile-enabled record or event model and make it queryable through supported services. Event context is tied to the journey execution that received it.

Use the expression editor's field selector instead of inventing a path. Journey and message authoring contexts use documented selectors and generated references; old examples from other Adobe products or arbitrary “context” paths are not reliable.

End-to-end configuration path

1. Confirm the source emits a conforming XDM ExperienceEvent.
2. Confirm the schema contains the required timestamp, event identification, identity, and business fields.
3. Confirm ingestion routes the event to the correct sandbox and datastream or connection.
4. Create the event configuration and choose system-generated or rule-based recognition.
5. Select the correct schema, identity type, namespace, and payload fields.
6. Place the event as the journey entry and build downstream logic.
7. Validate and exercise it with an approved test profile and a unique event occurrence.

Common failure modes

Wrong sandbox: The source posts to a different sandbox than the journey and event configuration.

Namespace mismatch: The identity value appears valid, but its namespace differs from the configured one.

Schema mismatch: A field uses the wrong datatype, is absent, or arrives at a different path.

Event recognition mismatch: The rule or event identifier does not match the incoming occurrence.

Profile not retrievable: The event can be received, but later profile lookup fails because identity or profile enablement is unsuitable.

Duplicate event ID: Reusing an identifier can lead to unintended deduplication or operational confusion. Generate a unique occurrence ID according to the source design.

Field not selected: The event arrives, but a downstream condition cannot use a value that was not exposed in configuration.

Choosing another entry

Use Audience Qualification for a membership transition, Read Audience for scheduled bulk entry, and Business Event for a non-person occurrence followed by a preselected audience read. A customer behavior with a direct individual identity is the clearest unitary-event case.