Runtime bindings

​

The names

​

The order

​

Using them

console.log('Applying', ABTESTLY_EXP_KEY, ABTESTLY_VARIANT_KEY);

// Key your own storage per-variant
localStorage.setItem(`myapp:${ABTESTLY_EXP_KEY}:${ABTESTLY_VARIANT_KEY}`, '1');

// Track a variant-scoped custom event to your own analytics
window.analytics?.track('variant_applied', {
  experiment_key: ABTESTLY_EXP_KEY,
  variant_key: ABTESTLY_VARIANT_KEY,
});

​

Why the key and not just the UUID

​

What is not in scope

• this. The variant function’s this is set to the runtime’s internal apply context, not window. Reach for window explicitly if you need it.
• Any DOM helper. Use document.querySelector, abtestly.waitFor, or your own libraries, the runtime does not inject jQuery-shaped shortcuts into scope.
• A framework’s runtime. React, Vue, and friends are not auto-imported. If your variant needs a framework, load it via Dev libraries or from the page itself.

​

onApply callback signature

• experimentId and experimentKey, same as the bindings above.
• variantKey, same as the binding.
• routeRevision, a monotonic counter that ticks on every SPA route change. Compare against it inside an async apply to detect supersession:

abtestly.onApply(ABTESTLY_EXP_ID, async (ctx) => {
  const startRev = ctx.routeRevision;
  const data = await fetchSomething();
  if (ctx.routeRevision !== startRev) return; // superseded, abort
  doThingWith(data);
});

​

Stability