Server Side A/B Split Testing with Bunting

Server-side split testing with Bunting is quick and easy to set up with this guide. However, before we continue, it is important to define what a server side split test is in Bunting, and how it differs from a client side split test.


Server side: Content is delivered from your servers before page load, not from Bunting after page load. Your server must define who to show content to, and informs Bunting via Javascript which variation/control group each visitor is in.

Client side: Content is delivered from Bunting’s servers via Javascript. Bunting handles the visitor targeting, and manages the distribution of visitors across each of the different variation/control groups for you.


Advantages of Server Side A/B Testing:

No ‘blink’ effect
With pre-determined experiment variations that are generated before the browser loads up (rather than after, as on client-side), the experiment is unnoticeable as there is no content replacement, and thus no ‘blink’.

Deep Experimentation Capability
Server-side experiments can test more complex things, such as underlying features, server logic, algorithms, etc.

Less Content Loading
Client side variation content is delivered to replace the control group content, meaning that both the variation content and the control content are both loaded, adding to load times. With server side testing, only the content relating to each visitor’s group is loaded, reducing overhead.

Advantages of Client Side A/B Testing

Visitor Targeting
Perhaps the biggest advantage of client side is that you can use Bunting’s visitor targeting tool. With server side A/B testing your software is responsible for figuring out who to show content to. For this reason, client side is recommended when delivering highly targeted personalised content, while server side is fine if you only wish to run a simple A/B split test.

Easily Accessible to Marketers
Marketers with little technical knowledge can deploy tests using Bunting’s visual editor, and through simple JavaScript modification.

No Developers Required
With client-side testing, there is no need to coordinate with a website code release to deploy experiments. Experiments can be developed and run almost instantly.

Minimal SEO Impact
Since Google typically ignores changes implemented through JavaScript for the purposes of search engine indexing, client-side tests have minimal SEO impact relative to server-side tests, which can be indexed.


If you have decided to implement server side testing with Bunting then follow the setup steps below.

  1. In your Bunting account, click to create a new campaign. Within the first section, Visitor Targeting, select the targeting option ‘Server Side Trigger’. You can find this easily using the targeting options search box.
    It is important that you don’t add any other targeting options, as these could conflict and compromise the collection of your split test data.
  2. On the second step, ‘Content’, you need to select a piece of content (even though we won’t actually be using it to make changes). Choose ‘Change website content’ – providing you don’t open the visual editor and start to make changes, Bunting will then not alter to your website. This will act as your ‘Variation A’.
  3. On the third step, ‘Measure Impact’, turn on split testing, and save the changes to return to the campaigns list. You will see the campaign you’ve just created. Make a note of the campaign ID number, next to the campaign name in the list.
  4. If you want to add more variations (for example, a variation B, C, or D) then simply return to the ‘Content’ step in that campaign, and add more empty content to the corresponding variation tabs.
  5. Activate the campaign. At this point Bunting is ready to collect data, and is waiting for your server to identify who to measure.
  6. On your server, build in the content you wish to show to each variation group. You should also retain a control group, in which you make no changes. For every visitor who arrives at your website, you will need your server side software to assign them with a variation or to the control group, and store a cookie to retain this information for their next page load / visit.
  7. When delivering the content to their page, send the following Javascript to your pages too. This will tell Bunting that the visitor is a part of your test, and which test group they are part of:
<script type="text/javascript">
if (typeof window.$_Bunting=="undefined") window.$_Bunting={d:{}};
if (!$_Bunting.d.psc) $_Bunting.d.psc = [];

Where it states ‘XXXX’ you need to denote the campaign ID, and the variation (‘control’, ‘a’, ‘b’, ‘c’ or ‘d’), separated by a colon. So, for example, if your campaign has ID number 123, and you have assigned the visitor to variation ‘B’ then your script will contain:


In the event of a visitor landing in the control group, your script will contain:


If your website is integrated with the ‘Best Performance’ loading method then this script will need to be inserted above your generic Bunting tracking script. If it is set up for ‘Easier Installation’ then it can be placed anywhere on the page. However, it is good practice to always put this script above the generic Bunting tracking script if possible, as this will future-proof your setup in case a member of your team decide to change the installation method in future.