Snippet
The Snippet tab is your central hub for everything related to the A vs B JavaScript on your website. Here you can copy your project's script tag, check whether the snippet is successfully detected on your live site, and write global JavaScript that runs as part of every experiment.
- The Installed or Not detected badge, next to the Install snippet heading.
- Your script tag, with the Copy button.
- The Global custom script card, where you write and publish Project JS.
Accessing the Snippet tab
Open your project, click the gear icon in the left sidebar to open Project Settings, then click the Snippet tab.
Install snippet
Your script tag
At the top of the Snippet tab you will find your project's unique install snippet. It looks like this:
<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>The first tag is a stub that defines avsb.ready, avsb.on and avsb.consent.set immediately: calls to any of them on your page are safely held even if they run before the bundle has loaded. The second tag loads the bundle asynchronously. The YOUR_SNIPPET_KEY part is replaced with your actual project key: a unique identifier that tells the A vs B network which project's experiments to load. Click the Copy button next to the snippet to copy both tags to your clipboard, then paste them into the <head> section of your website's HTML.
Add the script tag right after the opening <head> tag. The earlier the snippet loads, the less chance there is of visitors briefly seeing the original version before a variation is applied. See Anti-Flicker for more detail on preventing this flicker effect.
Snippet detection badge
Next to your script tag is a status badge that says whether A vs B has seen the snippet running on your site:
- Installed (green): a real visitor's browser has loaded the snippet and reported back. Experiments can run. The badge shows when this first happened.
- Not detected (gray): A vs B has not heard from the snippet yet.
How detection works
Each time the snippet loads in a visitor's browser, it reports back to A vs B. This happens on its own: you do not need to trigger a check, and the page updates itself the moment a report arrives.
While the badge is gray, the text under it tells you what stage you're at:
- Under five minutes: "Waiting for the first visit." This is normal. Open your own site once, even behind a login or a firewall, and that one visit is enough to turn the badge green.
- Five minutes or more: "Nothing has arrived in the last five minutes." Now check three things: both tags are on a page that's actually live (not just saved), the key in the loader tag (the second
<script>line) matches the one shown above, and no ad blocker is running in the browser you're testing with. A Check again button appears so you can re-check without reloading the page.
Your snippet build
A vs B keeps the file your visitors download as small as possible: optional features are left out automatically when your project does not use them, and added back the moment a publish needs them. The Your snippet card, directly under your install tags, shows you exactly where your project stands:
- The real size. The big number is the measured size of the exact file your visitors are served, not an estimate.
- What is inside, and why. Each optional part (the visual editor engine, and shop and recommendations) is listed as included or not included, with the reason in plain words, for example how many live tests use point-and-click changes or that a revenue metric is live. You never switch these yourself: publishing something that needs a part adds it automatically, and the card tells you what that would weigh.
- What loads only on demand. Preview and editing tools, shop data tools, analytics integrations, and the status panel are fetched only when something on the page needs them, so everyday visitors never download them.
- Running on your site. The last time a real browser loaded your snippet, which file it was running, and how long ago. Right after a publish that changes your file, this line shows updating, which normally resolves within a minute or two.
If the card warns that your site still runs an old file
When visits keep reporting the old file more than ten minutes after a publish changed it, the line becomes a warning. Two things to check:
- A cache in front of the snippet. If your site serves our snippet through its own cache, proxy, or performance plugin, that copy can go stale. Exclude the snippet URL from caching, or purge it, and the next visit picks up the current file.
- A copied file instead of the tag. If the snippet was downloaded and self-hosted rather than pasted as the two tags from this page, it never updates. Replace it with the tags shown above.
Some projects are set to always receive the complete build; the card says Pinned to the full build when that applies to yours.
Global custom script
What is Project JS?
Project JS is a block of JavaScript (or TypeScript) that you can write once and have it run automatically before every experiment in this project executes its variation code. It is designed for setup logic that all experiments share: things like defining helper functions, setting global variables, or initializing a third-party SDK that your variation code depends on.
Common uses for Project JS include:
- Defining a shared utility library your variations call into
- Setting up event tracking wrappers
- Fetching feature flags or user attributes that experiment conditions need
- Initializing animation or UI libraries used across multiple experiments
Editing Project JS
Before you open the editor, use the JS / TS switch on the Global custom script card to pick JavaScript or TypeScript. Then click Edit Code to open the same Monaco code editor used in the Visual Experiment Builder. It supports syntax highlighting, auto-completion, and bracket matching.
When you're writing TypeScript, a Lint control above the editor lets you choose how strict the checking is: off (no checking), standard (shows warnings but never blocks you), or strict (blocks Publish until every type error is fixed). Either way, TypeScript gets full autocomplete for the window.avsb API, so methods like track.purchase(), recs, and commerce show inline documentation as you type. TypeScript is compiled to JavaScript at publish time, so there is no runtime cost.
As you type, your edits are kept as a draft in that browser tab. A draft is private: it never reaches your live website until you publish it, so you can experiment freely without affecting running experiments. This also means the draft is not saved to A vs B until you publish: if you close the tab or reload the page first, unpublished edits are gone, so publish (or copy your work somewhere safe) before you navigate away.
Draft and publish workflow
Project JS follows the same draft/publish workflow as experiment variations. The status badge next to the editor shows the current state:
- Published (green): the version in the editor is live. All experiments in this project are using this script.
- Unpublished changes (yellow): you have made edits that have not yet been published. Your live site is still running the previous version.
- No code (gray): no Project JS has been written or published yet. This is the default for new projects.
When you are ready to deploy your script to your live experiments, click Publish. The updated script will be included in the next experiment execution cycle.
When you publish Project JS, the new script version is used by all running experiments in the project from that point forward. Test your changes carefully in a staging project before publishing to production.
Local IDE development
If you prefer writing project scripts in your own editor or IDE, use the A vs B CLI to pull the script to a local folder, edit it with full IDE support, and push it back:
avsb project pull PRJ-<id>This creates a new folder named project-<id> containing project.js or project.ts (depending on the language you selected). cd into that folder, make your edits, then push them back. Unlike pull, push takes no project id: it reads the folder's own record of which project it belongs to.
avsb project pushSee the CLI reference for full details.
How Project JS is executed
For a detailed explanation of when Project JS runs relative to variation code, global scripts, and metrics, see How Experiments Execute › Project JavaScript.
Consent integration
If your project has consent mode turned on, one more card appears at the bottom of this tab: Consent integration. With consent mode on, the snippet still loads your datafile and runs your global custom script, but it will not set cookies, run experiments, or track events until your site calls avsb.init(). This card shows example code for wiring that call up to your own cookie banner, and you can put the same code directly in your global custom script above instead if you prefer one file.