One of the most frequent questions that our Webtrends consultants get asked by business users is “can I have complete faith in the accuracy of my web analytics data?” This desire for accurate data is understandable, as the insight gleaned from Webtrends reports often underpins the decision making process within large organisations. If you delve deep enough, you can usually find problems with most Webtrends implementations – mis-configuration of the standard options and custom reports often prove to be the most common culprits of inaccurate data.
Detailed below are some of the basic checks we regularly carry out:
Base tag setup
The Webtrends base tag is the single most important part of your analytics setup – it allows you to capture vast amounts of data from the user’s visit which will then be passed through to your reports. Therefore, any issues in this area will transcend through and have an impact on the data you see in the reports.
Common problems include:
- Tag version – the latest base tag is currently v9.4.0, however many websites are still using out-dated versions. It’s always a good idea to ensure that the webtrends.js file is kept up-to-date – this is quick and easy to do using the Tag Builder tool (https://tagbuilder.webtrends.com/)
Visitor tracking validation
The primary method of tracking visitors within Webtrends is by using first party cookies. Initially, it’s important to check that the cookie is being set on the site – as seen in the below screenshot, the name of the cookie is ‘WT_FPC’:
However, the presence of the cookie on the website alone does not necessarily mean that visitors are being tracked using this method. It is also necessary to ensure that each profile is correctly configured to track sessions using cookies.
As a further check, and to provide peace of mind, the ‘New vs. Returning Visitors’ report in Webtrends details the percentages of users who are rejecting cookies. We would typically expect to see rejection rates in the region of 3-4%, so further investigation was required in the example below:
Webtrends stores data in tables – each report or profile has their own designated table, each with its own predefined size. To prevent reports from becoming too large, and thus consuming more memory during analysis, Webtrends limit the size of these tables.
Table limits are commonly reached in the ‘pages’ report, where you may potentially see something like the below:
In this example, there were 15,369 visits to pages which ‘didn’t make the cut’ and were omitted from the report by the table limits.
To double check this, you can view the table limit status of reports from within each profile. The red status in the screenshot below indicates that the limit has been reached, and that new pages will only be shown in the report if they reach a certain popularity (i.e more visits than the previous least popular page in the report):
Table limiting issues are the root cause of questions such as “I’ve added a new page to my website, it’s tagged, but I can’t see any statistics on it in Webtrends.”
Whilst software/on-premise customers are able to manage their own table limits, and can increase them as necessary, On Demand customers will need to contact Webtrends technical support in order to request a table limit increase.
Filtering and traffic exclusion
Another common question is along the lines of “my backend system reports 3,000 sales, whilst Webtrends only reports 2,500.” While there will always be a certain margin of discrepancy between different reporting systems, this can be minimised by carrying our several key configuration procedures in Webtrends.
I often find that one of the main causes of mismatched data is the fact that people are not comparing like-for-like. For instance, the backend system mentioned above may be excluding internal traffic, and data from the beta/development environment.
In order to ensure that data is as accurate as possible, the following are always recommended:
- Profile level filter to exclude internal traffic
- Profile level filter to exclude spiders and bots
- Profile level filter to exclude development/beta environments
Language / locale / currency settings
At first glance, you may think that the below screenshot is trivial, and that a UK user should not be too worried if their language/locale settings are set to US.
However, if you then consider the below screenshot, you will see the massive impact that such a small configuration error can cause. Webtrends now thinks that the home country of the website is the US (in actual fact it was the UK) and therefore reports all visits from the UK as being international.
The checks listed above are just a few of the most basic and routine checks which we initially carry out, but are a good starting point and can have a huge impact on the accuracy of your data. More advanced health check components such as custom report audits and custom tag/dcsMultiTrack validation is dependent on the specific needs of the client, and is difficult to discuss here. If you would like to arrange a Webtrends healthcheck, contact one of our experienced Webtrends consultants for more information.