You and I have heard so much about best practices that should be followed when embarking on the Web Analytics journey, but most of them are just… not very useful? We have vendors telling us to make use of event-based tags, just because marketers can start tracking their KPIs without involving the IT teams. Sadly, that’s not practical at all. In many cases, vendors come up with these “best practices” to reinforce the product’s USP (Unique Selling Point). I don’t blame them, as the “best practices” are helpful for the sales team to secure new businesses. Other than that, those “best practices” are best forgotten. Today, we will cover 5 Web Analytics best practices that you might have overlooked. This is by no mean an exhaustive list. For more best practices, we have a few other articles that would definitely pique your interest. There will be made available at the end of this article.

1. Tag all pages

Make sure that all the pages are tagged. For most websites, this should be very straightforward. Just include the code snippet provided by your Web Analytics tool in the header and footer of every page. This should allow you to capture some basic data to kickstart your Web Analytics journey. There are many tools out there that would help you check if all of your pages are tagged, so do your research and pick the one that best suits your needs.

2. Give each page an unique name

This is one of the most often overlooked practices, yet one of the most important ones. Without giving each page an unique name, we are essentially storing raw URLs which are less than useful for reporting purposes. At the very least, we should be breaking down the URL into different sub-sections and store them as individual pieces of data. This will be useful when generating reports to understand which parts of the website are more popular, etc. Taking one step further, we can further define data such as page category (E.g. personal, commercial, loan, credit card), page type (E.g. static content, dynamic content, application form, lead gen) , etc. All these will provide us with more information and means to slice & dice the data when it comes to reporting.

3. Deal with multiple links on a page that points to the same destination

There are cases where we have multiple links/buttons on a same page that does exactly the same thing. Multiple links pointing to the same destination, multiple buttons serving the same purpose.

Example

3 buttons on the same page that do exactly the same thing – get customers to buy our product. We want to be able to identify which button customers favor most when they have the intent to make a purchase. Maybe the top button wins, because most customers already have the intent to buy without reading the rest of the page. Maybe the middle button wins, because customers are impressed by what they have read so far. Maybe the bottom button wins, because it is the natural thing to do to find the purchase button, which is to scroll all the way down. Regardless, without giving each an unique identifier, it is impossible to tell which button actually helped to secure more customer purchase intents.

Recommendation

One simple solution is to add a parameter to the destination URL, making each link unique. For example, we can have:

1. https://pleasebuymenow.com/products/analytics?lid=btn_top
2. https://pleasebuymenow.com/products/analytics?lid=btn_mid
3. https://pleasebuymenow.com/products/analytics?lid=btn_btm

If we have 2 buttons and 2 links pointing to the same destination:

1. https://pleasebuymenow.com/products/analytics?lid=btn_top
2. https://pleasebuymenow.com/products/analytics?lid=btn_btm
3. https://pleasebuymenow.com/products/analytics?lid=lnk_top
4. https://pleasebuymenow.com/products/analytics?lid=lnk_right

Get what I mean now? With the parameter lid, we are now able to identify whether the customers came to the purchase page through a button or a link, and which button/link did they click on. Work with your developers on implementing the URL parameter, and life would be much better for everyone.

4. Remove unnecessary redirects

It is often easy to overlook tagging on redirect pages, and that can be costly.

Example

Imagine the following customer journey: Facebook > Page A (redirect) > Page B Customers coming through Facebook were expecting to land on Page B, but instead, they were sent to Page A first and then redirected to Page B. From a Web Analytics point of view, the referrer for Page B is no longer Facebook, but is instead Page A. Due to this redirect, we lost the precious information of where are our customers coming from. Now imagine the following customer journey: Page X > Page Y (redirect) > Page Z Things just gotten worse… as Page Y was not tagged, there might even be cases where your Web Analytics tool assumes that you exited from Page X and then started a new session on Page Z. Recommendation Remove all unnecessary redirects. If a redirect is absolutely required, ensure that the redirect page is tagged accordingly and configure your Web Analytics tool to treat all redirect pages as internal pages. In addition, you can also include a parameter (e.g. cid) in the redirect URL to capture the redirect as a campaign so that you can pass the previous page information on to the next page.

5. Ensure data accuracy and completeness

If you have been following my blog, you would know, bad data is the WORST. Reason being, bad data can lead you down the wrong path of coming up with wrong insights, leading to terrible recommendations. You might as well not have data. It is advisable to plan ahead of time (way before implementation) to define all the data you need.

Data accuracy

There’s a multi-step form that we would like to gain insights into. One of the data we want to look at is, how many users proceed on to step 2 of the form? How should we capture that piece of data? There are a couple of ways:

1. Track the click of the “Next” button on step 1 that brings us to step 2
2. Track the load of step 2 section

Simplistically speaking, both represents the same data. But what if there was… form validation? When the email is left blank, instead of proceeding on to step 2, the form would throw an alert. If that is the case, click of “Next” button no longer represents how many users proceed on to step 2 of the form. It represents how many users have the intent to proceed on to step 2 of the form. Load of step 2 section will then accurately represent how many users successfully proceed on to step 2 of the form.

Data Completeness

As for data completeness, just make sure that all the tags are firing as per expected and everything that should be tagged are tagged. Simple.

Conclusion…

As mentioned earlier, these are just some of the many best practices you can have for a Web Analytics implementation. Web Analytics is highly complex as it involves dealing with one of the most complex thing on Earth – World Wide Web. And as promised, we have a few more articles that will definitely help you improve your Web Analytics implementation.

How SDR improve web analytics data governance

Characteristics of Good Data

Data Layer for Web Analytics

That’s all folks!