Analytics integrations release (July 2026)

Every analytics integration was rebuilt end to end. Forwarding is now opt in per tool. The event names are yours to change, and they start pre-filled with each tool's own style. Purchases carry revenue. Your own preview and internal traffic never reaches a customer-facing report. A visitor who declines analytics can still see the experiment, just without being measured. Pro plans can also deliver the same events from our servers. Destinations include Google Analytics 4, Mixpanel, Amplitude, or your own signed webhook (an automatic message A vs B sends to your server).

Forwarding is opt in, per tool and per event type

Every tool gets a card in Project Settings > Integrations, and every card starts switched off. Turn one on and A vs B talks to the copy of that tool already running on your page. There is no measurement ID, project token, write key, or app ID to find. We never load a third-party script for you.

Experiment views are sent as soon as a card is on. Everything else is yours to tick, per tool, under Also send. That list covers conversions, purchases with revenue (order total, currency, and order ID), and recommendation views and clicks. Nine tools have a card now. Google Tag Manager is one of them, so getting experiment events into your dataLayer no longer needs custom code. You can keep any single experiment out of all of it, with the Analytics forwarding switch on its review step. Saves reach your live site in about a minute. Read more: Integrations Overview and Integrations Tab.

Event names are yours, pre-filled with each tool's own convention

Each card has a box for every event name. Each box starts empty, with that tool's standard name showing inside it as a hint. Leave it alone and A vs B sends the name that tool's own reports expect: experience_impression with exp_variant_string for GA4, $experiment_started for Mixpanel, $exposure for Amplitude. Built-in experiment reporting in those tools then works with no mapping from you. Type your own name to override it.

Where a rename costs you something real, the card says so: Amplitude does not bill for its own $exposure event, and a custom name loses that. Google Analytics refuses some names outright, so those are rejected when you save rather than failing quietly on your site. Read more: Google Analytics and Amplitude.

Your QA traffic stays out, and a test event proves the wiring

Preview sessions and traffic you have tagged as internal are never forwarded, to any tool, at all. Your analytics reports stay a picture of real visitors while you are still building the test.

To check a setup, the Integrations tab has a Send a test event link. It opens your site in a new tab and sends one clearly labelled test event to every tool you have switched on. You can then watch it land in that tool's live or debug view. Test events never create an experiment view and never appear in your A vs B results. Each card also previews the exact call we will make, under See exactly what will be sent.

Consent categories: run the experiment, measure only the visitors who agreed

Alongside the existing all-or-nothing consent mode, there are now two consent categories: analytics and marketing. Your banner tells us the visitor's answer with avsb.consent.set(). Or, if your banner already speaks Google's consent language, we read that signal automatically: analytics_storage drives our analytics category, and ad_storage drives marketing. An explicit call from you always wins over the automatic reading.

The point of the categories is the common case: the experiment should still run, but the visitor must not be measured. A variation is one specific version being tested, control or one of the challengers. With the default cookie classification, a visitor who declines analytics still sees your experiment, and the same variation on every page. But no experiment views, goals, purchases, or recommendation events are collected, and nothing is forwarded to any tool. Your own avsb.on('event', ...) callback does not fire for them either, so nothing you built on top of it can measure them by accident. The one thing still sent is a small check that tells your dashboard the snippet is installed. It carries your project's snippet key and nothing about the visitor. If you would rather treat our visitor cookie as an analytics cookie, switch the classification. Then a visitor who declines gets the original page, with no experiment and no cookie at all. Read more: Consent Mode (GDPR).

Server-side delivery, on the Pro plan

Browser-side forwarding has one weakness. If an extension blocks the analytics tool, or the visitor leaves before it loads, the event never happens. Server-side delivery sends the same events from our servers to the destination, once the event has reached us. Nothing in the browser can interfere with that leg.

Add a destination in Project Settings > Integrations and choose where events go: your own signed webhook, Google Analytics 4, Mixpanel, or Amplitude. Webhooks carry an HMAC signature and a timestamp, so you can prove a delivery came from us. They also let you pick exactly which event types you receive. Every destination keeps a delivery log of its last 50 attempts, kept for 30 days. Each logged attempt shows when it happened and whether it delivered or failed. It also shows the status, the batch size, how long it took, and the reason for any failure. A Send test event button runs through that same path a real event takes. It tells you what the destination answered, with the status code and the round trip time. Delivery is at least once. Every record carries the same event_id across retries, so duplicates are easy to drop.

Server-side delivery is part of the Pro plan. Forwarding to the analytics tools already on your page stays free on every plan. Read more: Server-Side Delivery.

Events join the person your analytics tool already knows

Google Analytics, Mixpanel, and Amplitude each identify a person by an ID. Their own script creates that ID in the browser: GA4's client ID, Mixpanel's distinct ID, or Amplitude's device ID. Server-side delivery attaches the one that tool already gave the visitor. That way, an event we deliver lands on the profile that already exists, instead of starting a new one. Your experiment data then lines up with everything else you measure about that person.

When that ID was never available, because the tool's own script is not on the page, the event is skipped, not guessed. Inventing an ID would create a phantom user and quietly corrupt your own numbers. Skipped records are counted, and the delivery log names the ID that was missing. Webhooks have no such requirement: they carry our own visitor ID and receive every event you subscribed to.

One event bus for anything without a card

For tools we do not have a card for, avsb.on('event', fn) hands you every event. Each one carries the experiment and variation it belongs to, plus the event type and name. It also carries revenue, the visitor ID, the page, and a unique event ID. The function returns another function that removes your subscription. You can subscribe as many times as you like.

The old window.avsb.onEvent hook has been removed. It held a single callback, so a second integration silently replaced the first. Replace window.avsb.onEvent = fn with avsb.on('event', fn); the data your function receives is the same, with more fields on it. Read more: Custom Integration and the event bus reference.

Reading the numbers honestly

Two new pages exist because these are the questions this data always raises. Why counts differ explains why a gap of roughly 5 to 10 percent between A vs B and your analytics tool is normal. We count visitors; most tools count events. It also explains which of our events line up one to one by event ID. And it explains why conversions and purchases are sent once per live experiment, and must never be summed as if they were separate orders.

Analyzing in GA4 covers the trap that makes GA4 conversion reports look almost empty. The variation travels with the experiment view event only. It does not attach itself to that visitor's later conversions. The page gives you three approaches that work, and says which one to pick.

Released July 2026.