Change but verify: the role of web analytics in interface design

Not so long ago, I attended one event where local Internet businessmen shared their experiences and concerns about their projects on the Internet.

And it so happened that the highlight of the program was a certain guy, let's call him Semyon, who introduced himself as the manager of an online toy store with daily attendance of more than 17,000 people. And that was the truth.

Semyon held one of the most important posts in this project and could influence many aspects of the business. The question he addressed to the audience was something like this: “Friends, we have a rather successful online toy store, but I don’t like its design. For example, this thing, or this one. "I would like to hear your opinion that we can change or improve?"

The audience was not long in coming and immediately began to spew out a variety of ideas, suggest the development of functionality or the rejection of something.

The only problem is that nobody was interested, but what is happening with this store now, what is its conversion? Semyon answered this question somewhat vaguely. He thought or rather guessed about the conversion of 2% in what I could hardly believe.

With a number of precise questions, I managed to bring Semyon to the idea that, like this, with your finger in the sky, either changing or improving at least would not be useful, or maybe even harm.

The meaning of this story is that the vast majority of current large and small Internet business owners do absolutely the same.

What are the problems of Seeds?


Semyon believed that his personal views and tastes completely and fully correspond to the expectations of the audience. Therefore, all changes were carried out randomly on the principle of "but it would not be bad."

The problem with this approach is to create a universal interface for everyone and everyone, and therefore for no one. As a result, the site either does not sell at all or sells poorly. And since almost all sites sell poorly, a magic conversion rate of 1% -2% is considered quite normal. And what happens to the remaining 98-99% of visitors, why did they leave?

Oddly enough, web analytics gives the answer to this question and to Semen's problems. Recently, every beginner and experienced businessman understands the need to install Google Analytics, but its use, unfortunately, is often limited only to viewing the amount of traffic and may still have some trivial data.

In the right hands, the information from Google Analytics can answer many questions, in particular, point out bottlenecks in the interface that really require changes.

What to track?


After installing the Google Analitycs code, you can immediately track quite a lot of data, but for a full picture you need to do some more work.

Set up event tracking

Events allow you to track points of interaction with the interface. For example, on your product page there are three Buy buttons. To find out which of them brings the maximum effect, and which is generally not effective, it is enough to assign an event identifier for each of them. For example, like this:

> Buy

Where:
  • BuyButtons - a group that will combine your events (the name can be arbitrary)
  • BuyMain - event identifier, i.e. which button was pressed (the name can be arbitrary)
  • Product Name - product name for more accurate analytics.

Thus, when you click on any of the buttons, we will know exactly which of them works.

Later, in Google Analitycs reports, the information collected can be seen in the report: “Reports / Behavior / Events / Overview”.

The value of events in the context of interface design lies in the ability to track the effectiveness of all interactive interface elements. And based on usage data, the hypothesis of necessary changes is already worth it.

Set goals

If event setting can still be neglected, then goal tracking should be set up immediately after installing Google Analitycs code. For the effectiveness of achieving goals is the most important characteristic of the site.

There can be many goals, but it is important to know the measure and not create stupid goals, such as the length of time spent, the number of pages viewed or the visit to the Payment and Delivery page.

For example, for an online store, the logical goals are to visit the “Cart” page, each page of the checkout process, and the final “Thank You Page”. In addition, you can also set goals for other lead generating elements: product question form, call back, etc.

Unlike events, goals are configured through the Google Analitycs interface: “Admin / Goals / Create Goal”

When creating a goal, you can also specify the sequence of visits to previous pages, for example, the checkout process. Then in the report "Reports / Conversions / Goals / Visual Sequence" you can see such a wonderful sales funnel:


In my example, the funnel consists of only two pages.

Having information about the goals, you can pretty accurately see where in the sales process you are having problems, whether it’s a product card, basket, the checkout process, or whatever else “with one right stroke” improve sales on your site.

Set up ecommerce

If your site is an online store, the need to enable and configure e-commerce is just as important as setting goals.

The difference between goals and e-commerce is that the goals indicate the fact of the purchase, while the trade says what they bought.

In terms of interface design, e-commerce reports provide such useful information about the audience as the average bill, time to purchase, the quantity of goods in the order and can serve as excellent control points for tracking the effectiveness of implemented changes.

I did everything, what's next?


Now that you have your events set up, goals and e-commerce you can approach the construction of hypotheses about the need for certain changes.

Looking through reports, you can clearly notice such anomalies as intermittent conversions on the way to the final goal or understand that some functional and very beautiful block does not work, since it does not generate any events.

Based on the identified problems, you can quite safely remove unnecessary, non-working elements, reducing redundant functionality and making your users' lives a little better. Or pay close attention to the page where a large percentage of interruptions occur and you will surely find a reason that will immediately affect the increase in conversion.

Nevertheless, despite the apparent simplicity, it is recommended to make any changes to an existing project through split testing. Thus, firstly, you can protect yourself from incorrect changes, and secondly, you can accurately assess the effectiveness of the implemented changes.

A / B - testing


A / B testing allows you to check the effectiveness of several page variations. For example, you decided to test the hypothesis that increasing the size of the Buy button and its color by bright, contrasting can increase the likelihood of it clicking.

To do this, you need to create a copy of the page with the implemented changes and available, for example, using the? Split? GET parameter.

That is, if the user opens the page: _http: // site / category / product - he sees the old content, and at _http: // site / category / product? Split the page opens with a large and bright button.

Now, using the tool “Reports / Behavior / Experiments / Create an experiment” you can very quickly launch your experiment and test the hypothesis.

The mechanism of the A / B test consists in randomly showing one of the tested options to the selected audience and measuring the effectiveness of achieving the goal chosen for the experiment.

Here is one of the reports:


In general, I recommend checking absolutely all the changes made, whether it is the introduction of a completely new page design or a change in the text of the product description. But best of all, A / B tests work on small changes, since in the case of a change in the entire page, it will be difficult to understand what exactly affects the result.

Epilogue


Returning to the story with Semyon, it now becomes clear why his attempts at blind change could turn into a real failure of the whole business.

Any change in an already working project should have a basis from analytical data and be checked using tests. This is especially important for highly visited projects with a mature audience core, as is the case with Semyon. After all, no matter how wonderful and perfect the interface would be implemented on his site, most of the audience would still be terribly unhappy, because habits have already been formed, and point improvement would be perceived much better. Remember at least iOS7.

PS The material describes the principles of working with the classic Google Analitycs, but it is already being replaced by Universal Analitycs, where the method of recording events is somewhat different.

PPS If the material seemed interesting to you, write in the comments about what you would like to know more - I will gladly share my practical experience in interface design.

Also popular now: