Initializing the A/B Testing SDK

Before Noibu can run A/B tests on your storefront, you must setup the A/B Testing SDK. This guide explains how to do that and also explains how the SDK relates to the Noibu script. At the end, you can confirm that the installation works.

How A/B Testing Relates to Your Noibu Script

The Noibu script (collect.js or collect-core.js) manages session replay, error monitoring, and analytics. Existing Noibu customers already run this script.

For more information about deploying the Noibu script see Deploying the Noibu Script

Once the Noibu script deployed, and your domain has an A/B test, the Noibu script downloads a second script automatically. This second script starts the feature flag SDK and creates the object window.NoibuFeatureFlag. You do not need to add anything else to the page.

The feature flag bundle is a second network request. The Noibu script sends this request after it reads its own configuration. Because of this, expect a short delay before flags resolve on first paint — this delay mostly happens on the first page load, since the bundle is cached afterward. See Reading flags without flicker in Implementing an A/B test for more information.

Reading a Flag

Once the bundle loads, listen for the ready event, then read flags from window.NoibuFeatureFlag:

window.addEventListener('noibuFeatureFlagReady', () => {
  const client = window.NoibuFeatureFlag.getClient();
  const showNewCheckout = client.getBooleanValue('new-checkout-flow', false);

  if (showNewCheckout) {
    // render the test variation
  }
});

getBooleanValue(key, defaultValue) returns defaultValue immediately if flags aren’t ready or don’t resolve. String, number, and object flags work the same way, via getStringValue, getNumberValue, and getObjectValue.

Fallback if the Script Doesn’t Load

The Noibu script can be blocked by ad blockers or content blockers, or simply load slowly. Don’t wait on noibuFeatureFlagReady indefinitely: race it against a timeout, and guard against window.NoibuFeatureFlag never existing at all.

const FLAG_TIMEOUT_MS = 1000;

const ready = new Promise((resolve) => {
  window.addEventListener('noibuFeatureFlagReady', resolve, { once: true });
});
const timeout = new Promise((resolve) => setTimeout(resolve, FLAG_TIMEOUT_MS));

Promise.race([ready, timeout]).then(() => {
  const showNewCheckout = window.NoibuFeatureFlag
    ? window.NoibuFeatureFlag.getClient().getBooleanValue('new-checkout-flow', false)
    : false; // script blocked or never loaded — fall back to the default

  if (showNewCheckout) {
    // render the test variation
  }
});

After FLAG_TIMEOUT_MS, rendering proceeds with the default value regardless of whether the script loaded. This bounds the worst-case delay and keeps the page usable even when the SDK never initializes.

How Assignment Ties to Your Noibu Session

The feature flag SDK uses the same browser and session identifiers as the Noibu script. The SDK attaches these identifiers to every flag exposure it records. Because of this, your A/B test results join directly to the conversion, revenue, and error data you already collect in Noibu. You do not need extra instrumentation for this.

Content Security Policy (CSP)

If your company uses a Content Security Policy, add the following URLs to your allowlist:

• cdn.noibu.com: script source

• smokescreen-proxy.noibu.com: flag evaluation and event ingestion. You cannot change this endpoint.

Platform Constraints

• Domain scoping: Noibu evaluates flags per hostname. If your company runs A/B tests on multiple domains, create and target a separate test for each domain in Noibu.

Confirming the SDK Is Working

There is no dedicated debug mode yet. Use the following steps to confirm that the SDK works:

1. Check the global object. window.NoibuFeatureFlag should exist after the bundle loads (Shopify or CDN).

2. Listen for the ready and error events:

   javascript window.addEventListener('noibuFeatureFlagReady', () => console.log('flags ready')); window.addEventListener('noibuFeatureFlagError', (e) => console.warn('flags failed', e.detail?.message));

3. Check the network tab for a request to smokescreen-proxy.noibu.com. Noibu sends flag configuration and exposure events to this address.

4. Inspect the resolution reason. client.getStringDetails(key, default) returns { value, variant, reason }. A reason of "DEFAULT" or "ERROR" means the flag did not resolve as expected. Check the domain scoping first. Also confirm that the test status in Noibu is RUNNING. Do this before you assume that the SDK itself is broken.

Troubleshooting

Symptom: Flags never resolve. The SDK always uses the default value.

What it means: The SDK is loaded, but it cannot match the flag to a running test on this domain.

How to fix it: Confirm that the test’s status in Noibu is RUNNING, not DRAFT. Also confirm that the page’s hostname matches the domain the test targets.

Symptom: A visitor gets a different variation after a page reload.

What it means: The visitor’s targeting key changed between page loads.

How to fix it: Check whether you supply your own targetingKey consistently. If you do not set a key, the SDK creates and stores a stable ID in the browser. If you clear storage, or open a new private window, the SDK creates a new ID. This can change the assignment.

Symptom: The SDK loaded, but nothing renders.

What it means: The SDK only evaluates flags. It does not render anything by itself.

How to fix it: See Implementing an A/B test for the render pattern.

Next Steps

After you install the SDK and confirm that it works, go to Implementing an A/B test. This guide shows you how to implement your first test.