Event Tracking

A vs B tracks two types of events: exposures (when a visitor is assigned to a variation) and conversions (when a visitor completes a metric event like clicking a button or viewing a page). Understanding how these are collected and sent helps you debug data discrepancies and plan custom tracking.

Exposure events

An exposure is recorded the moment a visitor is assigned to a variation and that variation is activated. Exposures are the denominator in your experiment results — they tell A vs B how many visitors were in each variation group.

Important properties of exposure tracking:

• Once per visitor per experiment — A vs B does not record duplicate exposures for the same visitor. If a visitor visits the same page ten times, they generate one exposure for that experiment.
• Queued immediately on activation — The exposure event is queued as soon as the variation is activated, even before any conversion events.
• Sent in the next batch— The event is sent to A vs B's servers in the next batch send (every 2 seconds or on page hide).

Conversion events

A conversion event fires when a visitor completes an action that one of your metrics is measuring. A vs B sets up event listeners automatically based on your metric configuration:

• Click metrics — A vs B attaches a click event listener to all elements matching your CSS selector. When a matching element is clicked, the event is queued.
• Pageview metrics — A vs B fires a conversion when the visitor loads the target URL. On SPAs, this fires on every navigation to the target URL.
• Custom events — You fire these manually by calling avsb.track.event(shortId) from your own code, where shortIdis the metric's numeric ID.
• Revenue events — You fire these manually by calling avsb.track.event(shortId, { revenue: 49.99 }).

Conversion deduplication

By default, conversions are de-duplicated per visitor. A visitor can only convert once per metric per experiment session. If the same visitor clicks the button ten times in one session, it counts as one conversion. This prevents click-happy visitors from artificially inflating your conversion rates.

Some metric types (like revenue) can be configured to allow multiple conversions per visitor (for example, counting every purchase, not just the first one). Check the individual metric settings for this option.

Event batching

Instead of sending each event as a separate HTTP request (which would be slow and create a lot of network overhead), A vs B collects events in an in-memory queue and sends them in batches:

• Every 2 seconds — A periodic interval flushes all queued events to the server.
• On page hide— When the visitor navigates away, closes the tab, or puts the browser in the background, A vs B immediately flushes all queued events using the browser's sendBeacon API. This ensures events are not lost when a visitor leaves.

Manual event tracking

You can fire custom events from anywhere in your code using avsb.track.event(). Pass the metric's numeric short ID (found in the metric settings) and an optional properties object for revenue. This is useful for tracking actions that are difficult to capture with a CSS selector (for example, a form submission, a video play, or a custom interaction).

1// Track a custom event (12345 is the metric's short ID)
2avsb.track.event(12345);
3
4// Track a revenue event with a value
5avsb.track.event(67890, { revenue: 79.99 });
6
7// Track from within variation JS
8const submitButton = document.querySelector('#checkout-form button[type="submit"]');
9if (submitButton) {
10  submitButton.addEventListener('click', () => {
11    avsb.track.event(12345);
12  });
13}

Where the data goes

Events are sent to A vs B's data ingestion endpoint (ingest.avsb.cloud). From there, they flow into the analytics pipeline and are processed to compute experiment results. Results are typically visible in the dashboard within a few minutes of events being sent.

Error capture

Alongside exposures and conversions, the snippet reports errors and warnings produced by your running variations so a broken variation can be caught before it costs you conversions:

• Uncaught variation errors— exceptions thrown by a variation's custom JavaScript, including asynchronous ones, attributed to the exact experiment and variation that produced them.
• Visual-change failures— when a visual edit's target element can't be found on the page (a warning), or an edit throws while being applied (an error).
• Project JavaScript errors — exceptions thrown by your Project JS.

Reports are de-duplicated per page load and batched to the ingestion endpoint the same way events are (every 10 seconds and on page hide).