Skip to main content
Most variants change the page in place. A redirect variant does something different: instead of applying JS or CSS, it fires the exposure event and then navigates the browser to a different URL.

When to use one

  • You already have two real URLs to test. Landing page A vs landing page B. Do not rebuild B on top of A with JavaScript when it exists already.
  • The variant is heavy enough that in-place would flicker. A full page redesign is a redirect test; a headline tweak is not.

How to set one up

In the variation editor, for the variant you want to be a redirect, set the Redirect URL field. Leave JS and CSS empty (or fill them in, they will not run because the browser navigates before they apply). The Original variant is not a redirect; it stays on the current URL. Only treated variants can be redirects.

What happens at runtime

  1. The visitor loads the current URL.
  2. The snippet decides which variant they are in.
  3. If they get the redirect variant:
    • The exposure event is queued.
    • The browser is instructed to navigate to the redirect URL.
    • sendBeacon sends the exposure before the navigation happens, so the event lands even though the page is unloading.
  4. On the new URL, no re-bucketing happens for the same experiment. they are still in the same variant on any page a matching URL applies to.

Ambient goals

Goals defined on either URL still count. A Page visit goal for /thanks fires when the visitor reaches /thanks, regardless of which variant sent them there. For cross-URL revenue tracking, orderId deduplication ensures the purchase is credited to the visitor’s variant even though it fires on a different URL from where the exposure was captured.

Watch for

  • Redirect loops. If the redirect URL is inside the Location rules of the experiment, the runtime detects the loop and drops the second bucketing. Nothing to do; just do not target a page that redirects back onto itself.
  • sendBeacon failing. In rare browsers (some corporate policies disable it), the exposure event might not land before navigation. ABTestly falls back to a synchronous fetch(keepalive: true).
  • SRM on redirect variants. If the redirect target is slower to load than the Original, some visitors bounce before the redirect completes and their exposure is dropped. This is the classic redirect-test SRM cause. See SRM.

What if I need a soft redirect (client-side route change)?

For an SPA, use JavaScript in the variant:
onCleanup should push back to the original URL if the visitor navigates to a page the experiment does not target. For a hard redirect on an SPA, the Redirect URL field still works. window.location.assign(url) is what the runtime does under the hood, and it always causes a full navigation.