Anonymous visitor web personalization

This reference plan provides implementation guidance for delivering personalized web content to anonymous (unidentified) visitors based on in-session behavioral signals. It covers the complete implementation lifecycle – from Web SDK configuration and edge audience definition through content delivery and performance reporting – and is designed for solution architects, marketing technologists, and implementation engineers working with Adobe Journey Optimizer (AJO), Adobe Real-Time Customer Data Platform (RT-CDP), and Adobe Experience Platform (AEP).

Use this plan to understand the architecture, evaluate implementation options, make informed configuration decisions, and locate the relevant Experience League documentation for each phase of implementation.

The pattern operates with limited data – only what can be observed in the current session and any anonymous edge profile accumulated from prior visits with the same device or cookie. This makes it suitable for top-of-funnel personalization where the visitor has no account or has not authenticated.

Use case overview

Anonymous Visitor Web Personalization addresses the business need to deliver relevant, personalized content to website visitors who have not yet been identified – they have not logged in, have no known identity, and cannot be resolved to a unified customer profile. Despite this limitation, meaningful personalization is achievable using in-session behavioral signals: pages viewed, time on site, scroll depth, referral source, geographic location, device type, and UTM campaign parameters.

This pattern uses AJO’s web channel surfaces and code-based experiences to modify page content in real time. Edge segmentation is the primary evaluation method since decisions must be made with sub-second latency as the visitor navigates the site. The Web SDK collects behavioral signals and sends them to the AEP Edge Network, where edge-evaluated audience rules determine which content variant to deliver.

Unlike known-visitor web/app personalization, which leverages the full unified profile and segment membership, this pattern is constrained to data observable in the current session and any anonymous edge profile associated with the visitor’s ECID (Experience Cloud ID). This distinction is critical for implementation planning: the behavioral signals available for personalization are limited to what the Web SDK captures and what persists in the edge profile store across sessions via the cookie-based ECID.

Key business objectives

The following business objectives are supported by this use case pattern.

Increase website engagement

Improve time on site, pages per session, and interaction with web content through relevant experiences tailored to anonymous visitor signals.

Deliver personalized customer experiences

Tailor content, offers, and messaging to individual preferences, behaviors, and lifecycle stage – even for visitors who have not yet identified themselves.

Increase conversion rates

Improve the percentage of visitors and prospects who complete desired actions such as purchases, sign-ups, or form submissions by presenting the most relevant content based on behavioral context.

Example tactical use cases

The following examples illustrate specific scenarios where this pattern can be applied.

Key performance indicators

Use the following KPIs to measure the effectiveness of this use case pattern.

Use case pattern

The following describes the core pattern and function chain for this use case.

Anonymous Visitor Web Personalization

Deliver personalized content based on in-session behavioral signals for unidentified visitors via AJO web channel.

Function chain: Web Surface Configuration > Behavioral Rule Evaluation > Content Delivery > Impression Tracking > Reporting

Applications

The following applications are used in this use case pattern.

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.

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 implementation.

Implementation options

This section describes three implementation approaches. Select the option that best fits your personalization requirements.

Option A: Rule-based web personalization

Best for: Simple, deterministic personalization – geo-targeted banners, referral-source-specific headlines, device-specific layouts, new vs. returning visitor messaging. Choose this option when the content variant can be determined by straightforward conditional logic (if condition X, show content Y).

How it works:

Rule-based personalization uses edge-evaluated audience segments to determine which content variant a visitor sees. Each audience segment maps to a specific content variant through conditional rules defined in the campaign. When a visitor loads a page, the Web SDK sends behavioral signals to the Edge Network, which evaluates the visitor’s edge profile against the defined audience rules in milliseconds. The matching content variant is returned in the Edge Network response and rendered on the page.

This approach requires defining distinct audience segments in RT-CDP (e.g., “visitors from Google search,” “visitors in California,” “mobile device visitors”) and creating corresponding content variants in AJO. The campaign binds each audience to its content variant using conditional content rules or separate campaigns per segment. No AI ranking or traffic splitting is involved – the relationship between audience and content is deterministic.

Key considerations:

Advantages:

Limitations:

Experience League:

Option B: Experimentation-based web personalization

Best for: A/B and multivariate testing – testing headline variants, CTA button colors, layout alternatives, promotional offers – with statistical significance measurement. Choose this option when you need to validate which content variant performs best before committing to a permanent personalization rule.

How it works:

Experimentation-based personalization uses AJO Content Experimentation to randomly allocate visitors to content treatment groups and measure which variant performs best against a defined success metric. Traffic is split across variants (e.g., 50/50 for A/B, 33/33/34 for A/B/C) and performance is tracked until statistical significance is reached.

The experiment is embedded in an AJO web campaign. When a visitor loads a page, the Edge Network assigns them to a treatment group based on the configured traffic allocation. The visitor consistently sees the same treatment for the duration of the experiment (session-level or visitor-level persistence depending on configuration). Success metrics (clicks, conversions, engagement events) are tracked via Web SDK and reported in the AJO experiment report.

This option does not require pre-defined audience segments for targeting – all visitors (or a targeted subset) participate in the experiment. The goal is to discover which content performs best, not to target known segments with predetermined content.

Key considerations:

Advantages:

Limitations:

Experience League:

Option C: Decisioning-based web personalization

Best for: Dynamic content selection – category affinity recommendations, exit-intent offers, behavioral recommendations – where a decision policy evaluates session signals and selects the optimal content from a catalog of eligible items. Choose this option when the content selection logic is too complex for simple rules, when you want AI-ranked optimization, or when the set of eligible content items is large and dynamic.

How it works:

Decisioning-based personalization uses AJO Decisioning to evaluate behavioral signals and select the best content variant for each visitor from a managed catalog of content items (offers). Each content item has eligibility rules (who qualifies), representations (what the content looks like in each placement), and optional capping constraints (how often it can be shown). A decision policy links placements (where content appears on the page) to collections of content items and applies a ranking strategy to select the best option.

When a visitor loads a page, the Web SDK sends an Edge Network request that includes the decision scope. The Decisioning engine evaluates the visitor’s edge profile against content item eligibility rules, applies the ranking strategy (priority-based, formula-based, or AI-ranked), and returns the winning content item. This happens at the edge with sub-second latency.

The ranking strategy determines how eligible content items are ordered. Priority-based ranking uses manually assigned priority values. Formula-based ranking uses a custom expression (e.g., weighting recency of page views). AI-ranked ranking uses a machine learning model that optimizes for the selected success metric over time, but requires a minimum of 1,000 conversion events for training.

Key considerations:

Advantages:

Limitations:

Experience League:

Option comparison

The following table compares the three implementation options across key criteria.

Choose the right option

Use the following decision logic to select the appropriate implementation option:

Combining options: These options are not mutually exclusive. A common progression is to start with Option B (Experimentation) to discover winning content, then deploy winners using Option A (Rule-Based) for ongoing delivery. Option C (Decisioning) can be layered on top for use cases that require dynamic catalog-based selection, while Option A handles simpler deterministic rules.

Implementation phases

The following phases describe the end-to-end implementation workflow.

Phase 1: Configure web surfaces

Application function: AJO: Channel Configuration

Define the web channel surfaces that specify where on your website personalized content will be delivered. A web surface identifies a specific page URL or URL pattern and the location on the page (CSS selector or code-based experience surface) where AJO can inject or replace content.

Decision points in this phase:

UI navigation: Journey Optimizer > Administration > Channels > Web configuration

Key configuration details:

Experience League documentation:

Phase 2: Define behavioral audiences

Application function: RT-CDP: Audience Evaluation

Define edge-evaluated audience segments based on in-session behavioral signals that drive personalization targeting. These audiences determine which visitors qualify for each personalized experience. Edge evaluation is mandatory for this pattern since personalization decisions must be made in sub-second timeframes as the visitor navigates the site.

Decision points in this phase:

UI navigation: Customer > Audiences > Create audience > Build rule

Key configuration details:

Where options diverge:

For Option A (Rule-Based):
Create distinct audience segments for each content variant. Each segment represents a specific behavioral condition (e.g., “Referral = Google AND Geo = US” maps to content variant A). The number of audiences equals the number of personalization rules.

For Option B (Experimentation):
Audience definition is optional. If the experiment targets all visitors, no audience is required – traffic splitting handles variant assignment. If the experiment targets a specific subset (e.g., only mobile visitors), define a single targeting audience for experiment eligibility.

For Option C (Decisioning):
Define audiences for use as eligibility rules on content items. These audiences determine which visitors qualify for which content items in the decision policy. The decisioning engine handles content selection from among eligible items.

Experience League documentation:

Phase 3: Author content and create variants

Application function: AJO: Message Authoring, AJO: Content Experimentation (Option B), AJO: Decisioning (Option C)

Create the personalized content variants that will be delivered to visitors based on audience membership (Option A), experiment assignment (Option B), or decisioning logic (Option C). This phase covers content creation using the AJO web designer or code-based experience editor, as well as the experiment or decisioning configuration that governs how content is selected.

Decision points in this phase:

UI navigation: Journey Optimizer > Campaigns > Select campaign > Edit content

Key configuration details:

Where options diverge:

For Option A (Rule-Based):
Author a distinct content variant for each audience segment defined in Phase 2. Bind each variant to its target audience using conditional content rules in the campaign configuration. Ensure a default content variant exists for visitors who do not match any audience rule.

For Option B (Experimentation):
Author treatment variants (A, B, C, etc.) for the experiment. Enable content experimentation on the campaign, define treatment variants with their content, set traffic allocation percentages, and configure the success metric.

For Option C (Decisioning):
Set up the Decisioning component stack and integrate it into the campaign.

Experience League documentation:

Phase 4: Configure campaign and delivery

Application function: AJO: Campaign Execution

Create and activate the AJO web campaign that binds the web surface (Phase 1), the audience targeting or experiment configuration (Phases 2-3), and the content variants (Phase 3) into a deliverable unit. The campaign controls when and how personalized content is served to visitors.

Decision points in this phase:

UI navigation: Journey Optimizer > Campaigns > Create Campaign

Key configuration details:

Where options diverge:

For Option A (Rule-Based):
Create one campaign per personalization rule, each targeting a different edge audience with its corresponding content variant. Alternatively, use a single campaign with conditional content rules that map audience membership to content variants within one campaign.

For Option B (Experimentation):
Create a single campaign with content experimentation enabled. The experiment configuration (variants, traffic allocation, success metric) was defined in Phase 3. Activate the campaign to start the experiment.

For Option C (Decisioning):
Create a campaign that embeds the decision policy configured in Phase 3. The campaign’s content action references the decision scope, which triggers the Decisioning engine at the edge. Activate the campaign to begin decisioning-based content delivery.

Experience League documentation:

Phase 5: Report and analyze performance

Application function: AJO: Reporting & Performance Analysis

Monitor personalization performance using AJO built-in reports and optionally extend analysis with CJA for deeper cross-channel insights. This phase covers accessing live and historical campaign reports, reviewing experiment results, and building custom analysis workspaces.

Decision points in this phase:

UI navigation: Journey Optimizer > Campaigns > Select campaign > View report

Key configuration details:

Where options diverge:

For Option A (Rule-Based):
Review campaign reports for each audience segment to compare delivery and engagement metrics across personalized content variants. Use CJA to build a comparison workspace that measures the conversion impact of personalized vs. default content.

For Option B (Experimentation):
Review the experiment report for statistical confidence, treatment lift, and winner identification. Wait for the confidence threshold to be reached before declaring a winner. Apply winning content as the permanent variant (transitioning to Option A for ongoing delivery).

For Option C (Decisioning):
Review decisioning performance metrics including offer impression rates, selection frequency, and conversion attribution per content item. Analyze how ranking strategies are performing and whether fallback content is being served too frequently (indicating eligibility rules are too restrictive).

Experience League documentation:

Implementation considerations

This section covers guardrails, common pitfalls, best practices, and trade-off decisions for this use case pattern.

Guardrails and limits

Review the following guardrails before and during implementation.

Common pitfalls

Avoid the following common implementation mistakes.

Best practices

Follow these recommendations for a successful implementation.

Trade-off decisions

Consider the following trade-offs when planning your implementation.

Related documentation

The following Experience League resources provide additional detail on the capabilities used in this use case pattern.

Web channel and code-based experiences

Audiences and segmentation

Personalization and content

Content experimentation

Decision Management

Campaigns

Web SDK and data collection

Identity and profile

Data modeling

Reporting and analytics

Data governance and privacy

Guardrails