Configure event-triggered journey entry and real-time action routing
Define streaming entry events with schema-matched payloads, assemble a journey canvas that routes profiles through conditional actions, and publish the journey for real-time execution.
Event-triggered journeys fire the moment a qualifying behavioral signal arrives — a purchase, an abandoned cart, a service cancellation — and immediately route the profile through a pre-defined action sequence. Configuring this capability requires defining the entry event (its schema, the fields that carry contextual data, and the mechanism for matching an inbound event to the correct journey), assembling the journey canvas with conditional branches and communication actions, and crafting message content that draws on both standing profile attributes and the live event payload.
Key decisions include selecting the correct eventID strategy (system-generated versus externally defined), choosing which XDM fields from the triggering event to expose in downstream message personalization, managing journey re-entry rules so returning profiles are handled predictably, and coordinating the Data Collection client-side configuration so events actually arrive in the edge network. Batch journeys follow a parallel pattern: instead of an event node they use a Read Segment entry, which enables scheduled, audience-scoped sends without requiring a live trigger.
Parallel viability: The real-time event-entry and sub-second action-routing pattern is deeply integrated with AEP Edge Network and AJO's internal orchestration engine, making it functionally AEP-locked for latencies under a few seconds. Composable stacks can approximate the batch variant (Read Segment) using tools such as Hightouch Journeys or Braze Canvas with a CDP audience sync, but the unitary-event path — where the journey fires within the same Edge call that ingested the event — has no direct equivalent outside AEP without significant custom engineering.
Side-by-side implementations
In Adobe Journey Optimizer, practitioners create a Unitary Event by selecting the "System Generated" eventID type and mapping it to an XDM Event Schema (e.g., Demo System - Event Schema for Website). The event is added as the entry node on a Journey Canvas, followed by an Email action that uses the Email Designer to compose content with profile personalization tokens (e.g., profile.person.name.firstName) and contextual attributes from the triggering event payload (e.g., productListItems.name, productListItems.priceTotal). A separate batch journey uses a Read Segment node to select an audience, imports or builds email content, and is scheduled for recurring delivery. Both journey types are published via the "Publish" button and the corresponding Data Collection Client Property trigger rule is activated to fire events into AEP Edge.
Capability: Audience Segmentation
Parallel implementation not yet available.
Hightouch Journeys covers the batch variant of this task: a Read Segment entry node (using a Hightouch audience model) evaluates profile eligibility on a schedule, triggers a journey, and routes action steps to configured destinations (email, SMS, ad platforms). The batch journey pattern — scheduled audience-scoped sends — is fully parallel to AJO's Read Segment node. The real-time unitary-event path (XDM PurchaseEvent triggers journey entry within the Edge Network call, milliseconds after the transaction) is AEP-locked; Hightouch's Live Syncs achieve near-real-time (1–5 minute lag) but cannot match sub-second Edge Network latency. For the Data Collection Client Property trigger rule update linking a Tags rule to AEP Edge: the composable equivalent is configuring Analytics.js or a custom SDK to fire qualifying events into Kafka/Kinesis, which a downstream stream processor evaluates for journey entry — this requires custom engineering with no pre-built equivalent.
Capability: Audience Segmentation
Pattern: AEP-as-Edge-Node
Task-level sources
- technical-training/module10/index.md
- technical-training/module10/ex1.md
- technical-training/module10/ex2.md
- technical-training/module10/summary.md
How is this implementation?
Sign-in-gated. Tomorrow morning's curriculum-ingestor consumes your feedback: "Inaccurate" queues the task for re-review, "needs update" queues it for a refresh, and "one vendor panel is wrong" re-drafts just that panel.