Adobe Journey Optimizer Business Practitioner cheat sheet

AJO is built on Adobe Experience Platform; profiles, datasets, and schemas live in AEP while journeys, messages, and campaigns live in AJO.

AJO supports two outbound patterns: journeys (event- or audience-triggered, multi-step, stateful) and campaigns (single-shot or scheduled, no journey state).

Inbound channels include web in-app messages and code-based experiences; outbound channels include email, push, SMS, and direct mail via third-party providers.

Journey entry sources are events (unitary), audience qualification, and business events; campaigns are launched manually or on a schedule.

Real-time decisioning (offers) is a separate capability from message personalization; it selects offers at decision time using eligibility rules and ranking.

AJO licensing is typically measured by billable profiles (profiles messaged in a period) and by channel volumes; message authoring does not itself consume billable profile counts.

Typical use cases: welcome/onboarding, abandoned cart, transactional confirmations, re-engagement, and milestone or lifecycle campaigns.

AJO requires a production sandbox with AEP profile data; journeys cannot run against data not ingested into a profile-enabled dataset.

A journey has exactly one entry (a read-audience, an event, or a business event) and one or more end paths; branches are created with conditions or percentage splits.

Wait activities can be duration-based or date-based; a wait node holds each profile independently, and journey re-entry rules govern whether a profile can re-enter.

Re-entry options are: no re-entry, re-entry after a fixed period, or unlimited re-entry; the setting is defined at the journey level.

Condition activities evaluate profile attributes, context (event) attributes, or expressions; the true/false branches must each connect to a downstream node or end.

The journey canvas enforces that every path terminates; unconnected nodes or dangling branches block publication.

Test mode publishes a journey in test profile mode, allowing simulated entry with a chosen profile without sending real messages to real customers.

Journey versions: editing a live journey creates a new version; stopping a journey halts new entries but profiles already in flight may complete or be removed depending on stop behavior.

Orchestration limits include a maximum number of activities per journey and per-node concurrency; exceeding them causes profiles to queue rather than fail.

A campaign is configured with an audience, a schedule (immediate or date/time), and an action (channel message); it does not maintain per-profile state across steps.

Email authoring supports HTML import, a drag-and-drop designer, and content fragments; fragments are reusable, centrally managed content blocks with their own approval status.

Personalization uses the expression editor with Handlebars-style syntax: profile attributes, context attributes, and helper functions such as date formatting and conditional logic.

Proof sending renders the message with a chosen test profile; proofs verify rendering and personalization, not delivery to the production audience.

Channel surfaces define sender identity and configuration (e.g., email sender address, push app/platform); a message must reference a compatible surface.

Frequency rules and send-time optimization are configured per channel and constrain when a message can be sent to a profile.

Campaign and message content can be A/B tested by defining variants and an audience split; the winning variant is selected based on the configured success metric.

Message authoring content is validated before publication; missing required fields (subject, sender, target surface) prevent the campaign from being activated.

A segment is defined in AEP by a Profile Query Language (PQL) expression; a segment definition evaluates against the unified profile and produces an audience.

Segment evaluation types: batch (scheduled, e.g., daily), streaming (near real-time as events arrive), and edge (evaluated at the edge for low-latency use cases).

Audience-triggered journeys use audience qualification; a profile enters when it qualifies for the segment, subject to re-entry rules.

Identity stitching merges identities into a single profile via the identity graph; the profile's merge policy determines which attribute values win when sources conflict.

Profile attributes are typed by the XDM schema; segments referencing an attribute must use the correct data type and namespace.

Segment membership changes trigger journey entry or exit only when the journey is configured to listen for that audience; exiting a segment does not automatically remove a profile from an in-flight journey.

Estimated audience size is available in the segment definition; actual counts populate after evaluation and can differ from the estimate.

Consent and governance labels (e.g., marketing vs. transactional) are evaluated at send time; a profile without consent for a channel is excluded from messaging.

Decisioning objects: offer items (the actual offer), collections (groupings), placements (where the offer is shown), and decision rules/eligibility constraints.

A decision policy (formerly offer decision) combines placements, collections, and ranking; it selects the best offer per profile at decision time.

Eligibility is enforced by decision rules (PQL) and by constraints such as capping (per profile, per offer) and global frequency limits.

Ranking can be formula-based (weighted attributes) or AI-based; the ranking method determines which eligible offer is presented.

Fallback offers are used when no eligible offer is available; a decision policy should define a fallback to avoid empty placements.

Offers can be delivered via the Offer Decisioning API (for web/apps) or embedded in AJO messages using the offer decisioning personalization helper.

Personalization at decision time uses profile attributes and context; the same profile may receive different offers across placements within one decision.

Offer and decision policy changes propagate to live experiences; testing a decision policy requires a test profile and a simulated decision request.

Journey reports show entry, exit, and drop-off by node; campaign reports show delivery, open, click, and bounce metrics per channel.

Channel metrics depend on provider feedback (e.g., email bounces and opens via tracking); metrics not returned by a provider appear as unavailable rather than zero.

Test mode and proofs validate rendering and personalization; A/B tests validate variant performance against a defined success metric.

AJO uses Adobe Experience Platform governance: data usage labels and policies restrict how attributes can be used in messaging.

Audit and approval: content fragments and messages can require approval workflows before publication; approval status gates activation.

Alerts and monitoring surface journey failures, delivery issues, and system health; alerts are configured per capability and notify via email or webhook.

Sandbox isolation separates development and production journeys, audiences, and offers; promotion between sandboxes requires exporting and importing assets.

Success events (e.g., a conversion event) are defined per journey or campaign to attribute outcomes; without a defined success event, conversion reporting is not available.