Snippet Not Detected

If your project settings page shows a grey "Not detected" badge on the Snippet tab, A vs B has not yet confirmed that the snippet is live and loading correctly on your website. This page walks you through every possible cause and how to fix it.

Symptoms

The Project Settings → Snippet page shows a "Not detected" badge.
No experiments are running even though they are published.
The snippet badge stays grey despite the tag appearing to be on the page.
This badge is always grey, never red, while A vs B is waiting for a first visit.
This line updates once A vs B has not heard anything for five minutes.

Checklist

Check both tags are in the page's head section

Open your website in a browser. Right-click anywhere on the page and choose View Page Source. Search for avsb in the HTML. You should find two tags, the inline stub first and the loader second, both inside the <head> element rather than the <body>. A loader tag on its own still runs experiments but cannot hide the page; a stub on its own runs no experiments, and hides the page until its safety timer reveals it about 3 seconds later. See the correct placement example below.

Verify the snippet key matches your project

The loader tag carries your project's key twice: in data-avsb="..." and in the ?id=... query parameter. Compare it to the key shown in Project Settings → Snippet. They must be identical. A typo or an outdated key from a different project stops everything, and the browser console will say so in as many words.

Check the browser DevTools Network tab

Open Chrome DevTools (F12) and click the Network tab. Reload the page. Search for snippet.js in the request list. You should see a request to cdn.avsb.cloud/snippet.js with a 200 status code. See the responses to look for below.

Read the console

Open the Console tab in DevTools and look for lines starting with [avsb]. When the snippet cannot run it says why, in one line, naming the value involved and where to fix it: an unrecognised key, a blocked host, or a paused project. Any other JavaScript error on the page can also stop the snippet before it pings. Common causes are listed below.

Check for Content Security Policy (CSP) headers

Open DevTools → Console and look for CSP violation messages that mention avsb.cloud. CSP is a browser security feature that can block scripts from external domains. If your site has a strict CSP, you need to add cdn.avsb.cloud to your script-src allowlist, and both cdn.avsb.cloud and ingest.avsb.cloud to your connect-src allowlist. See the required CSP additions below.

Check for ad blockers or privacy extensions

Ad blockers and privacy extensions like uBlock Origin, Privacy Badger, or Ghostery may block analytics and A/B testing scripts. Test in a clean Chrome profile (no extensions) or in an Incognito window with extensions disabled. If detection works without the blocker, the blocker is the cause.

Load a page of your site yourself

Detection is triggered by a real page view, not by A vs B visiting your site. Nothing is checked until the snippet runs in someone's browser, so if no one has loaded the site since you deployed, open it yourself once. The domain does not matter: staging subdomains, internal sites, and sites behind a login all report fine.

For step 1, both tags should be placed inside the <head> like this:

HTML

<head>  <meta charset="UTF-8" />  <script>  window.avsb=window.avsb||{};window.avsb.q=window.avsb.q||[];  window.avsb.ready=window.avsb.ready||function(f){window.avsb.q.push(f)};  window.avsb.on=window.avsb.on||function(n,f){var t=['on',n,f];window.avsb.q.push(t);return function(){t[0]=null}};  window.avsb.consent=window.avsb.consent||{set:function(s){window.avsb.q.push(['consent.set',s])},get:function(){return{}}};  window.avsb.track=window.avsb.track||{};['event','segment','purchase','cart'].forEach(function(m){window.avsb.track[m]=window.avsb.track[m]||function(a,b){window.avsb.q.push(['track.'+m,a,b])}});  (function(){window.avsb._t0=Date.now();window.avsb._df=fetch('https://cdn.avsb.cloud/YOUR_SNIPPET_KEY/datafile.json').catch(function(){});var d=document,e=d.documentElement,s=d.currentScript,a=s&&s.getAttribute('data-avsb-timeout'),t=a==null?3000:+a;if(!(t>0)||window.avsb.version)return;e.style.opacity='0';e.style.pointerEvents='none';window.avsb._t=setTimeout(function(){e.style.removeProperty('opacity');e.style.removeProperty('pointer-events')},t)})();  </script>  <script src="https://cdn.avsb.cloud/snippet.js?id=YOUR_SNIPPET_KEY" data-avsb="YOUR_SNIPPET_KEY" async></script>  <!-- rest of head --></head>

HTML13 lines

For step 3, if you see one of these results in the Network tab:

No request at all: the tag is missing from the page or the browser is not loading it. Double-check step 1.
A 404 error: the snippet key in the URL is wrong. Check step 2.
A blocked request (red row, no response): a Content Security Policy or network filter may be blocking the request. See step 5.

For step 4, the [avsb] console lines map straight onto a fix:

"No snippet key on this page": the loader tag lost its data-avsb attribute and its ?id= parameter, usually to a template or a tag manager that strips attributes. Re-copy the snippet from Project Settings.
"Snippet key ... not recognised (404 ...)": the key does not belong to any project. Compare it with Project Settings → Snippet.
"Could not reach https://cdn.avsb.cloud/...": the request never left the browser. Ad blocker, firewall, or Content Security Policy. See step 5.
Project is "paused": the project itself is not running experiments. Resume it in Project Settings.
"Config fetch failed: HTTP ...": the CDN answered, but not with your config. Retry, and contact support if it persists.

Other page-level problems that can stop the snippet before it pings:

A syntax error in the page's own JavaScript that runs before the snippet.
A conflicting script that overwrites window.avsb.

For step 5, this is the complete Content Security Policy a page needs to run A vs B. It is the same policy on every page of these docs that mentions CSP, so you never have to collect it from more than one place:

Plain text

script-src  'self' https://cdn.avsb.cloud 'unsafe-inline' 'unsafe-eval';style-src   'self' 'unsafe-inline';connect-src 'self' https://cdn.avsb.cloud https://ingest.avsb.cloud https://app.avsb.cloud;img-src     'self' https://assets.avsb.cloud;

Plain text4 lines

What each part is for:

https://cdn.avsb.cloud in script-src: the snippet bundle and its on-demand pieces load from our CDN.
'unsafe-inline' in script-src: the first half of the install tag is a small inline script that hides the page before the first paint; an external file would arrive too late to prevent the flash it exists to prevent. Nonce variant: if your platform can stamp a per-request nonce, add nonce="..." to BOTH halves of the install tag (the inline stub and the loader tag) and use script-src 'self' 'nonce-...' https://cdn.avsb.cloud 'unsafe-eval' instead; browsers ignore 'unsafe-inline' when a nonce is present, so this is the stricter policy.
'unsafe-eval' in script-src: the code you write in the experiment builder (variation JavaScript, project JavaScript, triggers, Custom JavaScript audiences) is compiled in the visitor's browser; without this directive every experiment that carries custom code stops running.
style-src 'unsafe-inline': variation CSS is applied as an inline style element. There is no nonce workaround for styles the runtime injects. If script-src allows the snippet but style-src blocks inline styles, visitors are bucketed and counted while seeing the control's styling; the snippet reports this to your experiment's error log as an apply failure, but the fix is the directive.
connect-src: the CDN serves your configuration, ingest.avsb.cloud receives events and error reports, and app.avsb.cloud answers preview links and editor sessions (and the SDK heartbeat and stream ticket where you use them). A browser flag SDK with streaming on also needs https://stream.avsb.cloud, where its live updates arrive.
img-src https://assets.avsb.cloud: images you upload in the editor are served from there.

Detection alone needs only the cdn and ingest entries, so a page can ping while experiments still fail to apply. Ship the whole policy and both problems are covered at once. The canonical copy, kept with the full host list, is Data-plane endpoints and credentials; the Visual Editor's own notes are in Visual Editor troubleshooting.

For step 6, when ad blockers block the snippet:

Ad blockers blocking the snippet only affects your own browser during testing; real visitors without blockers will see the snippet normally. However, it does mean you will not be able to test from your own browser while the blocker is active.

A vs B confirms the install by receiving a ping from the snippet as it loads in a browser. Nothing happens until someone loads a page: if no one has visited since you deployed, visit the site yourself. The badge updates on its own once the ping arrives; there is nothing to refresh. The ping carries only your snippet key, so it works on private, internal, and staging sites too.

Still not working?

If you have been through every step above and detection still fails, open DevTools and run this in the Console on your website:

JavaScript

// The install tag defines window.avsb on its own, so "is it defined" proves// nothing. This checks whether the real bundle took over.console.log('bundle running:', typeof window.avsb?.getActiveExperiments === 'function');console.log('visitor id:', window.avsb?.getVisitorId?.());

JavaScript4 lines

If bundle running: false, only the stub is present: the loader tag never ran, or the bundle stopped before installing the API. Scroll back through the console for the [avsb] line explaining why. If bundle running: true, the snippet is healthy and the ping itself is being blocked on its way out (check connect-src in your CSP, and any network filter in front of your site). Contact support with both results and any [avsb] lines.