In only three months, seven Samsung markets experienced a notable growth in incremental revenue. Some markets even reached a 119% increase and at times peaked up to 1 million euros in revenue uplift.

After six months, the A/B experiences that our team developed had already exceeded all projections by nearly 29%. One can’t deny the fact that these results are due to the tireless work of multiple teams across three companies. However, the sheer amount of experiments delivered at such a fast pace was undoubtedly our best practices and years of experience coming into play. And today we are excited to explain why.

How does this work?

A/B testing is the action of comparing two web page versions to conclude which one performs better at its designated goal, be it reminding customers what they’ve forgotten in their cart or simply providing better payment information for certain products. The possibilities are endless.

In e-commerce, performance is usually measured by, but not limited to, order purchases or revenue uplift as seen in some of the results we shared in the previous section.

During this project, we developed A/B experiments which performed with astounding results across different Samsung markets and audiences. The reasons behind this: great ideas and immaculate implementation.

Cutting-edge meets platform compatibility

Our development team delivered 77 experiments in a six-month period. At some point, there were very few pages on Samsung that were not running at least one of the experiments we had built. It wasn’t easy to explain the means of making this feasible and error-proof; this remains a challenge still.

However, it was very clear to us, there’s a method to madness. We’ve developed a one-of-a-kind approach to building custom, reusable and platform-independent experiments. This approach, and all best practices, are embodied in our Experiment Framework which along with years of experience building experiments made this delivery pace achievable. This framework enabled our team to focus only on developing what was absolutely necessary and worry less about cross-platform or cross-market compatibility.

These experiences were deployed across markets of Germany, France, Italy, Belgium, Netherlands, Spain, and Poland on all browsing devices and platforms. All of them were built using our Experiment Framework.

Reusability at its finest

True inventions are not often and almost always built upon some previous knowledge. We have embedded this principle into the way experiments are built and deployed. All experiments are analyzed through the eye of reusability so that we avoid building anything twice and invest our time and effort only on what is absolutely necessary. And this was precisely one of the key ingredients that made developing experiences quickly during this project a smooth and seamless process.

Component-based development is not a new concept, nonetheless, it can be new when it’s not utilized properly. Avoiding blocks and introducing reusable, configurable, and responsive components have made all the difference. We now are able to understand, reuse, and build experiments better than ever before.

Important to note that the obstacles we came across during this very fast-paced project gave us even more ideas and a newfound initiative to enhance our framework to a new level of utility.

Learning through challenges

Apart from the projected outcomes during this project, the most invaluable characteristic of its entirety was learning by overcoming challenges, and this phenomenon is ubiquitous throughout all of our work. In the last couple of months, we were delivering twice as many experiments as we did in the beginning; cross-market and cross-platform experiments have now become the new norm when it comes to A/B development and the time required for deploying an idea across different pages, markets or sites has decreased significantly.

Alongside these improvements, our repertoire of A/B experiences has never stopped growing and it's proving more useful every day. Might happen that building experiences from scratch will be required continuously less and we’ll resort to reusing and reconfiguring previous work instead.