Tracking Events

An event is a single piece of visitor behaviour you want A vs B to capture: a click on a button, a visit to a page, or a named action your code dispatches. You set up the event's tracking (a CSS selector, a URL pattern, or an event key) directly on the metric, in the same form where you create it. Once it exists, that one metric can be reused by many experiments and feature flag rules without redefining it.

The three event types

Click events

Click events fire when a visitor clicks an element that matches a CSS selector. Use them for buttons, links, or any interactive element. You can optionally scope a click event to a single page so a button that appears on both the home and product pages can be tracked separately.

Pageview events

Pageview events fire when a visitor reaches a URL. You choose how the URL is matched, from six modes: starts with a given address (the forgiving default; pages underneath it match too), an exact match, path-only (ignores the query string), contains a substring anywhere, a pattern with wildcards, or a regular expression. Use pageviews for funnel steps, landing pages, and any "the visitor reached this screen" signal.

Custom events

Custom events fire when your own code calls avsb.track.event('your-event-key'). They are the right choice when the action happens server-side, after a delay, or anywhere a click or pageview can't observe it directly: a successful purchase, a form validation pass, an in-app upgrade. Custom events can optionally carry a numeric value (revenue, duration, item count) which lets you analyse them with value-based measures later.

// Fired after a successful form submissionavsb.track.event('newsletter_signup');// With a numeric value, for a metric that measures more than just "it happened"avsb.track.event('video_completed', { value: 92 }); // 92 seconds watched

Events vs metrics

An event describes what happened. A metric decides how to analyse it, and that choice happens each time you attach the metric to an experiment, not when you create it. Take the Click event on your signup button. Attach it to one experiment and count unique visitors who clicked. Attach it to another and count every click instead, or measure revenue per visitor if the click carries a value. You only define the click once. You pick how to measure it each time you use it.

Archive vs delete

Archiving and deleting both immediately disconnect the event from every experiment and flag rule using it, and republish the datafile so the snippet stops tracking it right away. A vs B warns you what will be detached and asks you to confirm. Two references do block the action outright: if the event is on an experiment's sealed analysis plan, amend that plan first (the error names the blocking experiments), and if the event is a bandit's reward metric, point the bandit at a different metric first. Everything else detaches without a block.

What differs is what happens to the event's own record:

• Archive keeps the row. It stops firing everywhere, but you (or a teammate) can unarchive it later if it's needed again. Unarchiving restores the event itself; it does not reconnect it to the experiments or flag rules it was detached from, since those need re-attaching by hand.
• Delete removes the row for good. There is no undo.

Because both options detach the event immediately, archive one you might reuse and delete one you're sure you won't.

Where to go next