Experiences Overview
An Experience is Intempt's container for testing and personalizing your site or app. Four types, two stored fields.
An Experience is Intempt's container for testing and personalizing your site or app. There are four types, set by two choices.
| Applied by the visual editor | Applied by your code | |
|---|---|---|
| Does this work? | Page experiment | Server experiment |
| Who has this yet? | Personalization | Feature flag |
All four share the same targeting, scheduling, lifecycle and reporting. What differs is how people are chosen and who applies the change.
📘 Good to know
Controlled experiments are the way to establish that a change actually caused a metric to move, not just correlated with it. Run an experiment when you need that proof. Run a rollout - a Personalization, or a Feature flag if your own code reads it - when you already know which audience should see which content and you only want to control how many of them have it yet.
How it works
Creating an Experience
When you create a new Experience the dialog asks how the change will be applied first, then offers the two types available on that answer.
| Applied by | Types offered |
|---|---|
| Visual editor | Page experiment · Personalization |
| SDK | Server experiment · Feature flag |
Who applies the change is not the same as where your code runs, and confusing the two is how a mobile app ends up mislabelled.
Visual editor means Intempt injects the change into the page. You point at a headline in the
editor, and intempt-js swaps it at render time. Only a web page can work this way, because only a
web page has a DOM to point at.
Your code means you ask Intempt what to show, and your own code applies it. Every Intempt SDK
exposes the same variation / allFlags calls against the same endpoint, so a backend, a mobile
app and a browser all read it identically.
A mobile app is "Your code", for exactly the reason a backend is: there is no DOM for the editor to edit. It is not an exception and it is not because a phone is somehow a server. A native screen is drawn by your code, so your code is what applies the variant.
The browser SDK does both: intempt-js applies visual-editor changes and exposes
variation().
The Experiences list
The Experiences list shows every Experience you've created, with a Performance Summary above the table: Total revenue, Intempt attributed revenue (1-day attribution window), and a breakdown of that attributed revenue into Per experience, Total attributed, Personalization, and Experiments.
The table has 5 sortable columns - Name, Status, Type, Duration, and Created by - plus a search box. Status is one of 7 values: Draft, Preparing, Active, Stopped, Paused, Completed, or Ready for review. From any row, you can view details, open the visual editor, or delete the Experience.
Experience details: Setup, Result, Summary
Opening an Experience goes to its details page, with three tabs:
-
Setup. Configure the primary and secondary metrics, targeting (audience, frequency, device, URL conditions), and schedule (activation period, daily schedule).
-
Result. Cumulative exposure charts and the metrics table, with statistical controls for confidence interval, CUPED, sequential testing, and Benjamini-Hochberg correction.
-
Summary. A condensed view of the hypothesis, per-variant exposure, and any metrics you've flagged to share.
Use cases
-
CTA button optimization (Experiment). Test variations in CTA buttons to see which version leads to more completed purchases.
-
Checkout flow optimization (Experiment). Compare a multi-step checkout against a single-page checkout to see which lowers cart abandonment.
-
Landing page optimization (Experiment). Test different value propositions to see which drives more sign-ups or demo requests.
-
Trial length optimization (Experiment). Compare different trial lengths to see which leads to higher conversion.
-
Homepage customization (Personalization). Show different homepage content based on a visitor's past interactions, demographics, or session behavior.
-
Geo-targeted offers (Personalization). Offer personalized promotions based on a visitor's location.
-
Personalized navigation (Personalization). Highlight the categories or pages a visitor has already shown interest in.
-
Behavior-based CTAs (Personalization). Adjust CTAs based on a visitor's lifecycle stage, encouraging the next step in their journey.
Where to go next
-
Web Experiments to create your first visual-editor experiment.
-
Personalization Overview to create your first visual-editor personalization.
-
Using the visual editor to build variants without code.
-
Mobile Experiments for testing in a mobile app.
-
Experiment Analytics to read your results.
The off value applies to experiments too
A paused or stopped experiment drops out of the evaluation response, so a server-channel caller receives nothing at all. The off value is what it receives instead — set it on the setup tab. It is described in full in the feature flag guide, but it is not flag-only.
Rollout behaves differently here, and deliberately. A personalization or a flag re-derives on every call, so widening reaches people already evaluated. A running experiment keeps each participant's assignment until it ends: re-bucketing mid-flight destroys the reading.
Experiment analytics
The Result tab shows how each variant is performing against your hypothesis, with exposure charts, a metrics table, and a drill-in view for the full statistical breakdown.
Mobile experiments
A mobile experiment is an A/B test your own app code applies. Intempt decides which variant a person gets and returns it as a payload; your app reads that payload and renders accordingly.