AI-enabled web experimentation

One script tag in the head is the whole installation, and it is the only change to your site. From there a variant is built by pointing at elements on your live pages, so the first experiment is limited by how long it takes you to decide what to test rather than by anything that has to be procured, built or scheduled. Nothing goes live by accident while you are learning: a new experiment is a draft until you start it.

Each website gets its own compiled file with its experiments baked into it, so the runtime already knows what to run when it loads and nothing waits on a call to us before the page renders. The loader in your page is under 1 KB, and the heavier features, such as page data and data feeds, only load on websites whose tests use them. The page is briefly held back while changes are applied, which is what stops visitors seeing the original flash into the test, and it is revealed from four independent code paths so a failure shows the unmodified page rather than a blank one. Tracking loads last, after the page is visible, so measurement never delays rendering.

Text, styling, layout and position are edited by pointing, hover and focus states included, and whole sections are added from a library of components that take on your site's own fonts and colours. A change can carry the page's own data, such as each product's price, or values from a feed you already publish, and a selector can apply it to every matching element. You can also describe the change in plain words and let the AI editor propose it, previewed on the page before anything is saved. Past that it stops honestly rather than badly: anything the inspector cannot express you write as custom CSS or JavaScript on the variant, which means a test is never blocked on the tool. The genuine limit is a change that happens before the page exists, ranking, pricing logic, a recommendation model. Those are server-side experiments, and they need your engineers.

As many as you have ideas for, and this is the answer worth checking against whatever you use today. Each experiment randomises independently, so an eligible visitor enters every experiment they qualify for and each one measures against the full eligible audience. Concurrency does not divide your sample here, which is why the platform checks whether two tests would interfere rather than rationing how many may run. Throughput is usually the difference between a programme that pays for itself and one that does not.

Winners you have hard-coded are already in your own codebase and are unaffected, which is what the implementation queue exists to push you towards: it lists every winner still being served by us and keeps flagging it until your engineers have room. Winners still served by the platform stop when it does, the same way any variant stops. The experiments, the hypotheses and the written history stay in the account rather than in tooling of ours.