When a website’s content or pages change during the course of its evolution, its analytics tags could get inadvertently impacted. And when that happens, the integrity of the site’s web analytics comes into question. A typical ecommerce site has anywhere from three to five data feeds going into its analytics tool. These feeds include website performance data, marketing channel data, and transactional data. Sometimes, the break in data occurs not on the site itself but in the data feeds providing ancillary information. A web analytics audit identifies areas (internal and external) to the site that could be impacting web analytics and provides recommendations on fixing the same. Best practices in web analytics audit span several areas such as knowing what to look for, capturing the data, and recording it. Let’s take a detailed look at each of these areas.
How to capture data for analytics audits?Website data can be captured at three points – at the source code, as network traffic, or within the analytics tool itself.
Tracking data within the analytics toolThis approach requires executing carefully selected actions and then tracking them in web analytics. For example, an action could be to test add to cart functionality. You will need to note a uniquely identifiable attribute about the session that can then be used to isolate the data in web analytics. Some commonly used attributes are session ID and IP address. These can be used in Adobe Analytics. However, because Google Analytics prohibits storage of Personally Identifiable Information, neither of these variables are readily available. For ideas on how to execute a Google Analytics audit, see our Google Analytics audit page (TBA) on the same topic. The advantage of this approach is that there is nothing left to chance. You are no longer assuming that just because a tag fired, the data was sent and stored in the web analytics servers. You will view actual data through the web analytics system. To make the most use of this approach, the actions to be taken need to be carefully documented and then followed. Else, the entire exercise can easily become confusing and overwhelming. Here is an example of an audit that follows this approach: So what’s the downside to this approach? What if you are looking to track session or even user-level events? For example, if you want to track when a person logs into the site, then you are better off using the network traffic approach because it is not possible to determine when session level value was set by looking at analytics data.
When should an analytics audit be run?This is an interesting question. It is kind of like asking the doctor “When should I do a health checkup?” Your doctor might say, “Once a year” or “Every 3 months,” depending on your health. Similarly, the answer is regularly or frequently depending on the health and frequency of changes on the site. If your site is relatively static with only content being added or changed, then maybe you need a web analytics audit once a year. On the other hand, if your website is a core part of your revenue generation process either as an ecommerce site or a lead generation site, then you want to ensure that the site is optimized for transactions, lead generation, etc. In such cases, you should require an analytics audit every time there is a change to the site’s functionality. The reactive approach to web analytics auditing is to audit when there are sudden and unexplained changes in metrics. By unexplained, we mean that there are no internal or external actions that coincide with the change in metrics.
What should be the scope of a web analytics audit?If your web analytics auditing exercise is a manual effort, you may want to pick and choose pages that are representative of the site. For example, category, search results, or product detail pages may each be based off their unique templates. So auditing just one of each type of pages could be enough to get a feel for the integrity of analytics tagging. So audit all the pages that are unique or are representative of the site as a whole On the other hand, if you use an automated web analytics auditing tool, then the sky is the limit. There is no reason to not run all site pages through an audit regularly.
What tags should one look for?The obvious answer here is pageview tags. That’s the most common type of tag, isn’t it? True. But there’s a lot more to it. You are looking for everything that the analytics tool has been configured to track. That might include event tags when for internal searches or custom dimensions being set when a user logs into the site, etc. Here are a few commonly tracked activities you may want to consider adding to your audit:
- Catalog searches
- Use of sort and filter functionality
- Product detail views
- User signups
- User signins
- Form submissions
- Add to cart
- Alternate payments types such as Paypal and loyalty points
Being SelectiveSelecting technology platforms (e.g. Windows, iOS, or Android) and browsers to audit is a big decision. Browsers don’t all behave the same. And it is not uncommon to find one browser not firing tags when another browser fires them just fine. In an ideal world you will want to audit every single platform and browser, but that is highly impractical. Every browser and platform combination doubles the number of use cases to be audited. So be careful about the platforms you choose when auditing. The best way to narrow this down is by determining the platform and browser mix for majority of your website’s traffic. Here’s a Google Analytics report that can help you find the most popular OS and browser pair quickly.
Credit Cards for QAWhen auditing, you will want to go all the way to completing a transaction. This is particularly important when the transaction processing happens on another system such as PayPal. So your options are to either hook up to a test partition of the credit card processor or to use real live credit cards. The problem with using the first approach is that you will be relegated to connecting from a test or staging site on your side and you won’t actually be auditing web analytics in production. The problem with the second approach of course is that you might be racking up a huge amount of money onto your personal credit card. Check with your development and QA team, as they might have an internal card that doesn’t actually hit the credit card processor but simulates it. For your purposes, that is a pretty good compromise because the transactional data will flow into web analytics without a purchase actually happening.
Email for RegistrationsOther issues with web analytics auditing include using multiple email addresses for creating profiles. There are a couple of options here for you. First, check with your organization whether they allow pseudo emails. In my experience, using a third party such as Gmail is easier and without the red tape that you would find in a typical organization. The good thing about Gmail addresses is that you can apply a Gmail alias to an existing address and get notifications there. There is another scenario you might run into where your ecommerce system may not recognize or allow special characters such as ‘+’ in the email address. So a Gmail alias approach may not work. In this case, look into getting an external email from an email hosting provider such as GoDaddy or Rackspace. Once you have an email address setup, you can create unlimited aliases to it.
Auditing Marketing ChannelsAuditing marketing channel tags is trickier. Content, ads, and campaigns used in marketing are not static. So you will need to cast a pretty wide net for auditing web analytics for marketing channels. Here are your options – First, you could go to the source and ask your marketing managers to provide you with the spreadsheets they use for tracking campaigns and such. The problem with this approach is that you are auditing the source and not the result in web analytics. Another approach is to analyze traffic from known marketing channel referrers such as Twitter, Google, and Facebook. This right to left approach is better because you are then able to see the campaign names and other important attributes in use and make recommendations on use and naming conventions.
SummaryWeb analytics auditing can get pretty involved. Make sure you have a playbook ready before you dive in. Planning plays a very key role in determining whether you can scale and repeat your web analytics audits. Here are some best practices for creating the web analytics audit playbook:
- Name each test case using a date, release name, or other scalable naming convention
- Use a unique session id or user agent to conduct each test case
- Document the steps taken in each test case including the specific pages visited
- Store the results in an easy to read format