How It Works

Processing Sequence

When a page loads, the tracking script executes the following sequence:

flowchart TD
    A["Page Load"] --> B["Identify Visitor"]
    B --> C["Generate Default Segments"]
    C --> D["Evaluate Custom Segments"]
    D --> E["Evaluate Location Triggers"]
    E --> F["Evaluate Experiences"]
    F --> G["Apply Variation Changes"]
    G --> H["Show Page"]
    H --> I["Set Up Goal Listeners"]
    I --> J["Fire Integrations"]

    E -->|"Location matched"| F
    E -->|"No match"| H

    F -->|"Audience matched +\ntraffic allocated"| G
    F -->|"Not eligible"| H

    style A fill:#e3f2fd
    style H fill:#e8f5e9

Step by Step

1. Identify Visitor The script reads the _conv_v cookie to identify the visitor. If no cookie exists, a new visitor ID is generated. Session state is updated (page count, session count, returning visitor flag). UTM parameters are extracted from the URL.

2. Generate Default Segments The visitor is automatically categorised by browser, device type, traffic source, campaign, visitor type (new/returning), and country.

3. Evaluate Custom Segments Any custom segments configured in the project are evaluated against the visitor using the rule engine. If a segment requires geographic data that hasn't loaded yet, it is deferred until that data arrives.

4. Evaluate Location Triggers Each location trigger is checked to determine if it matches the current page. There are three trigger types:

5. Evaluate Experiences For each experience connected to an active location:

• Check audience rules (skip if visitor doesn't qualify)
• Check traffic allocation (percentage of qualifying visitors)
• Select a variation (using stored bucketing if the visitor was previously bucketed, or the bucketing algorithm for new visitors)
• Record the bucketing decision

6. Apply Variation Changes The selected variation's changes are applied to the DOM — CSS injection, HTML insertion/replacement, JavaScript execution, or redirects.

7. Show Page The anti-flicker overlay is removed and the page becomes visible. This happens after goals are set up, or after a safety timeout (default 2.5 seconds) — whichever comes first.

8. Set Up Goal Listeners Goal tracking is initialised: DOM listeners for clicks, form submissions, and scroll events are attached. Page visit goals are evaluated immediately. Revenue and code-trigger goals wait for API calls.

9. Fire Integrations Experience data is sent to all connected analytics platforms (Google Analytics, Mixpanel, Hotjar, etc.).

Important: Goals Are Independent

Goals are not directly wired to experiences at processing time. Instead:

• Goals are evaluated independently after experiences are processed
• When a goal triggers, it is attributed to all experiences the visitor is currently bucketed into
• This means a single goal can count as a conversion for multiple experiences simultaneously

flowchart LR
    subgraph "Processing Time"
        EXP["Experiences
(bucketing)"]
        GOALS["Goals
(listeners)"]
    end

    subgraph "Tracking Time"
        ATTR["Attribution
(goal to bucketed experiences)"]
    end

    EXP -.->|"independent paths"| GOALS
    GOALS -->|"goal triggers"| ATTR
    EXP -->|"visitor bucketed"| ATTR

SPA Re-Evaluation

When a URL change is detected in a single-page application (via pushState, replaceState, or popstate), the script re-runs the full sequence from step 1 (except visitor identification is skipped — the visitor is already known). This means:

• Location triggers are re-evaluated against the new URL
• New experiences may activate
• Previously active experiences connected to the old URL's locations are cleaned up
• Goal listeners are refreshed

Deferred Evaluation

Some targeting rules require data that isn't available at page load (geographic location, weather). When this happens:

1. The experience is placed in a deferred queue
2. An additional data request is made to the CDN
3. When data arrives, deferred segments, experiences, and goals are re-evaluated
4. This happens transparently — no action required from you