window.ABTEST

The storefront runtime configuration object — the settings the AB Test runtime reads to know where to fetch assignments, whether to log, and how the current page fits into template tests.

What it is

window.__ABTEST__ is a plain object the theme app extension writes onto the page before the storefront runtime (theme-ab-runtime.js) executes. The runtime reads it once, on load, into its internal cfg variable and uses it to configure every assignment call, redirect, and log line.

You do not create or edit this object. It is emitted by the AB Test app embed (theme app extension) each time a storefront page renders, and its values reflect the current shop, page, and app settings. This page documents the fields only so you can recognize them while debugging.

Enable the app embed under Online Store > Themes > Customize > App embeds for this object to be injected. See Quickstart for setup.

Fields the runtime reads

The runtime reads exactly four fields from window.__ABTEST__. Everything else it needs — the visitor id, targeting signals, cached assignments — it derives at runtime and stores in cookies, not in this object.

Field	Type	Purpose
`endpoint`	string	Base URL of the assignment endpoint. The runtime appends its own query string and fetches the visitor's assignments from here.
`debug`	boolean	When truthy, the runtime logs to the browser console. Otherwise it stays silent.
`templateName`	string	The Shopify template type of the current page (for example `product`, `collection`, `index`). Used to decide whether a template test applies here.
`reveal`	function	Anti-flicker callback. The runtime calls it to un-hide the page once it has decided not to redirect.

A representative object, as the extension emits it:

window.__ABTEST__ = {
  endpoint: "https://abtest.sofcy.com/…/assign", // app-hosted assign endpoint
  debug: false,
  templateName: "product",                        // this page's template type
  reveal: function () { /* un-hide the page */ }
};

endpoint

The runtime builds each request as endpoint + "?vid=<visitorId>&" + targetingQuery(), where the targeting query carries device class, new-vs-returning, referrer, and any utm_* params. The same base URL is reused, with an &activate=<experimentId> parameter, when a manual-trigger JavaScript test enrols a visitor. See the Assign endpoint reference for the request and response shapes.

templateName

This value only matters for template tests. A template test variant carries a templateType and a suffix; the runtime redirects the visitor to ?view=<suffix> only when templateName equals that templateType. On any other page the field is simply the current template and no template redirect fires. It plays no role in URL, theme, or JavaScript API tests.

reveal

For a first-time visitor, the extension can hide the page briefly so a URL, template, or theme redirect happens before the control experience paints. The runtime calls reveal() once it decides not to redirect (and on any assignment failure — it always fails open to the control). If reveal is not a function, the runtime skips this step and leaves the page as-is.

Most visits never hide the page. A returning visitor's cached assignment lets the runtime redirect — or not — before paint, so only a first-time visitor pays the anti-flicker hide.

Debug mode and logging

When debug is truthy, the runtime writes to console.log with an [abtest] prefix. It logs the resolved assignments, any redirect target, and caught errors (bad cache cookie, failed fetch, cart-stamp failure, and so on). When debug is falsy — the normal production state — nothing is logged.

[abtest] assignments [ … ]
[abtest] redirecting to /pages/landing-b

The flag is set by the extension, so you generally read it rather than set it. To confirm the current state from the browser console:

window.__ABTEST__.debug   // → true / false / undefined

What is not in this object

Some settings people expect to find here live elsewhere, by design:

Analytics forwarding. Which client-side tools receive experiment membership (Segment, Heap, Hotjar, Clarity) is configured app-side and delivered per request in the assign response as clientIntegrations — not as a field on window.__ABTEST__. See Data and consent.
Visitor id and assignments. The anonymous visitor id (_ab_vid) and the cached assignments are managed at runtime in cookies. Read them through the JavaScript API (window.abtest.getVisitorData()), not from the config object.
Consent state. Opt-out consent is tracked in the _ab_consent cookie, synced from Shopify's Customer Privacy API and auto-detected OneTrust/Cookiebot — not configured here.

Inspecting the config while debugging

You can read the whole object from the storefront console to confirm the extension is injecting it and pointing at the right endpoint:

console.log(window.__ABTEST__);

After the runtime has loaded, the same object also carries an __internals property. The runtime attaches it as a set of test hooks (its path-normalization and redirect-resolution helpers, plus the public API and consent functions) used to check the storefront file against the server's experiment logic. It is an implementation detail for the app's own tests — do not build against it.

Treat window.__ABTEST__ as read-only. Overwriting endpoint, debug, or templateName after the runtime has read them has no effect on the current page, and hand-editing the injected object can break assignment or redirect behavior. For custom variants, use the supported JavaScript API instead.