Content Personalization

Content personalization is about delivering the right message to the right visitor, every time they qualify, without running a statistical test.

With personalization rules, you define which content or destination qualifying visitors should see, and that treatment is shown every time they match. There's no traffic split, no statistical test, and no winner to declare. The rule runs until you stop it.

How it's delivered: Personalization runs on the same runtime, consent gating, and SDK as A/B tests. To put it into practice, use Headless Personalization: read visitor signals from window.ours_experiments.getVisitorContext() and render targeted content in your own application code.

Personalization vs. A/B Testing

For matching visitors, personalization ignores traffic allocation. The runtime applies the personalized variant directly instead of hashing visitors into buckets for a statistical test.

Use A/B testing when you have a hypothesis and want data to decide. Use personalization when you've already decided: you just need to deliver it.

What Personalization Is Good For

Industry-specific messaging. Healthcare companies get a hero tailored to HIPAA and care networks. Enterprise visitors get an enterprise pricing pitch. Everyone else sees your default.

Returning visitor recognition. First-time visitors see your acquisition pitch. Visitors who've already explored your product see a message that reflects where they are in the journey.

Campaign landing pages. Visitors arriving from a specific ad campaign or UTM source see copy that matches the ad they clicked. Everyone else sees the default page.

Geographic or regional content. Show region-appropriate messaging, pricing context, or compliance language based on where the visitor is located.

Behavior-driven content. Use a personalization property rule to turn an event into a visitor property, then target on that property. For example, a page_view on /pricing can become visited_pricing: true.

Targeted redirects. Send matching visitors to a dedicated destination page instead of rewriting the current page in-place.

How It Uses Your Existing CDP Data

Personalization is built into the CDP, so the data you're already collecting can become targeting criteria.

Visitor context is directly available at runtime: UTM parameters, geographic data, device type, referral source, query parameters, and new-versus-returning status.

Accumulated visitor properties turn tracked behavior into durable, targetable state. The runtime evaluates named properties, not saved Audience Builder membership.

Events you're already tracking provide behavioral targeting through property rules. Show a message to visitors who have previously viewed your pricing page, completed an onboarding step, or triggered another tracked event after its rule has accumulated the corresponding property.

Accumulated Visitor Properties

A personalization property rule watches your event stream and records a value on the visitor. "Saw the pricing page" becomes visited_pricing: true; "arrived from the spring campaign" becomes last_campaign: 'spring-2026'. The value sticks to the visitor across sessions, so a rule that fired weeks ago is still available the next time they land on your site.

Every accumulated value is a single scalar: a string, a number, or a boolean. Property rules never store nested objects or raw event payloads.

Read the accumulated values in your own code with window.ours_experiments.getVisitorContext():

const ctx = window.ours_experiments.getVisitorContext();

if (ctx?.properties?.visited_pricing === true) {
  showPricingFollowUp();
}

You can also target a personalization rule on an accumulated property directly, by naming the property key in the rule's visitor targeting.

Two timing rules matter:

• A newly accumulated value reaches the browser on the visitor's next full page load, not during the page view that triggered it. A rule that must react in the same page view should read the event you are already sending instead.
• Until the visitor has matched any property rule, they have no accumulated values at all. Write your checks so the default experience renders when a property is absent.

See Headless Personalization for the full read API.

Data Safety

Personalization rule values, including every accumulated property, are delivered to the browser and can be queried with a visitor ID. Use only values that are safe for browser delivery. Do not use secrets, credentials, protected health information, or other confidential data in personalization rules.

How to Implement Personalization

Use the REST API or an MCP-connected AI assistant to create a personalization experience. The workflow is:

1. Create a personalization property when the target is behavior-derived, such as visited_pricing.
2. Create an experiment with type: "personalization" and target it on visitor context or that property.
3. Add one treatment with DOM modifications or a redirect, then start it. The API supplies the control row and personalization does not require a metric.
4. Render or inspect the result: the runtime applies DOM/redirect treatments, or your code can read visitor context and assignments through the SDK.

See Manage Experiments with AI for prompt examples, or the Experiments API and Experiment Variants API for the raw endpoints.

See Headless Personalization for the full implementation guide.

Matching visitors see the personalized content immediately. Everyone else sees the original page.

What Makes Personalization Different Operationally

• No conversion metric is required. You can launch personalization without defining a primary metric because there is no winner calculation.
• No traffic split is required. Matching visitors always receive the personalized treatment.
• Assignments are still visible in the JavaScript SDK. The browser runtime persists the active personalization assignment in its first-party experiment cookie, so window.ours_experiments.getExperiment(...) and getAssignments() can report what the visitor saw.
• Treatments can be DOM changes or redirects. Personalization uses the same treatment building blocks as experiments; the difference is assignment semantics, not a separate rendering engine.

Multiple Rules on the Same Page

You can run multiple personalization rules on the same page at the same time. When a visitor matches more than one rule, all matching rules are applied.

Avoid overlapping rules that mutate the same selector or page region. If two matching rules both change the same element, the later-applied change wins at runtime.

Consent

Personalization rules respect the same consent settings as A/B tests. Visitors who have not consented to analytics do not see personalization rules. This is handled automatically by the platform: you don't need to add any consent checks to your rules.

Next Steps

• Headless Personalization: Code-driven personalization with visitor signals
• Content Experiments: Run a statistical experiment when you want data to make the decision
• Redirect Experiments: Test two completely different pages against each other
• JavaScript SDK: Access personalization assignments from your own code