Compare versions on your site
Add different versions of part of a page and choose a goal, such as a purchase. Version Compare starts learning from the first visits, automatically showing better-performing versions more often while continuing to try the others.
More traffic helps us learn faster, but there is no fixed test to finish and no winner you need to choose. Check your results whenever you like. We keep optimising while you get on with running your site.
Working with a coding agent?
Give it this prompt. The instructions explain how to inspect your site, configure your account, and check the result.
Read https://version.compare/docs/agent-instructions.txt and help me set up Version Compare on this website. Help me choose or create the right site before choosing an integration. Inspect the existing setup and serving process before making changes, choose the browser script or server proxy, and agree the versions and goal with me.For account setup, use Model Context Protocol lets a coding agent use tools in your Version Compare account. with a revocable access token from Agent access. Keep the token in your agent's environment, not in this prompt or your website.
Definitions
We use the following terms throughout. They are useful to know as you work with Version Compare:
- Version set
- A part of a page with alternatives, such as two headlines or three offers.
- Version
- One alternative in that set. You write the content.
- Goal
- A page visit or interaction you want to measure, such as reaching a confirmation page.
Version Compare shows one version from each set. Sets are discovered from your HTML, including sets added later by JavaScript. There is no experiment registration form or experiment name to invent.
Browser script or server proxy?
You can add Version Compare to your site in two ways: add a script tag to your pages, or run a small server proxy in front of your website. Both use the same versions and goals. The choice depends on how you host your site and whether avoiding a visible change of content is more important than keeping your existing page caching.
Browser script
If you use a Content Delivery Network: servers that keep copies of your pages and files close to visitors, so they load faster. (Content Delivery Network) to keep copies of your pages close to visitors, the browser script is a good fit. It also suits hosting providers that let you add scripts but do not let you install server software. Add a script tag to your pages; you do not need to change how your website is served or cached.
The trade-off is that the browser chooses a version after the page starts loading. A visitor may briefly see the default version before it changes to the chosen one. This visible swap is called flicker.
Server proxy
If you control the server that runs your website, the proxy can make the choice before the page reaches the visitor. It sits between your visitors and your existing web server, or serves a folder of static pages itself. For versions already in the page's HTML, it sends only the chosen alternative, so there is no first-load swap or flicker.
The trade-off is that each page is now tailored to its visitor. A CDN cannot reuse that page for everyone, and each page visit must reach your server. Visitors far from that server may wait longer than they would for a nearby CDN. Images, stylesheets, and other unchanged files can still be cached as before.
If your pages already come from a single server without a CDN, the proxy is usually the better fit: it avoids the flicker without giving up nearby cached copies. It also tells browsers not to save the personalised HTML, so returning to a page still requires a fresh response.