Web Experiment targeting
Web Experiments target both pages and audiences. Amplitude evaluates page targeting first, then audience targeting. Both targeting methods evaluate locally in the browser when the page first loads.
Web Experiments use Pages to control where experiment variants apply on your website. Pages define when a web experiment applies, including targeting conditions that match specific URLs and visual editor URLs for previewing experiments.
Audience targeting
By default, a new Web Experiment targets all users. Audience targeting lets you target specific users for your experiment. Users outside the target audience receive the default experience and don't count towards analysis.
If any segment matches, Amplitude buckets that user into a variant based on the rollout and variant distribution. For a segment to match, the user must meet all conditions you set.
Browser properties (local)
Browser properties are available client-side and don't require network requests, so Amplitude evaluates them with low latency.
| Parameter | Description |
|---|---|
| New Users | A new user that Amplitude first sees after a specified date. When the Web Experiment SDK first sees a user, the SDK stores the date in local storage and never updates the date. This rule may not function as intended shortly after the initial script installation, when all users are new. The New Users rule isn't the same as new user queries in charts and cohorts. |
| Returning Users | A returning user that Amplitude first sees before a certain date. The same local considerations apply as with New Users. |
| Referring URL | Matches users who land on your site from a specific referrer. For more information, refer to document.referrer on MDN. |
| Landing Page URL | The SDK sets the landing page URL in session storage when the SDK loads. |
| URL Query Parameters (Not persisted) | The current query parameters on the page at the time of evaluation. Use this rule for UTM parameter targeting. |
| URL Query Parameters (Persisted) | The query parameters that Amplitude stores locally to maintain variant assignments across navigations or reloads. Use this rule when you need consistent UTM-based targeting beyond the initial page visit. |
| Device Category | Target users by their device type. Desktop, Mobile, or Tablet. |
| User Agent | Target based on the user agent. Useful for targeting bots. For example, exclude all users where user agent contains Googlebot. |
| Cookies | The cookies in the window at the time of evaluation. |
| Language | The language in the user's browser. |
| Browser | The user's browser: Safari, Chrome, Firefox, Edge, Opera. |
| Freeform properties | Custom user properties that the IntegrationPlugin sets. |
Real-time behavioral targeting (local)
Beta feature
Real-time behavioral targeting is in beta. Behavior and APIs may change before general availability.
Real-time behavioral targeting lets you target users based on actions they perform during their current and previous sessions. Amplitude evaluates these conditions in real time as users perform Amplitude events, without network requests.
When users become eligible: the moment a behavioral condition becomes true (for example, after the 5th article view), users become eligible and Amplitude buckets them into the experiment.
How it works: the Web Experiment SDK listens to Amplitude events as they fire in the browser, stores behavioral signals in localStorage, and evaluates targeting conditions in real time.
The SDK persists events for real-time behavioral targeting only when the events appear in your targeting conditions and the experiment is on. There's no historical look-back before you turn on the experiment, so the effective evaluation window is whichever is shorter: the time window you set, or how long the experiment has been running.
If you don't load Analytics and Web Experiment together through the unified script tag, call window.amplitude.add(window.webExperiment.plugin()) so the web experiment client receives tracked event notifications.
Supported conditions
Real-time behavioral targeting supports event-based conditions:
- Event counts: target users who performed an event a specific number of times.
- Time windows: evaluate behavior within the current session or over a specific time period (last X hours or days).
- Property filtering: combine multiple property conditions with AND logic (for example, "where
category = 'electronics'ANDitem_value > 200"). - Cross-page tracking: behavioral signals persist across page navigations and browser sessions.
Example targeting rules
| Use case | Targeting rule |
|---|---|
| Engaged readers | User performed page_view ≥ 5 times this session. |
| Article readers | User performed page_view where page_type = 'article' ≥ 5 times this session. |
| Frequent visitors | User performed page_view ≥ 10 times in last 30 days. |
| Premium electronics shoppers | User performed add_to_cart where category = 'electronics' AND item_value > 200 ≥ 1 time this session. |
Real-time behavioral targeting vs. cohorts
| Feature | Real-time behavioral targeting | Cohort targeting |
|---|---|---|
| Where it runs | Client-side (browser) | Amplitude servers |
| When users become eligible | Instantly, as the event fires | Approx 1 min or 1 hour depending on type of cohort (Syncs, Cohort Targeting). |
| Network request needed | No | Yes |
| Can target mid-session behavior | Yes | No |
| Time window | Shorter. Supports current session, or rolling window of last X hours or days. | Longer. Supports specific intervals and rolling window up to last 12 months. |
| Best for | In-session intent signals (cart adds, page views, engagement depth) | Historical behavior, complex queries, long lookback windows |
Use real-time behavioral targeting when:
- You react to what a user does in this session, not only what they did days or weeks ago. For example, you show a discount after someone views three product pages this session.
- You target behavior that isn't in a cohort yet, including anonymous users who aren't synced to a cohort but show intent during the current session.
- You run experiments tied to high-intent moments: cart abandonment, repeat page views, scroll depth, where the targeting condition and the experiment need to resolve in the same session.
- You need eligibility to update the instant the user crosses the threshold, without waiting on cohort refreshes or remote membership checks.
Use cohorts instead when:
- You target stable attributes or longer historical patterns, such as users who purchased three or more times in the last 90 days or users in a curated churn-risk cohort.
- You target behavior from before the experiment started. Real-time behavioral targeting only persists events after you turn on the experiment.
- You need complex server-side queries across historical data beyond a few weeks.
User properties (remote)
You can perform advanced targeting based on Amplitude ID resolution, IP geolocation, property canonicalization, behavioral cohorts, and historical user properties. Targeting user properties may increase page display latency because Amplitude needs to make network requests.
| Parameter | Description |
|---|---|
| Enriched User Properties | Properties that user enrichment resolves. |
| Amplitude User Properties | Amplitude Analytics' historical user data. |
| Experiment User Properties | The variant that other experiments assigned to the user. |
| User Cohorts | A set of users that you define in Amplitude. |
Page display delay
When active web experiments target a page, Amplitude injects an anti-flicker overlay if at least one experiment targets the page and has "Anti-flicker" on. The overlay is a blank element that covers your page while it loads. Amplitude removes the overlay after it evaluates the remote properties, or after a 1-second timeout.
Bucketing
Bucketing refers to the variant a user sees, based on the rollout and distribution. Rollout is the percentage of users in the experiment. Distribution defines which variant a user experiences if the user is in the rollout. Web Experiment distributes variants evenly by default. Amplitude recommends this distribution.
Bucketing stays consistent when the user has the same ID. Because most experiments bucket by Device ID, Web Experiment may place users in a different bucket if they visit on a new device, browser, or use private browsing.
Increasing rollout doesn't re-bucket users who're already in the rollout. For example, if your experiment has rolled out to 10% of users, and you increase the rollout to 50%, the original 10% of users don't change variants. If you change the distribution from evenly distributed to 20% -> control, 80% -> treatment, users who started in the control jump to the treatment.
Was this helpful?