Debug Mode
A vs B keeps the browser console quiet for real visitors. Debug mode turns it on for you, and the snippet then explains itself: which experiments ran, and for every experiment that did not, the exact rule that stopped it.
Nothing to install, nothing to configure, and no effect on anyone else's visit.
Turn it on
Add ?avsb_debug=1 to any page on your site:
https://www.example.com/pricing?avsb_debug=1Then open DevTools and read the console.
The switch is remembered in this browser, so you can drop the parameter and keep clicking through your site with debug output still on. Turn it off again with:
https://www.example.com/pricing?avsb_debug=0It only decides how much the snippet prints. Bucketing, variations, tracking, and your results are all exactly as they would be without it. Your own traffic is still your own traffic, so if you do not want these page views in your results, use a preview link or an internal traffic rule as usual.
What you will see
Why an experiment did not run
One line per experiment that was skipped, naming the gate that stopped it:
[avsb] experiment 300012 skipped: url (needs /pricing, got /)[avsb] experiment 300018 skipped: aud[avsb] experiment 300021 skipped: traffic (50%)The number is the experiment's short ID, the same one shown in the dashboard. The gate is a short code (every visitor downloads the snippet, so the codes are kept terse and this table carries the meaning):
| Code | What it means | Where to change it |
|---|---|---|
dev | This browser is in dev mode and the experiment is not on its allow list. | The Chrome extension's Dev toggle for this tab, not the experiment builder |
sched | The experiment's start or end time excludes right now. | Step 5, Review & Publish (Scheduling) |
url | The page URL does not match the targeting rules. Both values are printed. | Step 1, Targeting (URL Targeting) |
aud | The visitor does not match the audience conditions. | Step 1, Targeting (Audience Targeting) |
excl | Another experiment in the same mutual-exclusion group has this visitor. | Audiences, Exclusion Groups |
traffic | The visitor fell outside the traffic allocation. The percentage is printed. | Step 2, Variations (Traffic Allocation) |
cap | Your plan's monthly tested-visitor limit is reached, so no new visitors enter. | Settings, Billing |
split | This page is not the experiment's control URL, and the visitor has no assignment yet. The page's path is printed. | Step 2, Variations (Control URL) |
novar | The experiment has no variations to serve. | Step 2, Variations |
late | The page was already revealed before the experiment could apply, so it was skipped for this page load to avoid shifting content mid-read. | Nothing; it runs normally on the next page load |
unsupported | The snippet build served to this page does not include a feature the experiment needs (for example its visual changes or a commerce audience), so it was skipped whole. This happens when a browser still holds the snippet it loaded before you published. | Nothing; browsers pick up the new build on their own within about ten minutes of publishing |
A variation you forced
Did you pick the variation yourself, with
avsb.forceVariation() or a preview
link? Then the console says so. It names the experiment's short ID and the
variation's ID:
[avsb] experiment 300012 forced: 1487A force from avsb.forceVariation() persists by default, so this line appears
on every later page where the experiment runs for you, until you call
avsb.exitPreview().
Install and configuration problems
These always print, debug mode or not, because a broken install is not a debugging preference:
[avsb] No snippet key on this page: the loader tag needs data-avsb="YOUR_KEY". Copy it from Project Settings > Snippet.[avsb] Snippet key "abc123" not recognised (404 https://cdn.avsb.cloud/abc123/datafile.json). Check it in Project Settings > Snippet.[avsb] Project is "paused": no experiments will run. Resume it in Project Settings.[avsb] track.event("signup") dropped: no metric has that key. Known: purchase, add_to_cartMessages from your own variation code
options.utils.log.debug() and options.utils.log.info() print in debug mode and
stay silent for real visitors, so you can leave them in your published variation
code. See Utilities.
Prefer to read it on the page?
Everything above is the console version. The
status panel is the same story rendered on
the page itself: add ?avsb_status=1 and you get your key, the config and its
age, every experiment decision in plain English, the consent state, and the
events the page has sent. Use both together when you want the panel's summary
plus the console's exact gate code.
Check the state of the page yourself
Debug mode pairs with the API. In the console:
avsb.version // the snippet build running on this pageavsb.getActiveExperiments() // [{ experimentId, variationId }] active right nowavsb.getVisitorId() // this browser's visitor id, or nullavsb.consent?.get() // what the visitor has agreed toavsb.refresh() // re-run every experiment against the page as it is nowOther ways the console switches on
Debug mode is the self-serve switch. Two others exist and behave the same way:
- Preview links and preview mode. Anyone reviewing a variation through a shared preview link gets the same output.
- Dev mode. The
_avsb_devcookie set by the Chrome extension's Dev toggle, not anything in the dashboard.