--- title: How Optimizely Experimentation counts conversions slug: experimentation-strategy/docs/how-optimizely-experimentation-counts-conversions docTags: createdAt: 2026-08-05T20:33:23.916Z --- - Optimizely Web Experimentation - Optimizely Personalization - Optimizely Performance Edge - Optimizely Feature Experimentation - Optimizely Full Stack (Legacy) When sending a decision event to Optimizely Experimentation, how Optimizely assigns conversion events depends on the product. **Web Experimentation, Optimizely Performance Edge, Feature Experimentation, and Full Stack (Legacy)** - Uses user-level scoping for visitor count and event-level scoping for events. - Conversion events are attributed to the first variation the user encounters, depending on the date range. **Optimizely Personalization** - Uses session-level scoping for both visitors and events. - Conversion events are attributed to the last decision made in the session. - This approach is ideal for behaviorally targeted campaigns with dynamic, evolving experiences. When segmenting on the [Optimizely Experiment Results page](docId\:mrUblIuNVOZc1dvjWdsbw): - The visitor count shows all visitors who had the attribute in their decision or had a conversion event with that attribute value. - The conversions and events will only show events that have the attribute added to the event. :::hint{type="warning"} **Warning** For information about how event counting works, see [Attributes and segmentation](docId:_sy-mNT1TCvYW-EA2m_Ls). ::: ## Example While you are experimenting on your site's product detail pages, a user visits one of those pages, enters the experiment, is bucketed into a certain variation, and converts on an event you track: *Click Add to Cart*. The user converts a few times while navigating your site. Unless otherwise noted, assume that the user is shown the same variation in Sessions 1 and 3. - **E = Conversion events** (also known as [events](docId\:puGm9z4XkEG5PDkyaNmlA)) are triggered when a visitor *converts* to a desirable action, such as a click, page view, or purchase. - Conversion events in [Optimizely Feature Experimentation](docId:3kGIZlCkODJIOJuT3bdWo). - Conversion events in [Optimizely Web Experimentation](docId\:puGm9z4XkEG5PDkyaNmlA). - Conversion events in [Optimizely Personalization](docId\:puGm9z4XkEG5PDkyaNmlA). - **D = Decision events** are triggered when a new variation is served to a visitor. - Decision events in [Optimizely Feature Experimentation](docId\:SzVcfUMHk3IKycnEjgjbq). - Decision events in [Optimizely Web Experimentation](docId:7AHMiX4UcWP1iNUY6X17X). - **Session** – A period of activity for a user. Optimizely Experimentation does not use sessions to assign data to decisions. Instead, sessions are used for illustrative purposes only. For example, Session 1 could be considered the user's activity on one day. Session 2 is the next day, and so on. ![Timeline of one user's activity across four sessions. Each session contains conversion events (E), and decision events (D) occur in Session 1 and Session 3.](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/wkHx94jjDoZGB8DI9rInf-20260720-144805.png) ## User-level scope - Optimizely Web Experimentation - Optimizely Performance Edge - Optimizely Feature Experimentation - Optimizely Full Stack (Legacy) When a user is shown a variation, subsequent conversion events from that user are assigned to that variation for as long as the experiment is running. When a user encounters multiple variations for the same experiment, subsequent conversions are assigned to the first variation encountered within the date range of the results query, meaning a user's conversions can be assigned to different variations, depending on the date range of your results query. For example, a user encountered Variation A at Time 1, then encountered Variation B at Time 2, and finally converted at Time 3. The conversion is assigned to Variation A if your results query spans from Time 1 to Time 3. If your results query spans from Time 2 to Time 3, the conversion is assigned to Variation B. The following timeline shows how a single user's conversion events (E) are counted when results are scoped to the user. ![User-level scoped assignment timeline across four sessions. The two events before the first decision in Session 1 are not assigned. All 16 events after that decision, through Session 4, are assigned to the variation.](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/sEz_LI8IvDsFIG8tdkqDH-20260720-144805.png) Optimizely Web Experimentation counts 16 total conversion events (E) and assigns them to one user. This is a user-scoped event assignment. When the user is shown a variation, subsequent conversion events from that user are assigned to that variation. - **Users** – 1 - **Total conversion events scoped to the user** – 16 - **Unique converting users** – 1 ## Session-level scope - Optimizely Personalization Session-level scoping in Optimizely Personalization assigns conversion events to the decision within that session while retaining the event scope for events when segmenting, making it suitable for behaviorally targeting with changing personalized experiences over time. ![Session-level scoped assignment timeline for Personalization. The user qualifies for experience 1 in Session 1, and the three events after that decision are assigned to it. The user qualifies for experience 2 in Session 3, and the two events after that decision are assigned to it. Events in Sessions 2 and 4, and events before each decision, are not assigned.](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/YcfBJXarjCpjpcfKtxs39-20260720-144805.png) When the user is shown a variation, subsequent conversion events (E) that are triggered are assigned to that variation. - **experience\_1 events** – 3 - **experience\_1 unique converting events** – 1 - **experience\_2 events** – 2 - **experience\_2 unique converting events** – 1 ## Decision-level scope - Optimizely Web Experimentation - Optimizely Personalization Decision-level scope assigns each conversion event to the most recent unique decision made before that event occurred. [Contextual bandits](../../../personalization/get-started-with-personalization/contextual-bandits.mdx) use this scope because visitors can be reassigned to a different variation while it is running. When a visitor triggers a conversion event, Optimizely attributes that event to the variation from the "previous unique decision", even if the visitor had previously seen a different variation. This ensures that each event reflects the variation the visitor experienced at the time of the action. For example, User123 is exposed to Variation\_2 and triggers the following four different conversion events: 1. Add\_to\_bag 2. Product\_viewed 3. Bag\_viewed 4. Removed\_item Then, User123 is exposed to Variation\_1 and triggers the following two conversion events: 1. Checkout\_1 2. Revenue ![Decision-level scoped assignment timeline for contextual bandits. A decision for Variation 2 in Session 1 is followed by the Add to bag, Product viewed, Bag viewed, and Removed item events, which are all assigned to Variation 2. A decision for Variation 1 in Session 3 is followed by the Checkout 1 and Revenue events, which are assigned to Variation 1.](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/93m41nxmWPasGvY2cwvB_-20260720-144805.png) The [Contextual Bandit Results page](../../../personalization/measure-and-analyze-results/contextual-bandit-results-page.mdx) in the previous example shows the following: **Variation\_2** - **Decisions** – 1 - **Events** – 4 (Add\_to\_bag, Product\_viewed, Bag\_viewed, and Removed\_item) **Variation\_1** - **Decisions** – 1 - **Events** – 2 (Checkout\_1 and Revenue) If User123 is later reassigned to Variation\_1, Optimizely does not increment the decision count because User123 already received a decision for that variation. However, additional conversion events are still counted and attributed to Variation\_1. ### Key benefits of decision-level scope - **Accurate attribution** – Events are precisely tied to the context (variation) in which they occurred, even when user context changes mid-campaign. - **No inflated counts** – Users who see the same variation multiple times do not increase decision counts, helping avoid misleading aggregation. - **Consistent reporting** – This approach mirrors event-scoped segmentation, where event attribution depends on when the event occurred relative to the decision. See [Decision count for contextual bandits in the Attributes and segmentation documentation](docId:_sy-mNT1TCvYW-EA2m_Ls).