A/B Testing Diagnostic Reference: Error Codes and Debug Report

This page is the machine readable reference for ABTestly’s diagnostics: the stable error codes the snippet prints, the reasons a beacon can be dropped on the server, and how to capture a diagnostic report to attach to a support request. Error codes are a stable contract. The sentence beside a code may be reworded over time, but the code itself does not change, so it is safe to search for, alert on, or quote in a ticket.

Generate a diagnostic report

When something looks wrong, open DevTools on the affected page and run:

window.__abtestly.report({ copy: true })

With copy: true the report is written to your clipboard so you can paste it straight into a support ticket. Without it, the object is returned to the console. For a raw string, use report({ json: true }). The report is deliberately small and non sensitive. It contains:

Field	What it tells support
`config`	Snippet version, site id, domain, run mode, SPA mode, GA4 flag, consent mode
`consent`	The consent mode and whether consent was granted on this pageview
`optOut`	Whether this browser is opted out
`assignments`	Each experiment the visitor was bucketed into, its variant, and whether the assignment came from the initial load or an SPA route change
`serverAcceptance`	Whether the server confirmed the beacons. On a live page this is `unknown`, because live beacons return `204` with no body; run in preview to see real acceptance
`recentEvents`	The last twenty debugger events

The report never includes the query string (only the path), so a preview token is never captured. Detailed per event fields stay masked unless you are in preview mode or have explicitly opted in to sensitive output, the same rule the debugger uses.

Console error codes

These print in the browser console with the [abtestly] prefix, in the form [abtestly] CODE: message.

Code	Level	Meaning	What to do
`CONSENT_KEY_MISSING`	error	Deferred consent mode is on but no consent key is set, so the snippet will never run.	Set a consent key in Settings, SPA and consent, then re-copy the snippet. See Consent and deferred mode.
`VARIANT_JS_ERROR`	error	A variant’s JavaScript threw.	Fix the variant code. The variation code check catches many of these before publish.
`GLOBAL_JS_ERROR`	error	Your site wide Global JS threw.	Fix the Global JS.
`SNIPPET_CRASHED`	error	The runtime failed to start at all. Rare.	Generate a report and send it to support.
`RUNTIME_ERROR`	error	An error happened in a runtime phase. The phase (apply, cleanup, route handling, or an async step) and the experiment id follow the code.	Check the named variant or Global JS, then attach a report.
`TRACKGOAL_ORDERID_MISSING`	warn	A refund `trackGoal` call had no orderId, so the event was ignored.	Pass the original orderId.
`TRACKGOAL_ORDERID_INVALID`	warn	The `trackGoal` orderId was not usable, so revenue was not deduplicated.	Pass a valid orderId string.
`TRACKGOAL_CURRENCY_INVALID`	warn	The `trackGoal` currency was not a three letter code.	Use a code such as `GBP` or `USD`.
`TRACKGOAL_REFUNDID_INVALID`	warn	The `trackGoal` refundId was not usable.	Pass a valid refundId.
`HOST_NOT_ALLOWED`	warn	The current host is not listed for this site, so nothing ran.	Add the host under Site settings, Domain.

Server side beacon drop reasons

A beacon can be sent by the browser and still not be accepted by the server. In the debugger you will see a beacon entry, because the snippet has no way to know the server’s decision; a live beacon returns 204 with no body. So a beacon in the debugger means attempted, not accepted. The blocked IP page walks through this exact gap. These drop reasons appear in ingest telemetry and support tooling, not in your own console:

Reason	Meaning
`blocked_ip`	The visitor’s IP matched a blocked IP rule. Expected for your own QA traffic.
`invalid_json`	The beacon body was not valid JSON. Usually a truncated or tampered request.
`invalid_beacon`	The beacon body was valid JSON but not a valid beacon shape.
`site_not_found`	The site id on the beacon does not exist. Usually a snippet copied from a different site.
`unknown_experiment`	The beacon named an experiment that is not live. Usually a stale cached assignment; it clears on the next load.
`invalid_variant`	The beacon named a variant that does not belong to that experiment.
`unknown_goal`	The beacon named a goal that is not configured on the experiment.
`missing_identity`	The beacon carried no visitor id.
`payload_too_large`	The payload exceeded the size cap. Applies to heatmap snapshots, not exposure or goal beacons.
`handler_error`	An unexpected server error. Rare. Contact support with a report.

A bot heuristic flags suspect requests but never drops them. Only an explicit blocked_ip rule you configured discards data.

Snippet not firing

The ladder for an installed snippet that does nothing.

Own visits blocked

Why a sent beacon is not always an accepted one.

The debugger

The full debugger surface behind the report.

Consent and deferred mode

Where CONSENT_KEY_MISSING comes from.

Getting started

Install

Build a test

Target the right visitors

Mutual exclusion groups

Measure

Read results

Methodology

Signals

Preview & QA

Site settings

Team & access

Assets

Integrations

Billing

Trust & compliance

Developer reference

Troubleshooting

A/B Testing Diagnostic Reference: Error Codes and Debug Report

Generate a diagnostic report

Console error codes

Server side beacon drop reasons

Snippet not firing

Own visits blocked

The debugger

Consent and deferred mode

​Generate a diagnostic report

​Console error codes

​Server side beacon drop reasons

​Related pages

Snippet not firing

Own visits blocked

The debugger

Consent and deferred mode

Generate a diagnostic report

Console error codes

Server side beacon drop reasons

Related pages