New allocation system for new campaigns

Since July 2023, all campaigns are using a new traffic allocation system and while this doesn't drastically change the way your experiments will operate, there are several changes that you need to acknowledge.


How it used to work

Previously, we used to have a simple yet effective system that was based on a random function. For each new allocation that was needed to do, a virtual dice was rolled and we obtained a score between 1 and 100. For a 50/50 traffic allocation, any visitor with a score between 1 and 50 was assigned to the original and between 51 and 100 to the variant. Each campaign had its own dice roll. 

The result of the allocation was stored in the cookie and read by the tag on the following pages. This is how we kept the navigation consistent for a unique visitor.


How it will work

The new approach might seem quite similar in the output but is fundamentally different in the way it is performed.

For each individual visitor, we are going to compute what we call a seed, a unique alphanumeric String that will be persistent in time. This seed, also unique for each campaign will be used to generate a score between 1 and 100 and then the same logic as before applies.

As the seed is computed each time, we do not need to store the result anymore.


The reasons behind the switch


With this new approach, forcing the tag to show a specific variation is made very hard. While there are not a lot of reasons for a malicious user to force a variation on a website as it is only front-end content, we can only get satisfied with additional security. Also, it helps obfuscate the mechanics of our engine and the content of your campaigns for anyone that is too much curious.



We ran several benchmarks and we discovered that the new approach is lightning speed compared to the old one. This might sound quite odd as we are computing the score on each page instead of simply reading it, but in JavaScript, computing a score is a matter of nanoseconds while reading a cookie is more counted in milliseconds. A hundred times better!



We can't provide you with a cookieless solution if we don't get rid of the content we store in it. While we could have done it in many ways, the new approach is the fastest and most sober way of doing your traffic allocation.



Nowadays, cookies can hardly be trusted as many browsers, extensions, and software are designed to fight against them and clean them at regular intervals. With the new mechanism, we expect better reliability in our allocation over time.


What is changing for you

If you have regular usage of AB Tasty, you won't notice the difference as it will operate the same. However, you have to keep in mind that a unique visitor will now have a fixed score for a campaign instead of having a fixed allocation.

Let's take back the example of a 50/50 campaign. In both systems, if a visitor gets a score of 51, they will be exposed to the variant (a score above 49). If you decide to change the allocation from 50/50 to 60/40, the two systems start to behave differently.

  • in the previous system, as the allocation is saved in the cookie, the visitor will keep seeing the variant as long as we don't lose the storage and are still able to identify them.
  • in the new system, the allocation will be computed again and their score of 51 will now place them in the original, as the original is now within 0 and 59. The visitor will switch from one variant to another.

For all campaigns running with this new mechanism, a pop-in will warn you each time you are trying to change the allocation and expose yourself to these risks.

As a reminder, it is highly not recommended to change the allocation while a campaign is running, in both the old and new systems. Doing so might severely impact the reliability of your results, even more now with the new system. We strongly advise you to duplicate your campaign and start a fresh new one unless you consider the risk is low (the campaign is still in QA, only a few visitors have seen it until now, etc ..).


About HTTP websites

Note that this new allocation system won't work under the HTTP protocol as we are using cryptographic tools that are only available under a secure protocol.

If the tag detects it is on an insecure environment, it will automatically fallback to the old mechanism.

Was this article helpful?