Web analytics is, as you might expect, about gathering data and analysing it. It, therefore, follows a predictable journey dictated by the place of the website within the business..
Justification=>usability=>analysis=>segmentation=>personalisation=>individualisation (or true personalisation)
When a business first gets a website it is necessary to justify its existence. At this stage the credibility of the figures matters far more than the utility. It is a game of large numbers.

Next comes the search for the best possible web site. This, if people do it, provides the most obvious Roi of all the steps along this journey. As there is no such thing as the best possible site this leads naturally on to analysis.

Analysis can go either of two ways:
• Analysis of the site
• Analysis of the users (+)
Either can produce benefits but it is probably best to do both.

Segmentation can be thought of as further analysis but in fact, if done right it is analysis with a purpose. If it is a loyalty segmentation the purpose might be to get people to migrate between segments. If it is a demographic segmentation the purpose might be to inform media buying. The key point is that analysis is about understanding (preferably as actionable insight) while segmentation is about creating a pre-defined change.

Personalisation is about creating the best possible website for each segment of your customers and then delivering it to them. In essence it combines your segmentation work with an understanding of the available information when the decision of what to serve is made.

Individualisation is what personalisation aspires to be. It is the art of providing the best possible web experience for them to each user.

Rufus Evison

(+)users not customers. While it would be nice if everyone wh visited the site either was or became a customer real life is not like that.

The single basket.

A website, which shall remain nameless, had a problem. It was not really a single website at all. It was really a set of websites that coexisted under the same domain. Each division of the company had its own website selling its own products from its own database.

There were strict style and branding guidelines. All the pages had the same look and feel. All the searches worked in the same way. All the baskets and checkouts used the same principles and worked the same way. To customers it looked like one website. That is it looked like one website until customers tried to buy across the borders between the sites. A product put in a basket from area A did not show up in a basket from area B. This was fine unless someone wanted something from each area. If you wanted to buy, for example, a fishing rod and a book on fishing, and maybe some wading boots then it all fell apart. The rod went into your basket. The waders went in. The book went in. At the checkout only the book as there so the customer would go back to buy the waders assuming he had made a mistake. When he went to the checkout two pairs of waders were now present (the original ones and the pair put in because they were missing). The only problem was that the book was gone now. After a bit of too-ing and fro-ing the customers would often give up and leave.

Seeing that this was what was happening someone responsible for the overall P&L for the site went to the technical people and asked them to make the site work from a single database so that the customers had a single basket and did not leave in disgust.

This is a classic mistake that stems from talking across a cultural divide. What the business person was saying was ‘do something to stop customer confusion bleeding profits’. What the technical person was hearing was ‘create a merged database to do something’.

Suddenly, without even meaning to, a commercial person is defining the technical solution. While the technical solution he is suggesting is a good one it is also hopelessly impractical to do in the short term. It would be fairly straightforward to create a joint basket page that displays all the baskets at once. It would not be a perfect customer experience but it would be much better and could be done quickly. The solution specified by the commercial person was estimated at two years to complete. It has been between one and two years away for three years so far and I have little hope it will arrive any time soon. As a usability solution the simpler technical answer is a must. The only way it will ever happen is if technical people are encouraged to understand commercial problems and their causes. At the same time commercial people need to understand technical limitations. Only then can a reasonable solution be agreed by stakeholders from both camps. This can only be achieved through mutual respect for the abilities across the cultural divide.

Efficiency is important in running any business, particularly in times of austerity and yet often companies waste resources by using manual labour where it is not needed. If it is important then why do companies waste time energy and precious reources by devoting paid staff to things that could be automated? It is almost as if they want to waste money. In fact it is quite the opposite; they are using a proven tactic to save money.

At any point automation requires an investment and automating something that will not justify the cost of automation is clearly a waste of money. For any given time something is done the cost of automating is going to be greater than just doing it. The ‘Just do it’ tactic saves money in the short term and loses it in the longer term.

So what are the factors to be considered when deciding whether to automate? What is the point at which they should be considered, and what is a good default position that can act as Standard Operating Procedure?

Deciding whether to automate
The point of automation is to save time and money. To decide whether this is worth while you need:

• A clear view of the amount automation will cost. This should include time, money, and the effects of lack of focus due to thinking about the automation.
• Understanding of what will be saved once the automation is complete.
  To determine this requires two things:

  1. How much the manual process costs
  2. What the running costs of the automated version will be.

The impact of delays due to automation should also be considered but only in the context of whether they are crucial. That is to said it is always easy to think that automation is impractical right now because of the requirement to get this (whatever this happens to be) out of the door. Because this is always easy to say a company can end up never automating anything. Clearly if the process were automated future versions would get out the door much more easily so do not let a one time thing put your company off forever.

Item 2 above is a difficult one as if the automation turns out to be unreliable it can waste a lot of time and effort. If it is not clearly simple to automate then some time must be spent understanding what the issues could be. This can mitigate in both directions. If it is a complex process it can be hard to automate and potentially unreliable. If it is a complex process it can be hard to do robustly in a manual fashion and human error can promote large costs.

When to decide
There are a variety of approaches to when the decision ought to be made and I tend to side with more than one of them. One approach is to have a regular sweep of processes and decide what needs automating based on how often it is being done. This works well for medium size companies who have a fair amount going on but do not really have someone with enough information to step back and spot what should be next in line to be streamlined. Another approach is to have someone who has that as their full time job. This is very efficient but is really only an option for largish companies as carrying someone to do just that is not so easy in a smaller firm.

Yet another approach is the ongoing process approach which can be implemented as standard operating procedure across the company. It will not replace either of the two previous methods as some things will always be missed, but is a good philosophy for minimizing the waste of people on boring jobs. It has the advantage of putting the power to make a job more interesting in the hands of the people who have to do the job. If you have a good workforce I recommend it. If you do not have a good work force then I recommend getting one or changing your company.

There are many other ways to approach this problem but here is one final approach before I put forward the SOP. A new company is probably small enough that instead of a full time role managing automation is a potential part time role for the CEO. If the company is small enough she ought to know everything that everyone is doing and so be able to step in and say “time to automate that”. Again, this is not a replacement for a standard operating procedure but is a way to introduce and SOP in the first place.

Standard Operating Procedure
1. Just do it
2. Do it and understand how you would automate it
3. Automate it and then let the automated process do it

A final thought
Clearly there is no hard and fast rule about what is and is not worth automating, so it is useful to step back at the end of step two and discuss the task with someone. If the company is large enough then the obvious person is the person automating’s immediate superior. If it is too small for that then it may be the person automating themself or any available co-worker who is to hand. In any case it is worth checking that the automated version will be significantly less work than the manual version before moving to step three.

Rufus Evison