In recent years businesses of all shapes and sizes have woken up to the potential offered through Experimentation on their websites and apps. Companies have conducted experiments that range in complexity from button colour or placement changes to checkout flow changes. It’s no secret that testing is a viable growth strategy, organisations have invested a lot in understanding their customers by way of data and are now attempting to make use of this information to enhance customer experience to grow.
Software vendors across the board have attempted to make testing as accessible as possible and have democratised the very concept of experimenting through the provision of WYSIWYG editors that in essence enable non-technical users to make changes to a website by way of what is in effect a simple drag and drop interface almost. However, things are changing. Companies are beginning to jump onto the testing bandwagon in large numbers. Many have come to the realisation that there’s much more to testing than just swapping images, content, text, site layout and style sheets and that things like customer journey, check-out flows, pricing and even product offerings can be tested to enhance the overall customer experience to move the dial a few notches.
So, just how do you move on from testing visual or experiential changes to look at more sophisticated aspects of the customer journey? To answer this question, we must first look at the fundamentals from a technology perspective, but we’ll do so in layman’s terms. Conventional testing tools have mostly been, up until recently client-side. What I mean by this is any changes that are required to the experience are initiated in the end user’s browser using JavaScript technology, a method also known as DOM manipulation. A request is made by the end user’s browser to the web server which in turn returns the relevant web page and any experimental changes to this page are executed at run time in the browser. So the underlying content is still present and the new content for the experiment is served as an overlay. It all occurs so quickly which means that the end-user doesn’t even know it’s happening (in theory).
There are some draw backs to this method. Most marketers will know that the IT team or developers in particular get quite funny about anything that manipulates their web pages for fear that it could hold up page load time and thus degrade user experience. This is likely to happen when the script needed to initiate a change on the page is loaded synchronously – in other words should the files returned by this script fail to load in time then this could hold up the rest of the page which would have a noticeable effect on the end user’s experience. The alternative to this is to load the script asynchronously, which means that it will load as and when it’s ready without holding up the page, however if the script fails to load in time then the default content will appear first before the variation loads which could cause an undesirable effect known as flicker. The bottom line here that is both methods have pros and cons which require careful evaluation.
What’s the alternative? There are a couple of methods available, one is to utilise a server-side solution which uses an SDK or an API which can manipulate the content at source. In other words, the logic required to determine which variation to serve is initiated server-side and the associated variation is served as if it were the default version as far as the browser is concerned – in other words there’s no loading of the underlying website and then an overlay in the browser. The other method uses a proxy as an intercept between the end user’s browser and the web server.
The question then becomes, which method should I chose and when? The answer is dependant upon your business, its maturity, resourcing constraints and sophistication as far as your experiment ideas are concerned. Simple experiential changes can be initiated using client-side testing tools provided your website isn’t built using a Single Page App (SPA) framework which adoption rate is rapidly increasing e.g. React.js or Angular.js etc. More complex tests on SPAs or ones that aim to change things such as dynamic content, or content that relies on a database entry being returned as a result of an end user’s query, such as an itinerary search on a travel site can be executed far easier and neater using server-side methods.
Whilst server-side testing offers a great deal more flexibility and robustness around your experiments, the drawbacks are often related to the complexity that guarantees the need for development resources and more often than not being constrained to your company’s development sprints. Whilst client-side tools have democratised testing which has by enlarge been a big part of the appeal, server-side testing enables you to test a great deal more and if handled properly, can really drive significant returns and help give you a competitive edge.
Other advantages that server-side testing offers above client-side testing are around privacy and security. All testing and targeting decisions that are made are kept internal and are handled within your business infrastructure and as such these activities are invisible to the end-user which reduces the ‘attack surface’.
So, where next? Well, I foresee that most businesses will still rely on client-side testing for the foreseeable future as everyone catches up and progresses through the experimentation maturity curve. Those who are considering deeper level experimentation will soon start to adopt a mix of both client-side and server-side testing to achieve their goals. Vendors such as Optimizely and Adobe are worthwhile considerations should you be looking at venturing into the world of server-side testing – which I certainly advocate you doing!
