When something in an experiment is not doing what you expect, the first thing
to reach for is the debugger. It runs entirely in the browser and requires no
dashboard access.
Call it
Open DevTools on the site with the snippet installed:
Or, for a compact JSON blob you can paste into a bug report:
The same object is also reachable as window.abtestly.
What it shows
- Session. Snippet version, site id, domain, SPA mode, whether GA4 is
enabled, which product analytics adapters are on, the consent mode, and
whether this page load is
live or preview.
- Loaded experiments. Every experiment active on this page, with the
variant assigned.
- Registered goals. Every goal the snippet registered, with its selector or
condition, its state, and how many times it has fired this page load.
- Event log. A ring buffer of the last 100 events the runtime observed.
Older events are dropped and the count of dropped events is reported.
What the debugger does not prove
The debugger observes the snippet inside your browser. That is a real and
useful record of what the snippet decided and attempted, but it is not
confirmation that anything reached your results. Three states are distinct and
worth keeping apart:
- Emitted. The snippet built an event and handed it to the browser. A
beacon event in the log with wouldSend: true means exactly this.
- Sent. A transport actually accepted it. The debugger records
serverStatus: 'unknown' on a normal live send, because the beacon is fire
and forget and its network outcome is never awaited.
- Accepted and recorded. The ingest endpoint validated the payload, it
survived filters such as blocked IPs and visitor opt out, and it was written
to your results. The debugger never observes this.
So “the goal fired” in the debugger means the snippet’s handler ran, not that a
conversion landed in your report. To confirm the latter, check the experiment’s
results.
Sensitive fields
The debugger masks a narrow set of fields: orderId and refundId inside
a goal event’s payload. They are shown as a short prefix and the last four
characters rather than in full.
Masking is lifted when you pass includeSensitive: true and one of these
is true:
- The page is in preview mode.
- You have set the opt in explicitly:
localStorage.setItem('abtestly_debug_sensitive', '1').
This gate is not access control, and it does not make a debug blob safe to
share. Anyone who can open DevTools on the page can set that localStorage key
themselves, and everything outside orderId and refundId is never masked at
all. A debug blob contains your site id, your domain, your experiment and
variant names, every goal selector and URL pattern, the page path, and the
browser’s user agent.Treat the output as internal. Read it before pasting it into a support ticket
or a public issue, and do not put anything confidential into variation code,
goal selectors, experiment names, or error payloads on the assumption that the
debugger will hide it.
dev.apply
For prototyping:
Treats the experiment as active for the rest of the tab session, so your
onApply callbacks fire and SPA navigations re cycle the lifecycle. It does
not bucket the visitor, does not fire a beacon, and does not inject the
variation’s CSS or JS from the dashboard. It is a flag flip for the lifecycle
hooks, meant for iterating on variant code locally.
abtestly.dev.* is for the console and userscripts only. Do not leave it in
variation code; the dashboard editor will flag it.
Event kinds in the buffer
config_loaded, snippet fetched config.consent_granted, consent flipped to granted.assignment, visitor was bucketed (or not).variant_applied, variant JS/CSS applied.variant_apply_error, variant code threw. Includes message and stack.spa_route_change, SPA navigation handled.spa_cleanup, variant cleanup ran on route change.spa_reapply, variant re applied on a new matching route.spa_stale_cancelled, an async apply detected supersession and bailed.activation_view_armed, IntersectionObserver installed for a
When visible trigger.preview_token_rejected, a preview link’s token was refused, with the
reason. Most often the token expired or preview links were revoked.beacon, the snippet built an event for /e or /err. Carries
wouldSend: true, and suppressedReason: 'preview' when preview mode
stopped it leaving the browser. This records the attempt, not delivery.server_verdict, preview mode only. Preview posts the would be payload
to /e/validate, which stores nothing, and records whether the server
would have accepted it. See the note below.
What server_verdict actually checks
/e/validate runs the same payload parse, the same beacon schema check, and
the same site lookup as the real ingest endpoint, then returns
accepted: true or a reason such as invalid_json, invalid_beacon, or
site_not_found.
It stops there. It does not apply blocked IP rules, does not count the
visitor, and does not write anything to your results. A verdict of accepted
means the payload is well formed and the site resolves, not that an equivalent
live event would be recorded.
If the request itself fails or is blocked, the event records
serverStatus: 'unreachable' instead.
Answering common questions
“Why did my variant not apply?” Look for an assignment event for that
experiment. If there is none and the experiment is missing from the loaded
list, it did not match: targeting, audiences, or consent. The debugger does not
record a reason for that, so narrow it by hand against the experiment’s
Locations and Audiences. If there is an assignment but no
variant_applied, look for a variant_apply_error in the buffer.
“Why did my click goal not fire?” Check registered goals in the output; the
goal is listed with its selector and state. Click the target and re run
debug() to see whether a beacon event appeared.
“Why is my experiment not in the debugger at all?” The config did not
include it. Either the experiment is not live, or you are on a page that does
not match its Location, or the site does not match the snippet (wrong snippet,
wrong domain).
Last verified against the shipped snippet on 2026-09-01. 
