Skip to content

Full-Stack Optimizely One Implementation

⏱ 90 minutes advanced

Why a platform approach beats point solutions

Section titled “Why a platform approach beats point solutions”

Individual Optimizely products solve specific problems well. CMS manages content. ODP unifies customer data. Experimentation validates changes. But running them as isolated tools means visitors get fragmented experiences — the CMS does not know what ODP knows about the customer, and experiments cannot leverage content-level personalization.

Optimizely One connects these products through shared identity (Opti ID), shared data (ODP profiles), and shared delivery (Graph). The result is a platform where content decisions, personalization, and experimentation share context and compound each other’s value.

This recipe provides the integration sequence — what to connect first, how the data flows, and where the products depend on each other.

┌────────────────────────────────────────────────────┐
│ Opti ID Layer │
│ Unified visitor identity across all touchpoints │
└──────┬──────────┬───────────┬──────────┬───────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌──────────┐ ┌─────────┐ ┌────────┐ ┌────────┐
│ CMS │ │ ODP │ │ Web │ │Feature │
│ SaaS │ │ │ │ Exp. │ │ Exp. │
└────┬─────┘ └────┬────┘ └───┬────┘ └───┬────┘
│ │ │ │
▼ ▼ ▼ ▼
┌────────────────────────────────────────────────────┐
│ Optimizely Graph │
│ Content + personalization + experiment decisions │
│ delivered via GraphQL to any frontend │
└────────────────────────────────────────────────────┘

Start with Opti ID because every other integration depends on consistent visitor identification. Install the Opti ID snippet on all digital properties. This creates a single visitor identity that persists across CMS pages, experiment interactions, and ODP tracking events.

Verify the integration by confirming that a single visitor session generates one Opti ID that appears in ODP event logs, CMS analytics, and experiment assignment logs.

With identity established, configure ODP to ingest behavioral data:

  1. Event tracking — page views, product interactions, form submissions
  2. Profile unification — merge anonymous browsing with authenticated identity
  3. Segment creation — build audiences from behavioral patterns

ODP becomes the central customer data store. CMS and Experimentation both read from ODP segments to make decisions.

Set up CMS SaaS with content types that match your site structure. Configure Graph as the delivery channel. This enables:

  • Headless delivery to any frontend framework
  • Content queries that include personalization context
  • Preview workflows for content authors

Install the Web Experimentation snippet alongside Opti ID. Configure experiments that use ODP segments as audiences. This allows experiments to target specific behavioral groups identified by ODP.

Step 5: Add Feature Experimentation for server-side control

Section titled “Step 5: Add Feature Experimentation for server-side control”

For backend changes — pricing logic, search algorithms, API responses — use Feature Experimentation. Feature flags controlled by ODP segments let you roll out server-side changes to specific customer groups.

OrderProductDepends onEnables
1Opti IDNothingAll other integrations
2ODPOpti IDSegments for CMS and Experimentation
3CMS + GraphOpti IDContent delivery with personalization
4Web ExperimentationOpti ID, ODPClient-side testing with behavioral targeting
5Feature ExperimentationODPServer-side testing with customer segments

This full-stack approach suits organizations committed to Optimizely as their primary DXP. If you are evaluating individual products or have a phased procurement timeline, implement products in the sequence above, stopping at whatever stage meets your current needs. Each step delivers standalone value.