Event-triggered messaging
This guide provides a comprehensive implementation blueprint for event-triggered messaging using Adobe Journey Optimizer (AJO), Real-Time Customer Data Platform (RT-CDP), and Adobe Experience Platform (AEP). It is designed for solution architects, marketing technologists, and implementation engineers who need to deliver contextual, real-time messages in response to behavioral or system events.
Use this guide to understand what to configure, where implementation choices exist, and what trade-offs drive each decision.
The guide covers the full lifecycle from event ingestion and journey creation through message delivery and performance reporting, with detailed decision guidance for three distinct implementation options.
Use case overview
Event-triggered messaging delivers a contextual message in response to a real-time behavioral or system event. Unlike batch outbound message activation, which sends to a pre-evaluated audience on a schedule, this pattern listens for a qualifying event – such as a cart abandonment, a browse session, a form submission, or a system status change – and immediately enters the triggering profile into a journey that evaluates conditions and delivers a message.
The pattern relies on real-time event streaming into AEP (via Web SDK, Mobile SDK, or server-side API), a journey with a unitary event entry in AJO, and condition evaluation logic that determines whether and what to send. The message is typically sent within minutes of the triggering event, making this pattern ideal for time-sensitive, contextually relevant communications.
Organizations use this pattern to respond to customer actions in real time, increasing relevance and driving higher engagement and conversion rates compared to scheduled batch communications. Common scenarios include abandoned cart recovery, post-purchase follow-up, welcome messages after registration, and time-sensitive notifications like payment failures or price drop alerts.
Key business objectives
The following business objectives are supported by this use case pattern.
Recover abandoned carts & journeys
Re-engage users who dropped off during purchase, application, or enrollment flows with timely, personalized follow-ups.
Improve the percentage of visitors and prospects who complete desired actions such as purchases, sign-ups, or form submissions.
Deliver personalized customer experiences
Tailor content, offers, and messaging to individual preferences, behaviors, and lifecycle stage.
Accelerate time-to-value for new customers with streamlined, personalized welcome experiences and activation journeys.
Example tactical use cases
The following scenarios illustrate how event-triggered messaging can be applied across different business contexts.
- Cart abandonment email or SMS – Send a reminder message when a customer adds items to their cart but does not complete the purchase within a defined time window
- Browse abandonment follow-up – Re-engage visitors who viewed products or content but did not take a conversion action
- Post-purchase thank-you or cross-sell – Deliver a confirmation and cross-sell recommendation immediately after a purchase event
- Trial expiry reminder – Notify users approaching the end of a free trial with renewal or conversion messaging
- Welcome message after registration – Send an immediate onboarding message when a new user registers or creates an account
- Form submission confirmation – Acknowledge form submissions (contact requests, applications, enrollments) with a contextual confirmation
- Payment failure notification – Alert customers when a recurring payment fails, prompting them to update payment information
- App uninstall win-back push notification – Trigger a win-back message when a user uninstalls a mobile application
- Booking or appointment confirmation – Send immediate confirmation after a booking, reservation, or appointment is scheduled
- Price drop alert for wishlisted items – Notify customers when a product on their wishlist drops in price
Key performance indicators
The following KPIs help measure the effectiveness of event-triggered messaging implementations.
Use case pattern
This section describes the core pattern and the function chain that drives event-triggered messaging.
Event-Triggered Messaging
Listen for a real-time behavioral or system event, then deliver a contextual message to the triggering profile.
Function Chain: Event Ingestion > Journey Entry > Condition Evaluation > Message Delivery > Reporting
Applications
The following Adobe applications are used in this use case pattern.
- Adobe Journey Optimizer (AJO) – Journey orchestration with unitary event entry, condition evaluation, wait steps, message authoring, channel configuration, frequency governance, and delivery reporting
- Adobe Real-Time Customer Data Platform (RT-CDP) – Audience evaluation for condition-based filtering within journeys, consent and governance enforcement, profile enrichment
- Adobe Experience Platform (AEP) – Real-time event ingestion via Web SDK, Mobile SDK, or server-side API; data modeling; identity resolution; Edge Network
Foundational functions
The following foundational capabilities must be in place for this use case pattern. For each function, the status indicates whether it is typically required, assumed to be pre-configured, or not applicable.
commerce.productListAdds for cart events, product details, cart value). The schema must be enabled for Real-Time Customer Profile. A corresponding dataset must be created and Profile-enabled.Supporting functions
The following capabilities augment this use case pattern but are not required for core execution.
Application functions
This plan exercises the following functions from the Application Function Catalog. Functions are mapped to implementation phases rather than numbered steps.
Journey Optimizer (AJO)
Real-Time CDP (RT-CDP)
Prerequisites
Complete the following before beginning the implementation.
- [ ] AJO sandbox provisioned with journey creation and publish permissions (F1)
- [ ] XDM ExperienceEvent schema capturing the triggering event with contextual fields, enabled for Real-Time Customer Profile (F2)
- [ ] Real-time event streaming configured via Web SDK, Mobile SDK, or Edge Network Server API with a datastream routing events to the correct AEP dataset (F3)
- [ ] Identity namespaces configured for the identifiers on the triggering event; identity linking rules in place (F4)
- [ ] Channel surface (email, SMS, or push) configured and validated with a successful test send
- [ ] Message content authored, reviewed, and tested with sample profiles
- [ ] Consent fields populated on profiles for the target channel (e.g.,
consents.marketing.email.val) - [ ] If using condition-based audience filtering (Option B/C), streaming-evaluated audience segments defined and actively evaluating
Implementation options
This section describes three implementation options for event-triggered messaging. Each option builds on the previous one, adding additional capabilities.
Option A: Simple event-triggered message
Best for: Immediate, single-message responses where no delay or conditional logic is needed – order confirmation, welcome email, form submission acknowledgment, booking confirmation.
How it works:
The journey listens for a qualifying event via a unitary event entry node. When the event is received, the profile enters the journey, passes through minimal condition evaluation (consent check, profile existence verification), and immediately receives a single message via the configured channel action node.
This is the simplest implementation variant. The journey canvas contains an event entry node, an optional condition node for basic eligibility checks, a single message action node, and an end node. There are no wait steps, no complex branching, and no conversion checks. The message is typically delivered within seconds to minutes of the triggering event.
Event data from the triggering event (product name, order total, form details) can be used for message personalization via contextual attributes in the personalization editor. This approach maximizes speed-to-delivery and minimizes journey complexity.
Key considerations:
- Message is sent regardless of whether the customer self-converts after the event (no conversion check)
- Best suited for events that inherently warrant an immediate response (confirmations, acknowledgments)
- Re-entry rules should be configured carefully – for confirmation-style messages, allow re-entry so each event generates a message; for welcome-style messages, prevent re-entry
Advantages:
- Fastest time-to-delivery (seconds to minutes after the event)
- Simplest journey configuration with minimal moving parts
- Lowest risk of journey failures or stuck profiles
- Easy to test and maintain
Limitations:
- No ability to check whether the customer self-converted before sending
- Cannot incorporate time-delayed conditional logic
- May generate unnecessary messages if the event occurs frequently without frequency governance
Experience League:
Option B: Conditional event-triggered message with wait
Best for: Delayed, conditional responses where the customer should have time to self-convert before receiving the message – cart abandonment (wait 1-4 hours, then check if cart is still abandoned), browse abandonment (wait 24 hours, check if purchase was made), trial expiry (wait until expiry date approaches).
How it works:
The journey listens for a qualifying event, enters the profile, and introduces a wait period before evaluating conditions. After the wait, a condition node checks whether the customer has self-converted (e.g., completed the purchase, renewed the subscription) or whether the original context is still valid. Only if the condition is met (e.g., cart still abandoned) does the journey proceed to message delivery.
The journey canvas contains an event entry node, a wait node (configurable duration or specific date/time), a condition node that checks for a conversion event or profile state change, branching paths (send message vs. exit without sending), a message action node on the qualifying path, and an end node on each branch. Exit criteria can be configured to automatically remove profiles from the journey if the conversion event occurs during the wait period, eliminating the need for the explicit condition check.
This approach reduces unnecessary messaging by giving customers time to self-convert, improving the customer experience and increasing the perceived relevance of messages that are sent.
Key considerations:
- Wait duration significantly impacts conversion rates – shorter waits (1-2 hours) produce higher urgency but more unnecessary sends; longer waits (24-48 hours) reduce volume but may miss the relevance window
- Condition evaluation requires the conversion event to be captured in AEP and associated with the same profile identity
- Exit criteria provide a cleaner alternative to explicit condition nodes for conversion checking
- Re-entry rules must account for the wait period – a profile should not re-enter the journey while already waiting
Advantages:
- Reduces unnecessary messaging by checking for self-conversion
- Produces higher-quality, more relevant communications
- Supports time-sensitive use cases with configurable delay windows
- Exit criteria enable automatic journey removal on conversion
Limitations:
- Increased journey complexity with wait and condition nodes
- Profiles occupy journey slots during wait periods (subject to 91-day journey timeout)
- Requires the conversion event to be ingested into AEP within the wait window for accurate condition evaluation
- Longer time-to-delivery compared to Option A
Experience League:
Option C: Event-triggered with frequency governance
Best for: High-frequency event sources where message fatigue is a concern – page views, product views, search queries, repeat cart additions. Can be applied as an overlay on top of Option A or Option B.
How it works:
This option adds frequency governance to either Option A or Option B to prevent over-messaging. High-frequency behavioral events (such as product views or repeated cart additions) can trigger the journey multiple times within a short period. Without frequency governance, a profile could receive duplicate or excessive messages.
Frequency governance is implemented through two complementary mechanisms: AJO business rules (frequency caps) that limit how many messages a profile receives per channel per time period, and journey-level re-entry rules that define a cooldown period before a profile can re-enter the same journey. Business rules operate at the organization level and enforce caps across all campaigns and journeys (e.g., maximum 3 emails per week), while re-entry cooldown operates at the individual journey level (e.g., a profile cannot re-enter this specific journey within 72 hours of the last entry).
Additionally, conflict and priority management can be configured to assign priority scores to the triggered journey, ensuring that when multiple journeys or campaigns compete for the same profile, the highest-priority communication wins.
Key considerations:
- Frequency caps must balance between preventing fatigue and ensuring important triggered messages are delivered
- Channel-specific caps are recommended – email, SMS, and push have different fatigue thresholds
- Journey re-entry cooldown and organization-level frequency caps work together; both should be configured
- Priority scores determine which communication wins when caps are reached – higher-priority journeys should be assigned higher scores
Advantages:
- Prevents message fatigue from high-frequency event sources
- Maintains brand reputation and subscriber satisfaction
- Organization-level caps provide a safety net across all campaigns and journeys
- Priority scoring ensures the most important messages are delivered when caps are reached
Limitations:
- Some qualifying profiles will be suppressed, potentially missing relevant messages
- Frequency cap configuration adds administrative complexity
- Caps may interact unexpectedly with other active campaigns and journeys sharing the same channel
- Requires ongoing monitoring and adjustment as the messaging portfolio changes
Experience League:
Option comparison
The following table compares the three implementation options across key criteria.
Choose the right option
Use the following decision guidance to select the right implementation option.
-
Does the message need to be sent immediately with no delay? If yes, start with Option A. Confirmation messages, welcome emails, and acknowledgments typically do not require a wait period.
-
Should the customer have time to self-convert before receiving the message? If yes, choose Option B. Cart abandonment, browse abandonment, and trial expiry use cases benefit from a wait period that allows customers to complete the action on their own.
-
Is the triggering event high-frequency (occurs multiple times per session or per day for the same profile)? If yes, add Option C as an overlay on top of Option A or B. Product views, page views, and search events can generate high volumes of triggers that require frequency protection.
-
Are multiple triggered journeys and campaigns active in the sandbox? If yes, add Option C regardless of event frequency to manage cross-journey communication load and prevent channel fatigue.
In practice, most production implementations use Option B + C for abandonment-style use cases (conditional wait with frequency governance) and Option A + C for confirmation-style use cases (immediate send with frequency governance as a safety net).
Implementation phases
The following phases walk through the end-to-end implementation of event-triggered messaging.
Phase 1: Configure event schema and data collection
Application Function: AEP: Data Modeling (F2), AEP: Data Sources & Collection (F3)
What you will configure: The XDM ExperienceEvent schema that captures the triggering event, the dataset that stores these events, and the real-time data collection pipeline (Web SDK, Mobile SDK, or Server API) that streams events into AEP. This phase establishes the data foundation that the journey will listen to.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Commerce event (cart add, purchase, checkout) | Ecommerce use cases – cart abandonment, post-purchase | Requires Commerce field group with productListItems, cart, order fields |
| Web interaction event (page view, product view) | Browse abandonment, content engagement triggers | Requires Web Details field group with webPageDetails, webInteraction fields |
| Application event (app install, uninstall, in-app action) | Mobile engagement triggers | Requires Mobile SDK implementation and Application field group |
| System event (payment failure, subscription change, status update) | Operational notifications | Requires server-side API or source connector to ingest system events |
| Form submission event | Lead generation, enrollment confirmation | Requires custom field group capturing form data fields |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Web SDK | Web-based behavioral events (cart adds, page views, form submissions) | Requires Web SDK installation on the website; events are streamed in real time via Edge Network |
| Mobile SDK | Mobile app events (app opens, in-app actions, push token registration) | Requires Mobile SDK integration in the native app or React Native wrapper |
| Edge Network Server API | Server-side system events (payment processing, subscription management, backend triggers) | No client-side dependency; events sent from the organization’s backend systems |
| Source connector | Events from external systems (CRM, marketing automation, legacy platforms) | Typically batch-based; may not support real-time triggering unless streaming-capable |
UI navigation: Data Collection > Datastreams > New Datastream (for datastream setup); Schemas > Create schema (for event schema); Datasets > Create dataset from schema (for dataset creation)
Key configuration details:
- The event schema must include all fields needed for journey condition evaluation and message personalization
- The datastream must have both Adobe Experience Platform and Adobe Journey Optimizer services enabled
- The dataset must be enabled for Real-Time Customer Profile so events are associated with unified profiles
- Event data must include an identity field (email, CRM ID, ECID) that can resolve to a known profile
Experience League documentation:
Phase 2: Configure identity and profile
Application Function: AEP: Identity & Profile Configuration (F4)
What you will configure: Identity namespaces for the identifiers on the triggering event, primary identity designation on the event schema, identity linking rules for cross-device resolution, and a merge policy for profile unification. This ensures the triggering event is associated with a unified customer profile so the journey can resolve contact information and deliver the message.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Email address | Events from authenticated web sessions or forms where email is captured | Direct resolution to a contactable identity; simplest path to email delivery |
| CRM ID | Events from authenticated systems where the CRM ID is the primary identifier | Requires CRM ID namespace creation; profile must have a linked email or phone for message delivery |
| ECID (Experience Cloud ID) | Anonymous web or app events where no authenticated identity is available | Requires identity stitching to link ECID to a known identity; messages cannot be sent to ECID alone |
| Phone number | Events from mobile or call center interactions | Supports SMS delivery; requires Phone namespace |
UI navigation: Identities > Create identity namespace; Schemas > Select schema > Select field > Identity > Set as primary identity; Profiles > Merge policies
Key configuration details:
- Anonymous events (ECID-only) cannot trigger message delivery until the ECID is linked to a known contactable identity (email, phone) via the identity graph
- The merge policy used by AJO must be consistent with the one used for audience evaluation
- For web-based triggered messaging, ensure the identity graph links ECID to authenticated identities through login events
Experience League documentation:
Phase 3: Set up channel surfaces
Application Function: AJO: Channel Configuration
What you will configure: The channel surface (preset) that defines the sending infrastructure for the triggered message – subdomain delegation, IP pool, sender identity, reply-to address, unsubscribe handling, and channel-specific credentials (SMS provider, push certificates). A valid channel surface must exist before message content can be created or journeys can be published.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Most triggered messaging use cases – abandonment recovery, confirmations, onboarding | Requires subdomain delegation, IP pool, sender configuration; supports rich HTML content and personalization | |
| SMS | Time-sensitive notifications, concise alerts, audiences with high SMS engagement | Requires SMS provider integration (Sinch, Twilio, Infobip); subject to character limits and stricter consent requirements |
| Push notification | Mobile app engagement, re-engagement of app users | Requires push credential configuration (APNs for iOS, FCM for Android); user must have the app installed with push enabled |
| Multiple channels | Comprehensive engagement strategy using channel preference or fallback logic | Requires multiple channel surfaces; channel selection can be managed via journey condition nodes |
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Full delegation | Organization wants Adobe to manage all DNS records for the sending subdomain | Simplest setup; Adobe manages SPF, DKIM, DMARC records automatically |
| CNAME delegation | Organization wants to maintain DNS control while pointing to Adobe infrastructure | Requires manual DNS record management; provides more organizational control over DNS |
UI navigation: Administration > Channels > Subdomains (for subdomain setup); Administration > Channels > IP pools (for IP pool configuration); Administration > Channels > Channel surfaces > Create surface (for surface creation)
Key configuration details:
- Subdomain verification and DNS propagation can take up to 48 hours
- New IP pools require a warmup plan (2-4 weeks of gradual volume increase)
- Configure one-click list-unsubscribe headers for email compliance
- For SMS, configure the provider credentials before creating the SMS channel surface
- For push, configure APNs and FCM credentials before creating the push channel surface
Experience League documentation:
Phase 4: Create message content
Application Function: AJO: Message Authoring
What you will configure: The message content that will be delivered by the journey, including layout design, personalization tokens using profile and event attributes, conditional content blocks, reusable fragments (headers, footers, legal disclaimers), and content preview and testing.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Start from an existing template | Organizational templates exist and brand consistency is required | Fastest path to content creation; ensures brand compliance; template changes propagate to new messages |
| Design from scratch in Email Designer | Custom layout needed for this specific triggered message | Full creative control; drag-and-drop visual editor; slower but more flexible |
| Import HTML | Content is designed by an external team or agency and provided as HTML | Requires HTML coding expertise; may not fully support all Email Designer features |
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Event contextual attributes | The message should include details from the triggering event (product name, cart value, form fields) | Use contextual event attributes in the personalization editor; data comes from the triggering event payload |
| Profile attributes | The message should include profile-level data (first name, loyalty tier, location) | Use profile attributes via XDM paths (e.g., profile.person.name.firstName); data comes from the unified profile |
| Both event and profile attributes | The message should combine event context with profile personalization | Most common approach for triggered messages; ensures both relevance (event) and personalization (profile) |
UI navigation: Content Management > Content Templates > Browse (for template selection); Campaign or Journey action > Edit content > Email Designer (for content design); Select text component > Personalization icon (for adding personalization)
Key configuration details:
- Use contextual attributes to personalize with data from the triggering event (e.g., product name, cart value)
- Use profile attributes for name, preferences, and loyalty data
- Configure conditional content blocks to vary content by profile segment or attribute (e.g., different CTA for loyalty members)
- Create reusable fragments for headers, footers, and legal disclaimers shared across triggered messages
- Preview with multiple test profiles to verify personalization renders correctly
- Send proofs to internal stakeholders before publishing the journey
Experience League documentation:
Phase 5: Create and configure the journey
Application Function: AJO: Journey Orchestration, AJO: Frequency & Business Rules (Option C), AJO: Conflict & Priority Management
What you will configure: The journey that listens for the triggering event and orchestrates message delivery. This is the core implementation phase where the journey canvas is designed with the event entry node, condition nodes, wait steps (for Option B), message action nodes, and exit criteria. This phase also covers frequency governance (Option C) and conflict/priority configuration.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Allow re-entry (with cooldown) | The event can legitimately recur and each occurrence warrants a message (e.g., each cart abandonment should trigger a recovery message) | Set a cooldown period (minimum 5 minutes) to prevent rapid re-entry from duplicate events; typical cooldown ranges from 1 hour to 72 hours |
| No re-entry | The message should only be sent once per profile regardless of event recurrence (e.g., welcome message after first registration) | Profile is permanently excluded after first journey completion; appropriate for one-time lifecycle messages |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Short wait (1-4 hours) | High-urgency use cases like cart abandonment where immediate follow-up is effective | Higher message volume; may catch some self-converters; best for high-value cart recovery |
| Medium wait (12-24 hours) | Moderate-urgency use cases like browse abandonment or content engagement | Balanced approach; reduces unnecessary sends while maintaining relevance |
| Long wait (2-7 days) | Low-urgency use cases like trial expiry reminders or periodic check-ins | Lower message volume; higher risk of losing contextual relevance |
| Custom date/time | Use cases tied to a specific date (e.g., send 3 days before trial expiry date) | Wait until a calculated date/time; uses the custom expression editor |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Conversion event (e.g., purchase completed) | Cart or browse abandonment where the goal is conversion | Profile exits automatically when the conversion event is detected; cleanest approach for Option B |
| Audience membership change | Profile should exit if they leave a qualifying segment | Requires streaming-evaluated audience that updates in near real-time |
| Journey timeout (91-day max) | Default behavior – profile exits after the maximum journey duration | Safety net; should not be the primary exit mechanism for short-lived triggered journeys |
| No explicit exit criteria | Simple confirmations (Option A) where every qualifying profile should receive the message | Profile exits naturally after the message action and end node |
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Channel-specific caps (e.g., 3 emails/week, 1 SMS/day) | Different channels have different fatigue thresholds | Recommended approach; respects the intrusiveness level of each channel |
| Global cap (e.g., 5 messages/week across all channels) | Simplified governance across all communication types | Easier to manage but less nuanced; may over-restrict less intrusive channels |
| Journey-level re-entry cooldown only | Frequency governance needed for this specific journey but not organization-wide | Simplest implementation; does not protect against cross-journey fatigue |
UI navigation: Journeys > Create Journey (for journey creation); Journey canvas > Drag event activity (for event entry); Journey canvas > Drag “Wait” activity (for wait configuration); Journey canvas > Drag “Condition” activity (for condition branching); Journey properties > Exit criteria (for exit configuration); Administration > Business rules > Create rule (for frequency caps)
Key configuration details:
- Configure the journey event by selecting the event schema and defining the qualifying conditions
- For Option B, add the wait node immediately after the event entry and before any condition evaluation
- Configure condition nodes using profile attributes, event data, or audience membership checks
- Link the message action node to the channel surface and authored content from Phases 3 and 4
- Set the journey timeout to an appropriate duration (shorter than 91 days for triggered journeys)
- For Option C, create frequency rules via Administration > Business rules before publishing the journey
- Assign a priority score to the journey if other campaigns or journeys target overlapping audiences
Where options diverge:
For Option A (Simple Event-Triggered):
The journey canvas is minimal: event entry > optional consent/eligibility condition > message action > end. No wait steps or conversion checks. Set re-entry rules based on whether the event should generate a message every time it occurs.
For Option B (Conditional with Wait):
Add a wait node after event entry. After the wait, add a condition node to check for conversion (e.g., check if commerce.purchases event occurred after journey entry) or use exit criteria to automatically remove converted profiles. Branch to the message action on the “not converted” path and to an end node on the “converted” path.
For Option C (Frequency Governance):
Configure organization-level frequency caps via Administration > Business rules before publishing. Set journey-level re-entry cooldown in the journey properties. Optionally, assign a priority score via journey properties to control which communication wins when caps are reached. This can be applied on top of either Option A or Option B.
Experience League documentation:
Phase 6: Test and deploy the journey
Application Function: AJO: Journey Orchestration
What you will configure: Test mode validation to verify the journey behaves as expected with test profiles, followed by journey publication to make it live.
UI navigation: Journey canvas > Test mode toggle (for testing); Journey canvas > Publish (for deployment)
Key configuration details:
- Enable test mode on the journey canvas to simulate event triggers with test profiles
- Select test profiles that have valid channel contact information (email address, phone number)
- Trigger the test event and verify the test profile traverses the expected path
- For Option B, verify that the wait step behaves correctly and that condition evaluation produces the expected branching
- Verify that personalization tokens render correctly in the test message
- After successful testing, publish the journey to make it live
- Monitor the journey status and initial profile entry metrics after publication
Experience League documentation:
Phase 7: Monitor and report on performance
Application Function: AJO: Reporting & Performance Analysis, S4: Monitoring & Observability, S5: Reporting & Analysis
What you will configure: Live and historical journey reports for delivery and engagement monitoring, platform alerts for event ingestion and journey processing failures, and optionally CJA workspaces for deeper cross-channel analysis of triggered messaging effectiveness.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| AJO native reports only | Operational monitoring of delivery metrics is sufficient | Available immediately; covers sent, delivered, bounced, opened, clicked; no additional configuration needed |
| AJO native + CJA integration | Cross-channel analysis, conversion attribution, and trend analysis are needed | Requires CJA connection and data view linked to AJO datasets; provides deeper analytical capabilities |
UI navigation: Journeys > Select journey > Live report (for live monitoring); Journeys > Select journey > All time report (for historical analysis); Alerts > Alert rules > Subscribe (for alert configuration)
Key configuration details:
- Access the journey live report during active execution to monitor profile entries, exits, and delivery metrics
- Review the historical report after the journey has been active for sufficient time to accumulate meaningful data
- Configure alerts for source flow run failures (event ingestion) and journey processing delays
- For CJA integration, ensure the CJA connection includes AJO experience event datasets (Message Feedback Event Dataset, Email Tracking Experience Event Dataset)
Experience League documentation:
Implementation considerations
This section covers guardrails, common pitfalls, best practices, and trade-off decisions for event-triggered messaging implementations.
Guardrails and limits
The following platform guardrails and limits apply to event-triggered messaging implementations.
- Unitary event throughput: Maximum 5,000 events per second per sandbox for unitary event journeys – Journey Optimizer guardrails
- Live journey limit: Maximum 500 live journeys per sandbox – Journey Optimizer guardrails
- Journey canvas limit: Maximum 50 activities per journey canvas
- Journey timeout: Maximum journey duration is 91 days (global timeout)
- Re-entry cooldown: Minimum re-entry cooldown is 5 minutes
- Frequency cap configurations: Maximum 10 capping configurations per sandbox
- Channel surfaces: Maximum 10 channel surfaces per channel type per sandbox
- Streaming ingestion: Maximum 20,000 records per second per HTTP connection – Ingestion guardrails
- Computed attributes: Maximum 25 computed attributes per sandbox – Computed attributes guardrails
- Content fragments: Maximum 30 content fragments per message
- Live report refresh: Live reports refresh every 60 seconds and show the last 24 hours of data
- Historical report latency: Historical (all time) reports may take up to 2 hours to fully populate after execution ends
Common pitfalls
Be aware of the following common issues when implementing event-triggered messaging.
-
Anonymous events without identity resolution: Triggering events that only carry an ECID (anonymous cookie ID) cannot resolve to a contactable profile for message delivery. Ensure the triggering event includes an authenticated identity or that the identity graph links the ECID to a known contact. Without identity resolution, profiles enter the journey but fail at the message delivery step.
-
Missing conversion event for Option B condition checks: If the conversion event (e.g., purchase) is not ingested into AEP or is not associated with the same profile identity as the triggering event, the condition check will incorrectly evaluate as “not converted” and send unnecessary messages. Verify that conversion events flow into AEP in real time and share an identity with the triggering event.
-
Overly permissive re-entry rules: Allowing re-entry without a cooldown period on high-frequency event sources can cause the same profile to receive multiple messages within minutes. Always set a re-entry cooldown that matches the business context (e.g., 4-hour cooldown for cart abandonment, 24-hour cooldown for browse abandonment).
-
Wait step timezone misalignment: Wait steps process in UTC by default. If the journey targets profiles across multiple time zones and the wait should align with the recipient’s local time, configure the timezone settings on the journey accordingly.
-
Frequency caps conflicting with other campaigns: Organization-level frequency caps apply across all campaigns and journeys. A new triggered journey may be suppressed if profiles have already reached their cap from other active campaigns. Monitor the suppression rate and adjust priority scores to ensure important triggered messages are prioritized.
-
Journey publish failure due to missing dependencies: Every branch in the journey canvas must terminate with an end activity. All action nodes must reference valid channel surfaces with active message content. Verify all dependencies before publishing.
Best practices
Follow these recommendations for successful event-triggered messaging implementations.
-
Start simple, then iterate: Begin with Option A for new triggered messaging use cases. Add wait and condition logic (Option B) only after validating the event pipeline and message delivery. Add frequency governance (Option C) when multiple triggered journeys are active.
-
Use exit criteria instead of condition nodes for conversion checks: Exit criteria automatically remove profiles from the journey when a qualifying event (e.g., purchase) occurs, eliminating the need for an explicit condition node after the wait step. This produces a cleaner journey canvas and more responsive conversion detection.
-
Test with real event data in a development sandbox: Use test mode with actual event payloads (not just test profiles) to validate that event schema fields, personalization tokens, and condition expressions work correctly with production-like data.
-
Set event-specific re-entry cooldowns: Match the cooldown period to the business context of the triggering event. Cart abandonment journeys typically use a 4-24 hour cooldown; confirmation journeys may allow immediate re-entry; onboarding journeys should prevent re-entry entirely.
-
Monitor the suppression rate as a health metric: If the suppression rate (profiles qualifying but not receiving messages due to frequency caps or conditions) exceeds 30-40%, review whether caps are too restrictive or whether the triggering event is too broadly defined.
-
Version journeys instead of editing live ones: A live journey cannot be edited directly. Create a new version by duplicating the journey, making changes, then stopping the old version and publishing the new one. This avoids disrupting profiles currently in the journey.
-
Include a fallback/default path in condition nodes: Always configure a default (else) path in condition nodes to handle unexpected profile states. Profiles that do not match any condition branch should exit gracefully rather than remaining stuck.
Trade-off decisions
Consider the following trade-offs when designing your event-triggered messaging implementation.
- Option A favors: Speed, simplicity, confirmation-style use cases where every event warrants a message
- Option B favors: Relevance, reduced message fatigue, abandonment-style use cases where self-conversion is common
- Recommendation: Use Option A for transactional and confirmation messages where speed is the primary value. Use Option B for recovery and re-engagement messages where relevance outweighs speed. Experiment with wait durations to find the optimal balance for each use case.
- Strict caps favor: Customer experience, brand reputation, deliverability (fewer spam complaints)
- Permissive caps favor: Message coverage, conversion opportunities, avoiding missed triggers
- Recommendation: Start with industry-standard caps (3-5 emails/week, 1-2 SMS/week, 2-3 push/day) and adjust based on engagement metrics and unsubscribe rates. Assign higher priority scores to triggered messages so they win over batch campaigns when caps are reached.
- Simple journeys favor: Faster implementation, easier debugging, lower maintenance burden
- Sophisticated journeys favor: More precise targeting, better personalization, reduced unnecessary sends
- Recommendation: Start with the simplest journey that meets the business requirement. Add complexity incrementally based on performance data. A simple journey that works reliably is more valuable than a complex journey with undetected errors.
Related documentation
The following resources provide additional detail on the capabilities used in this implementation.