Known-visitor web/app personalization
This reference plan provides a complete implementation guide for delivering personalized content to identified visitors across digital surfaces using Adobe Journey Optimizer (AJO) and Adobe Real-Time Customer Data Platform (RT-CDP). It is designed for solution architects, marketing technologists, and implementation engineers who need to understand all viable implementation approaches, the decisions that must be made at each phase, and the Experience League documentation that supports configuration.
Known-visitor web/app personalization is the primary personalization pattern for authenticated digital experiences. Unlike anonymous visitor personalization, which relies solely on in-session behavioral signals, this pattern leverages the full unified profile: historical behavioral data, segment membership, loyalty tier, purchase history, lifecycle stage, computed attributes, and propensity scores. It supports personalization across web pages (via AJO web channel), mobile in-app messages, and content cards.
This guide presents all viable implementation options – segment-based, decisioning-based, and multi-surface – with trade-offs, decision guidance, and references to Adobe Experience League documentation.
Use case overview
Organizations with authenticated digital properties – e-commerce sites, banking portals, subscription services, loyalty programs, mobile apps – need to deliver personalized experiences that reflect each customer’s relationship with the brand. When a visitor logs in or is recognized through identity resolution, the platform can access their full unified profile and deliver content tailored to their specific attributes, behaviors, and preferences.
This pattern addresses the scenario where an identified visitor arrives on a web property or opens a mobile app, and the system must determine the optimal content, offer, or promotion to display based on real-time profile data and audience membership. The personalization decision happens at the edge in milliseconds, enabling sub-second content delivery without perceptible latency.
The pattern supports both deterministic personalization (where specific content maps to specific audience segments) and dynamic decisioning (where AJO Decisioning evaluates eligibility rules and ranking strategies to select the optimal content per profile). It spans multiple digital surfaces – web pages, mobile in-app messages, and content cards – enabling consistent personalization across the customer’s digital journey.
Key business objectives
The following business objectives are supported by this use case pattern.
Deliver personalized customer experiences
Tailor content, offers, and messaging to individual preferences, behaviors, and lifecycle stage. For more information, see Deliver personalized customer experiences.
KPIs: Engagement, Conversion Rates, Customer Satisfaction (CSAT)
Increase website engagement
Improve time on site, pages per session, and interaction with web content through relevant experiences. For more information, see Increase website engagement.
KPIs: Time On (web) Page, Engagement, Conversion Rates
Increase mobile app engagement
Drive daily active usage, feature adoption, and in-app conversions through personalized in-app experiences.
KPIs: Engagement, Retention, Conversion Rates
Example tactical use cases
The following are common tactical implementations of this pattern:
- Homepage hero personalization by loyalty tier or lifecycle stage – display different hero banners based on whether the customer is new, active, at-risk, or VIP
- Product recommendation carousel based on purchase history – surface relevant product suggestions using past purchase data and product affinity scores
- Personalized promotional banner by customer segment – show different promotions to high-value, at-risk, and new customer segments
- In-app message for mobile users based on feature adoption – guide users to underutilized features based on their usage patterns
- Content card with personalized offer on account dashboard – persistent, dismissible offers tailored to the customer’s profile
- Personalized pricing or discount display based on customer tier – show tier-specific pricing or exclusive discounts to loyalty program members
- Cross-sell recommendation widget based on owned products – suggest complementary products or services based on current portfolio
- Personalized navigation or content ordering based on interests – reorder content modules or navigation elements based on demonstrated preferences
Key performance indicators
The following KPIs help measure the effectiveness of this use case pattern.
Use case pattern
This section describes the core pattern and its function chain.
Known-visitor web/app personalization
Deliver personalized content, offers, or promotions to an identified visitor based on real-time profile and segment membership across web, mobile in-app, and content card surfaces.
Function chain: Audience Evaluation > Personalization Decisioning > Surface/Channel Configuration > Content Delivery > Impression Tracking > Reporting
Applications
The following applications are used in this use case pattern.
- Adobe Journey Optimizer (AJO) – Web channel configuration, in-app channel configuration, content card channel configuration, decisioning (offer selection and ranking), message authoring (personalized content creation), campaign execution, content experimentation, and reporting
- Adobe Real-Time Customer Data Platform (RT-CDP) – Audience evaluation (edge, streaming, and batch), real-time profile lookup via Edge Network, profile enrichment with computed attributes and propensity scores
- Adobe Experience Platform (AEP) – Profile store, identity service, Web SDK, Mobile SDK, datastream configuration, edge network delivery
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.
isActiveOnEdge: true to resolve the authenticated profile at the edge.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
Before implementing this use case pattern, ensure the following are in place:
- [ ] Web SDK implemented on target web properties with
alloy("sendEvent")configured for page views and interaction tracking - [ ] Mobile SDK implemented on target mobile apps (if in-app or content card surfaces are used)
- [ ] Datastream configured with Adobe Journey Optimizer service enabled
- [ ] Profile schema includes attributes used for personalization (loyalty tier, purchase history, product interests, lifecycle stage)
- [ ] Experience Event schema configured for impression and conversion tracking
- [ ] Known identity namespaces created and identity stitching operational between anonymous (ECID) and authenticated identities
- [ ] Edge merge policy configured with
isActiveOnEdge: true - [ ] Audiences defined with edge-eligible evaluation for real-time personalization
- [ ] Content assets (images, copy, CTAs) prepared for each personalization variant
- [ ] Personalization strategy documented: which attributes drive which content, for which surfaces
Implementation options
This section describes the available implementation approaches for this use case pattern.
Option A: Segment-based web personalization
Best for: Deterministic personalization where specific content variants map directly to audience segments – loyalty tier-specific hero banners, lifecycle stage messaging, customer segment promotional content. Ideal when the content-to-segment mapping is well-defined and does not require dynamic ranking or optimization.
How it works:
Segment-based personalization maps content variants directly to audience segments. When a known visitor’s profile is evaluated against edge-eligible audiences at page load, the system determines which segments the visitor belongs to and displays the corresponding content variant. Selection is based on segment membership priority – if a visitor qualifies for multiple segments, the highest-priority segment’s content is displayed.
This approach uses AJO web channel campaigns (or in-app/content card campaigns) with conditional content rules or multiple treatment targeting configurations. Each audience segment is associated with a specific content experience. No decisioning engine is involved – the content selection logic is entirely segment-driven.
Content is authored using the AJO message authoring interface with dynamic content blocks that render different content based on audience membership or profile attributes. The Web SDK or Mobile SDK delivers the personalized experience in real time via the Edge Network.
Key considerations:
- Content variants must be pre-authored for each segment
- Segment definitions must be edge-eligible for real-time qualification
- Adding new segments or content variants requires updating the campaign configuration
- Content selection is deterministic – the same segment always sees the same content
Advantages:
- Simple to implement and maintain with clear content-to-segment mapping
- Easy to understand and explain the personalization logic to stakeholders
- No decisioning overhead – faster content resolution
- Full control over which content each segment receives
Limitations:
- Limited flexibility when the number of segments and content variants grows
- Cannot dynamically optimize content selection based on profile-level signals beyond segment membership
- Adding new content variants requires manual campaign updates
- Does not support next-best-offer scenarios where multiple offers compete for the same placement
Experience League:
Option B: Decisioning-based personalization
Best for: Dynamic personalization where the optimal content or offer must be selected per profile using eligibility rules and ranking strategies – next-best-offer on homepage, personalized product recommendations, dynamic promotional banner selection. Ideal when multiple offers or content items compete for the same placement and the system must choose the best one.
How it works:
Decisioning-based personalization uses AJO Decisioning to evaluate each visitor’s profile against a catalog of content items or offers, applying eligibility rules to determine which items qualify, and then applying a ranking strategy (priority-based, formula-based, or AI-ranked) to select the optimal item for each placement.
The implementation involves creating placements (where content appears), defining offers with eligibility rules and content representations, organizing offers into collections, and creating decision policies that bind placements to collections with ranking strategies. At runtime, when a visitor loads a page, the Edge Network evaluates the decision policy against the visitor’s profile and returns the selected offer content.
This approach supports sophisticated personalization scenarios including next-best-offer, personalized promotions with capping, and AI-optimized content selection. Offers can have per-profile and global capping limits, validity date ranges, and complex eligibility criteria combining profile attributes and audience membership.
Key considerations:
- Requires more upfront configuration (placements, offers, eligibility rules, collections, decisions)
- Ranking strategies can be priority-based (manual), formula-based (custom expression), or AI-ranked (auto-optimization)
- AI ranking requires a minimum of 1,000 conversion events for model training
- Offer capping counters may have a slight lag under high-throughput scenarios
- A fallback offer must be configured for cases where no personalized offer qualifies
Advantages:
- Dynamic, per-profile content selection without hardcoded segment-to-content mapping
- Supports complex eligibility criteria and ranking logic
- AI-ranked option enables automatic optimization without manual intervention
- Offer capping prevents over-exposure of specific content
- Centralized offer management – offers can be reused across campaigns and channels
Limitations:
- Higher implementation complexity than segment-based personalization
- AI ranking requires sufficient conversion event volume for training
- Decisioning evaluation adds marginal latency compared to direct segment-based content delivery
- Formula-based ranking requires careful design to avoid unintended prioritization
Experience League:
How this differs from Offer decisioning Option B:
The infrastructure is identical — both use AJO Decisioning at the edge with Web SDK and an edge-active merge policy. The difference is what is being selected. This option manages content items where the selection criterion is personalization fit (segment membership, behavioral ranking). Offer decisioning Option B manages a governed offer catalog where eligibility rules, capping limits, and validity windows are business requirements. If your item set requires per-profile impression capping, regulatory eligibility constraints, or offer lifecycle management, use Offer decisioning Option B instead.
Option C: Multi-surface personalization (web + in-app + content card)
Best for: Consistent personalization across multiple digital surfaces – delivering coordinated personalized experiences on web pages, mobile in-app messages, and content cards. Ideal when the organization has both web and mobile app properties and wants unified personalization logic across all digital touchpoints.
How it works:
Multi-surface personalization extends either Option A (segment-based) or Option B (decisioning-based) to deliver personalized content across multiple AJO surface types. Each surface type – web, in-app, content card – may have different content formats and delivery mechanisms, but the underlying personalization logic (audience membership or decisioning) is shared.
The implementation involves configuring channel surfaces for each surface type, authoring surface-specific content (web HTML/CSS for web surfaces, structured messages for in-app, card layouts for content cards), and creating campaigns that target the appropriate surface. The Web SDK handles web surface delivery, while the Mobile SDK handles in-app and content card delivery.
Content cards are particularly valuable for persistent, dismissible personalized messages on account dashboards or app home screens. In-app messages are ideal for contextual, session-specific communications. Web personalization handles hero banners, recommendation widgets, and promotional content.
Key considerations:
- Each surface type requires its own channel surface configuration and content authoring
- Web SDK and Mobile SDK must both be implemented and configured
- Content must be designed for each surface format (different dimensions, layouts, interaction patterns)
- Shared audiences and decisioning logic ensure consistency across surfaces
- Testing must cover all surface types across devices
Advantages:
- Consistent personalization experience across all digital touchpoints
- Shared audience and decisioning logic reduces duplication
- Content cards provide a persistent, non-intrusive personalization surface
- In-app messages enable contextual, session-specific personalization on mobile
Limitations:
- Highest implementation complexity – requires configuration for each surface type
- Requires both Web SDK and Mobile SDK implementation
- Content must be designed and maintained for each surface format
- Testing scope increases with each additional surface type
Experience League:
Option comparison
The following table compares the three implementation options.
Choose the right option
Start with these questions to select the right implementation approach:
-
How many surfaces? If you need personalization on both web and mobile app, choose Option C (which builds on either A or B for the underlying logic). If web-only, choose between A and B.
-
How dynamic is your content selection? If you have a well-defined mapping of segments to content variants (e.g., 3-5 loyalty tiers, each with a specific hero banner), choose Option A. If you need to select from a catalog of offers with complex eligibility and ranking, choose Option B.
-
Do you need AI-optimized selection? If you want the system to automatically learn and optimize which content performs best for each profile, choose Option B with AI-ranked decisioning.
-
How many content variants? If you have fewer than 10 content variants with clear segment mappings, Option A is simpler. If you have dozens of offers that need eligibility filtering and ranking, Option B scales better.
-
Do you plan to extend to other channels? If your decisioning logic should eventually serve offers across email, web, and other channels, Option B provides the centralized decisioning foundation that cross-channel offer decisioning extends.
Implementation phases
This section walks through each phase of the implementation in detail.
Phase 1: Define audiences and configure evaluation
Application function: RT-CDP: Audience Evaluation
What you will configure: Define the audiences that drive personalization content selection. These audiences represent the visitor segments that will receive personalized experiences – loyalty tiers, lifecycle stages, behavioral cohorts, or product affinity groups.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Edge evaluation | Real-time web/app personalization requiring sub-second qualification | Limited to simple profile attribute checks and segment membership. No time-series queries or complex aggregations. Required for known-visitor personalization. |
| Streaming evaluation | Near real-time qualification when profiles enter/exit audiences based on behavioral events | Supports single event and limited time window queries. Audience changes reflected within minutes. Suitable for in-app and content card surfaces where slight delay is acceptable. |
| Batch evaluation | Daily audience refreshes for segments based on complex aggregations or historical patterns | Full segment rule function support. Not suitable for real-time personalization but can complement edge audiences with complex pre-computed segments. |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Profile attributes (loyalty tier, lifecycle stage) | Deterministic personalization based on known customer properties | Stable, well-defined attributes. Easy to map to content variants. Available at the edge if the profile is properly configured. |
| Behavioral signals (purchase history, browsing patterns) | Personalization based on recent behaviors and engagement patterns | Requires computed attributes or streaming segments. More dynamic but more complex to maintain. |
| Propensity scores (Customer AI) | Predictive personalization based on likelihood to convert, churn, or purchase | Requires computed attributes. Enables sophisticated personalization but requires ML model training data. |
| Combined approach | Most production implementations | Uses profile attributes for primary segmentation with behavioral signals and propensity scores for refinement. |
UI navigation: Customer > Audiences > Create audience > Build rule
Key configuration details:
- Define audiences using Segment Builder with segment rule expressions referencing profile attributes
- Ensure segment rule expressions qualify for edge evaluation (simple attribute checks, segment membership)
- Configure edge-eligible audiences for real-time personalization use cases
- Consider suppression audiences to exclude recently converted or opted-out visitors
Experience League documentation:
Phase 2: Set up decisioning (Option B and C only)
Application function: AJO: Decisioning
What you will configure: Set up the decisioning infrastructure that dynamically selects the optimal content or offer for each visitor. This includes placements (where offers appear), offers (what content is available), eligibility rules (who qualifies), ranking strategies (how to choose the best), and decision policies (how everything connects).
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Priority-based (manual) | Simple use cases with clear offer hierarchy | Each offer has a manual priority value. Highest priority eligible offer wins. Easy to understand and control. |
| Formula-based (custom expression) | When ranking should consider profile attributes | Custom ranking formulas reference profile data (e.g., score by loyalty tier + recency). Flexible but requires formula design and testing. |
| AI-ranked (auto-optimization) | When you want the system to automatically optimize offer selection | ML model learns which offers perform best for which profiles. Requires minimum 1,000 conversion events for training. Best for high-traffic placements. |
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Per-profile cap | Prevent fatigue from seeing the same offer repeatedly | Limits impressions per visitor over a time period. Ensures variety in the personalized experience. |
| Global cap | Limit total impressions for a promotion or limited-availability offer | Caps total impressions across all visitors. Useful for limited-quantity promotions. |
| No cap | Evergreen content or always-relevant offers | No impression limits. Suitable for persistent content like loyalty tier banners. |
UI navigation: Journey Optimizer > Components > Decision Management
Key configuration details:
- Create placements for each surface where offers will appear (web banner, in-app message area, content card slot)
- Define eligibility rules using segment rule expressions referencing profile attributes and audience membership
- Create personalized offers with content representations for each placement
- Create a fallback offer that covers all placements (displayed when no personalized offer qualifies)
- Organize offers with collection qualifiers (tags) and group into collections
- Create a decision policy binding placements to collections with the selected ranking strategy
Experience League documentation:
Phase 3: Configure surfaces and channels
Application function: AJO: Channel Configuration
What you will configure: Configure the channel surfaces that define where personalized content will be delivered. Each surface type (web, in-app, content card) requires its own configuration specifying the surface URI, content format, and delivery parameters.
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 |
| Web channel only | Personalization focused on web properties | Requires Web SDK. Simplest implementation. Covers hero banners, promotional areas, recommendation widgets. |
| In-app channel only | Personalization focused on mobile app experiences | Requires Mobile SDK. Covers contextual, session-specific messages within the app. |
| Content card channel only | Persistent, dismissible personalized messages | Requires Mobile SDK or Web SDK. Cards persist until dismissed. Ideal for dashboards and home screens. |
| Multiple surfaces (Option C) | Consistent personalization across web and mobile | Requires both Web SDK and Mobile SDK. Each surface needs separate configuration and content. |
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Single-page application (SPA) | Modern web apps with client-side routing | Use renderDecisions: true in Web SDK sendEvent calls. Content rendered automatically by the SDK. |
| Multi-page application (MPA) | Traditional server-rendered web pages | Content delivered on page load via Edge Network response. May require page-level surface URI configuration. |
UI navigation: Journey Optimizer > Administration > Channels > Channel surfaces
Key configuration details:
- For web surfaces: configure the web surface URI matching the target page(s)
- For in-app surfaces: configure the mobile app surface with app ID and surface type
- For content card surfaces: configure the content card surface with app ID or web context
- Ensure the datastream has AJO service enabled for edge personalization delivery
Experience League documentation:
Phase 4: Author content
Application function: AJO: Message Authoring
What you will configure: Author the personalized content variants for each surface and segment or offer. This includes designing the visual layout, adding personalization expressions that reference profile attributes, configuring conditional content blocks, and creating reusable content fragments.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Conditional content blocks | Different content sections within the same layout vary by audience | Single content asset with conditional rules. Efficient for minor variations (headline, CTA text, image swap). |
| Separate content variants per treatment | Fundamentally different layouts or designs per audience | Multiple complete content assets. More flexible but more to maintain. Required for content experimentation. |
| Decisioning-driven content | Content selected dynamically from an offer catalog | Offer representations define the content. Content management is centralized in the offer library. |
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Surface-level personalization | Only specific elements are personalized (hero image, CTA, offer banner) | Lower complexity. Focused personalization on high-impact areas. Most common starting point. |
| Full-page personalization | The entire page layout or content ordering is personalized | Higher complexity. Requires extensive content creation. Delivers the most tailored experience. |
| Token-level personalization | Inline personalization tokens (name, tier, points balance) | Simplest form. Inserts profile attribute values into otherwise static content. |
UI navigation: Journey Optimizer > Campaigns > Create Campaign > Edit content
Where options diverge:
For Option A (segment-based):
- Author content variants for each audience segment using the web designer or code editor
- Use dynamic content blocks with conditions based on audience membership
- Configure personalization expressions referencing profile attributes (e.g.,
{{profile.person.name.firstName}},{{profile.loyalty.tier}}) - Set up conditional rules to display different content based on segment membership
For Option B (decisioning-based):
- Author offer content representations for each placement defined in Phase 2
- Each offer has one or more representations (HTML, image, JSON) matched to placements
- Integrate decisioning output into the web page or app by embedding decision placements
- The content is selected dynamically at runtime – authoring focuses on individual offer items
For Option C (multi-surface):
- Author surface-specific content for each target surface (web HTML/CSS, in-app structured message, content card layout)
- Maintain consistent personalization logic across surfaces while adapting to each surface’s format constraints
- Test content rendering on each surface type
Experience League documentation:
Phase 5: Set up and activate campaigns
Application function: AJO: Campaign Execution
What you will configure: Create and activate the AJO campaign that binds the audience, surface, and content together for delivery. For web personalization, campaigns are typically configured for immediate or ongoing activation rather than one-time scheduled sends.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Scheduled campaign (always-on) | Ongoing personalization that runs continuously for all qualifying visitors | Set start date to immediate and no end date. Campaign remains active until manually stopped. Most common for web personalization. |
| Scheduled campaign (time-bound) | Personalization tied to a specific promotion period | Set start and end dates. Campaign automatically stops after the end date. Suitable for seasonal promotions or limited-time offers. |
| API-triggered campaign | Personalization triggered by a specific application event | Triggered programmatically. Useful when personalization should only appear in response to specific system events. |
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| Apply frequency rules | Promotional or offer-based personalization that could fatigue visitors | Prevents the same personalization from appearing too many times. Configured via AJO business rules. |
| No frequency cap | Evergreen content personalization (loyalty tier banner, dashboard content) | Always-relevant content that does not cause fatigue. No impression limits needed. |
UI navigation: Journey Optimizer > Campaigns > Create Campaign
Key configuration details:
- Select the web, in-app, or content card channel and the surface configured in Phase 3
- Bind the target audience defined in Phase 1
- Link the content authored in Phase 4
- Configure the campaign schedule (immediate, date range, or API-triggered)
- Review and activate the campaign
- For content experimentation: enable the experiment toggle, define treatments, set traffic allocation and success metrics before activation
Experience League documentation:
Phase 6: Track impressions and collect data
Application function: AEP: Data Sources & Collection
What you will configure: Ensure that impressions, interactions, and conversions from personalized experiences are tracked back to the platform for reporting, audience re-evaluation, and decisioning optimization.
Key configuration details:
- Verify Web SDK is sending
decisioning.propositionDisplayevents when personalized content is rendered - Verify Web SDK is sending
decisioning.propositionInteractevents when visitors interact with personalized content (clicks, dismissals) - For Mobile SDK: verify in-app message and content card interaction events are captured
- Configure conversion event tracking for downstream success metrics (purchases, sign-ups, feature adoption)
- Ensure events include the proposition ID for attribution to specific personalization decisions
Experience League documentation:
Phase 7: Report and optimize
Application function: AJO: Reporting & Performance Analysis, Reporting & Analysis
What you will configure: Set up performance monitoring and analysis to measure personalization effectiveness across surfaces, segments, and content variants. Use AJO native reports for operational metrics and Customer Journey Analytics for cross-channel business impact analysis.
Decision points in this phase:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Option | When to choose | Considerations |
| AJO native reports only | Operational monitoring of delivery and engagement metrics | Built-in campaign reports with impression, click, and conversion data. Quickest to set up. |
| CJA cross-channel analysis | Deep analysis of personalization impact on business outcomes | Requires CJA connection and data view. Enables funnel analysis, cohort comparisons, and attribution modeling across channels. |
| Both AJO + CJA | Complete operational and analytical visibility | Use AJO for day-to-day monitoring and CJA for strategic analysis. Recommended for production implementations. |
UI navigation:
- AJO reports: Campaigns > Select campaign > View report
- CJA: Projects > Create new project
Key configuration details:
- Access campaign live reports during active personalization delivery
- Review historical reports for completed campaigns or periodic analysis
- For CJA: configure a connection including AJO experience event datasets and create a data view with personalization metrics
- Build dashboards tracking personalization engagement rate, conversion lift, offer acceptance rate, and revenue per visit
- For decisioning-based personalization (Option B): monitor offer performance by placement and ranking strategy effectiveness
Experience League documentation:
Implementation considerations
This section covers guardrails, common pitfalls, best practices, and trade-off decisions relevant to this use case pattern.
Guardrails and limits
- Edge Network lookups have a response time SLA of less than 200ms for edge-evaluated segments – Real-Time Customer Profile guardrails
- Maximum of 4,000 segment definitions per sandbox – Segmentation guardrails
- Edge segments are limited to simple attribute checks and segment membership queries – no time-series queries – Edge segmentation
- Only one merge policy can be active on Edge per sandbox – Merge policies
- Maximum of 10,000 approved personalized offers per sandbox – Decision Management guardrails
- Maximum of 30 placements per decision – Journey Optimizer guardrails
- AI ranking models require a minimum of 1,000 conversion events for training
- Offer Delivery response time SLA is less than 500ms at P95 for single-scope requests
- Maximum of 500 active live campaigns per sandbox – Journey Optimizer guardrails
- Maximum of 25 active computed attributes per sandbox – Computed attributes guardrails
Common pitfalls
- Edge merge policy not configured: Without an edge-active merge policy, the Edge Network cannot resolve the authenticated profile, causing personalization to fail or fall back to anonymous behavior. Ensure exactly one merge policy has
isActiveOnEdge: truein the sandbox. - Audience not edge-eligible: If audience segment rule expressions use time-series queries, complex aggregations, or
inSegment()references to batch-only segments, they will not qualify for edge evaluation and cannot power real-time personalization. Validate edge eligibility during audience definition. - Identity stitching gap during authentication: When a visitor transitions from anonymous to authenticated, there may be a brief moment where the profile has not yet resolved. Ensure identity stitching is properly configured and that the Web SDK sends the authenticated identity via
identityMapimmediately upon login. - Missing fallback offer in decisioning: If no fallback offer is configured and no personalized offer qualifies for a visitor, the decision returns empty content, creating a broken experience. Always configure a fallback offer that covers all placements.
- Web SDK not sending proposition display events: If
renderDecisionsis set totruebut display events are not being sent, reporting will not reflect actual impressions. Verify event tracking by inspecting network requests in browser developer tools. - Content flicker on page load: If personalized content is not pre-hidden during the decisioning call, visitors may see default content briefly before it is replaced. Use the pre-hiding snippet or CSS-based pre-hiding to eliminate flicker.
Best practices
- Start with segment-based personalization (Option A) for initial implementation, then evolve to decisioning-based (Option B) as the offer catalog grows and optimization needs increase
- Use edge-evaluated audiences whenever possible for real-time personalization; reserve streaming and batch audiences for complementary use cases
- Implement content experimentation on personalized experiences to validate that personalization drives measurable lift over default content
- Design personalization with a graceful degradation strategy – if the profile cannot be resolved at the edge, display well-designed default content rather than a broken experience
- Use computed attributes to create high-value personalization signals like engagement score, product affinity, and days since last purchase, which improve both segment-based and decisioning-based personalization quality
- Maintain a content governance process to ensure personalized content stays current, on-brand, and compliant across all surfaces
- Monitor personalization performance by segment to identify which audiences benefit most from personalization and where the lift is strongest
Trade-off decisions
- Higher granularity favors: Better customer experience, higher engagement, stronger conversion lift
- Lower granularity favors: Faster implementation, lower content maintenance burden, simpler governance
- Recommendation: Start with 3-5 high-impact segments (e.g., loyalty tiers or lifecycle stages) with clear content differentiation. Expand granularity based on measured performance lift. Use decisioning (Option B) to scale granularity without proportional content management growth.
- Decisioning favors: Scalability, automatic optimization, complex eligibility scenarios
- Segment-based favors: Predictability, compliance control, stakeholder transparency
- Recommendation: Use segment-based personalization for compliance-sensitive content (regulatory messaging, tier-specific pricing) where exact control is required. Use decisioning for promotional content, offers, and recommendations where dynamic optimization adds value.
- Edge-only favors: Sub-second latency, simplest architecture
- Pre-computed enrichment favors: Richer personalization signals, more sophisticated audience definitions
- Recommendation: Use computed attributes to pre-aggregate rich behavioral signals into edge-available profile attributes. This provides the richness of behavioral data with the speed of edge evaluation.
Related documentation
The following resources provide additional detail on the technologies and configurations referenced in this guide.