Getting Started With SiteAudit™
Our Goal
At ObservePoint our goal is to enable web analysts, marketers and business to trust their web analytics data. Our SiteAudit solution requires no installation and is flexible enough to integrate with nearly all deliverables and auditing requirements your company may have.
The goal of this getting started guide is to help you trust you data by ensuring data accuracy, integrity and consistency.
Phase One: Is it Tagged?
First Priority
The primary goal web analytics auditing is to verify that every page has the correct tagging in place, if not, data accuracy is in question.
Before running a full audit on any domain we recommend performing a small initial audit of 100-500 pages to be sure the correct kinds of pages are being audited. If your site has a user sitemap this could be a good place to start the sample audit.
Important questions to ask at this phase are:
- Is every page tagged?
- Which tags should be on every page?
- Which pages have duplicate tags?
- Are there old vendor tags that should not be on every page?
Missing, duplicate and antiquated tags introduce data accuracy, integrity and consistency questions into your analysis. As a base line it is critical to ensure that each page on your website is tagged correctly.
TIP: SiteAudit Naming Conventions
One challenge we see many of our clients face is audit organization. We recommend a simple, yet detailed naming convention. Using something similar to the following may be helpful:
- WEEKLY:BLOG:domain.com
- MONTHLY:SITEWIDE:domain.com
- QA:SITEWIDE:domain.com
- QA:BLOG:sub.domain.com
- INITIAL:BLOG:domain.com
Phase Two: How and When do I audit?
To ensure data quality, you must be involved in each step of the marketing process to ensure data quality.
Pre- and post-production audits will illuminate any data collection issues before they become a problem.
Recurring Audits
During normal, everyday website maintenance and updates web pages can become inadvertently mistagged, or even broken. It is important that frequent and systematic audits be performed.
We recommend recurring audits of the entire web site as often as possible depending on the frequency of web site changes being made. Managing audits for a large web site should be carefully planned out so that manageable data sets can be analyzed. Examples of smaller data sets could include: subdomains, site sections or key content.
SiteAudit needs to be a part of your development and QA processes so you can be confident that every page is tagged and that all irrelevant tags have been removed.
Using the SiteAudit search tool will help identify duplicate tagging issues, uniformity of tag positions and outdated tag versions.
TIP: Auditing Behind a Firewall
Allow our user agent string: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0;) http://my.observepoint.com/bot.html
Phase three: Standardization, Is my data consistent?
Only after every page is tagged and redundant or irrelevant tags have been removed we recommend using SiteAudit to increase standardization. From your implementation design documents, you can enter details of your implementation design as a SiteAudit rule. When a tag is found to be out of compliance with the rule, SiteAudit alerts you. Vendor tags are always checked against their own standard implementation recommendations, and SiteAudit will alert you about faulty tags.
Many of the insights you'll find in SiteAudit will be from using the report search tool. Think of the search tool like you would a pivot table in Excel. You have a data set that consists of all of the pages you've audited and now you're looking for some insights like missing tags, broken links / pages or custom variables with missing or incorrect values.
You can access the search tool from the Audit menu, then select any of the clickable links in the Domain Summary. The search tool consists of a set of filters and a report presented in a row, column format. As you create filters, new data will be displayed in the report. You can save your most useful filters.
TIP: Using SiteAudit Rules
Prerequisites serve to focus where a rule should be applied, what kinds of pages should be checked against a given rule. The requirements section is for the actual elements from your implementation requirements.
