Developer Demo
Personalization & Audiences
Optimizely has several products that all touch personalization - FX, ODP, Web Experimentation, and the CMS each have their own audience system and their own way of showing different content to different visitors. That overlap is real and intentional, but it can make it hard to know which to reach for, or whether to combine them.
The clearest way to think about it is in layers, not alternatives: ODP is the data layer (who is this visitor, based on their history); FX is the decision layer (which variant should they see, and can we measure lift); Optimizely Graph is always the delivery layer (it serves the right CMS variant once it has a variation key). The four paths below are different ways of stacking those layers - from the full Optimizely stack down to bringing your own logic entirely.
Four Paths to Personalized Content #
- Feature Experimentation (FX) - delivery engine: configures audiences, buckets traffic, runs A/B experiments, and produces statistical results. Managed in your source code, so the decision can run at the edge / server-side or client-side via an SDK.
- ODP (Optimizely Data Platform) - audience layer only: builds behavioral profiles from cross-session events. No delivery role - plugs into FX as an audience source, or drives Graph directly.
- Optimizely Graph - content delivery API: always the final step, regardless of which path resolves the variation key. Serves the right CMS variant based on the key it receives.
- Web Experimentation / Personalization - a separate, standalone Optimizely product with its own visual editor and its own client-side delivery: it buckets visitors and applies changes in the browser, independent of the CMS and Graph. It can be bridged to CMS content as a last resort, but the server-side paths above are simpler and have no lag.
- FX and ODP can be combined - ODP segments used as FX audience conditions. Path 3 is the escape hatch for bringing your own audience logic entirely.
Path 1 - Feature Experimentation (server-side, CMS-integrated)
Audience signal
device, persona, geo, auth
FX engine
delivery, experiments, results
Graph filter
getContentByPath()
CMS variant
or original fallback
FX is the delivery engine: it evaluates audience rules in-process, buckets traffic, and returns a variation key that Graph uses to serve the right CMS variant. The FX results page tracks decision events and conversions per variation and runs a statistical significance test - you can declare a winner with a measured confidence interval. FX audience conditions can be fed from native request-time attributes or ODP segments (the combination) - see FX Audience Sources below. Use this path when you need experiments, hold-out groups, or measurable lift.
Path 2 - ODP direct (server-side, no Feature Experimentation)
ODP segments API
one query per request
Segment map
segment name → variationKey
Graph filter
getContentByPath()
CMS variant
or original fallback
ODP is an audience layer only - it has no delivery role. Query it for the visitor's behavioral segments, map a segment name to a variation key, and pass it straight to Graph. CMS/Graph still does the content delivery, just as in Path 1 - only the decision layer differs. ODP reporting covers audience analytics (segment reach, engagement trends) - not a controlled statistical test. Use this path for pure personalization for known behavioral segments with no experiment to run.
Path 3 - Custom audience layer (server-side, direct to Graph)
Custom logic
cookie, DB, API, 3rd-party service
Variation key
resolved by your code
Graph filter
getContentByPath()
CMS variant
or original fallback
Graph's variation filter accepts any string as the variation key - it does not care where it came from. Plug in whatever audience system you already have: read a cookie your own system wrote, call an internal API, query a database, or derive the key from request headers. Resolve the key in your Server Component and pass it to getContentByPath(url, { variation: { include: "SOME", value: [key], includeOriginal: true } }). The rest of the delivery pipeline - Graph filter, CMS variant, original fallback - works identically to Paths 1 and 2.
Path 4 - Web Experimentation / Personalization (separate, standalone product)
Unlike Paths 1-3, this is not a server-side route to CMS content - it is a separate, standalone Optimizely product with its own visual editor and its own client-side delivery. It buckets visitors and applies changes in the browser, independent of the CMS and Graph, and tracks its own results. It can be bridged to serve CMS content - the bridge below reads WX's decision before first paint and routes the render to the matching CMS variation - but the server-side paths above are still simpler, because they decide before the HTML is sent and so cannot flicker. See the bridge below.
IsMatch(). Content blocks show or hide at the component level based on audience membership. No separate SDK - purely rules-based, built into the CMS, no A/B testing or statistical results. In the SaaS CMS (this demo), Visitor Groups / Audiences do not exist - the CMS is headless with no built-in rendering layer. Personalization is externalized: FX audience rules take the place of criteria for request-time facts (device, country, login state); ODP segments take the place of behavioral criteria (page view history, high-value, churn risk). FX also adds what Visitor Groups never had: experiments, traffic splits, and statistical results.Path 1 · server-side
Feature Experimentation
The middleware mechanism end to end: decide at the edge, carry the variation in the path, filter in Graph. Also how ODP segments become FX audiences, and how to personalize with a rollout instead of an experiment.
Path 4 · client-side
Web Experimentation
Two implemented ways to turn a browser-side WX decision into CMS content, the tradeoff between them, and pushing ODP segments in as WX audience attributes.
Path 2 · data layer
ODP
Profiles, identity stitching and segments, driving Graph directly with no experiment in the loop. The live Settings panel lives here too.
Personalization or Experimentation? #
Every path above can do either, and the difference is not the mechanism - it is whether you are measuring. An experiment splits a single audience and compares outcomes. Personalization targets a known audience and serves them different content on purpose, with nothing to prove. The delivery is identical; only the configuration and the reporting differ.
With FX
A rollout with an audience condition and no second variation. Same middleware, same Graph filter, no traffic split and no statistics.
With Web Experimentation
A Personalization campaign rather than an A/B test. It buckets and applies changes through exactly the same client-side delivery.
With ODP directly
Segment membership maps straight to a variation key. This one is personalization by construction - there is no experiment engine involved at all.