Under the Hood: Preventative care against visit/visitor inflation
Previously, I’ve discussed how visit and visitor measurement works in SiteCatalyst. However, there are some nuances that I haven’t mentioned, and which can wreak havoc on an otherwise solid implementation. I have seen numerous cases of good development hampered by minor errors which cause visit and visitor inflation, so I’d like to discuss briefly a few ways that you can ensure that you aren’t duplicating these metrics.
Make sure that key configuration variables are always consistent—even across collection methods
This will cause the s_vi cookie to be set on, and read from, the “myawesomesite.com” domain. Now let’s say you begin to implement SiteCatalyst in a Flash application that will live on your site. You download the ActionSource code and component from SiteCatalyst. In your excitement, you forget to implement the two variables discussed above:
Leave that s.visitorNamespace variable alone
This applies primarily to those implementations based on third-party data collection domains. As described briefly above, the data collection domain determines where the visitor ID is set; as such, it must be consistent from page view to page view and from visit to visit. The s.visitorNamespace variable controls the subdomain for data collection. Because it frequently matches or suggests the name of your organization, you may feel tempted to change it when your company’s name changes or when you are introducing a new brand.
These two variables (given the absence of the s.trackingServer and s.trackingServerSecure variables) will cause the data collection domain to be “myawesomesite.112.2o7.net.” Changing the visitorNamespace variable will not prevent data collection, so it’s possible that a change here would go undetected. But since the data collection domain has changed, every visitor will be treated as brand new. This is commonly called “visitor cliffing.” Since every visitor becomes a new visitor, unique visitor metrics will spike; “lifetime” reports, such as Return Frequency, Visit Number, and Original Referring Domain will be “reset.”
So what can you do to detect these problems when they occur (so that you can correct them using the information above)?
1. Always debug using visits and visitors—not just page views
Checking your Pages report and your Custom Traffic reports is important, but they may not always tell the whole story—at least when showing the Page Views metric. A visit may involve a number of page views for a certain line item in a Custom Traffic report, but if the number of visits matches the number of Page Views, you might have a problem with visit and visitor measurement. Also, make sure to compare visits and visitors to previous time periods. Some spikes are natural and good—the result of marketing efforts—but sudden spikes in visits and visitors that correspond to implementation changes made on your web site can be a sign of trouble.
2. Check “lifetime” reports
If you typically see 60% first-time visits, and that number jumps to 90% all of a sudden, it probably isn’t that you’re driving away your loyal customers. Rather, you may be seeing visitor cliffing in action.
3. Use a packet monitor while browsing your site
There are a number of debugging tools that will show you the data collection domain that your SiteCatalyst implementation uses. You can use these tools to detect changes—both against historical data collection, and from image request to image request on your site. For example, Tamper Data for Firefox will show all image requests and will update with new ones as you browse. Simply look at the beginning of each request URL to confirm that the data collection domain is consistent. For bonus credit, you can double-click the “Cookies” details for each request to ensure that the s_vi value is consistent from request to request.
Fortunately, issues involving visit and visitor inflation are rare. These issues probably aren’t affecting your data, but when they do arise, they can be difficult to troubleshoot and can give even the best analysts severe headaches. I don’t want that to happen, so I hope this helps you understand the process that you might follow in validating an implementation against visit and visitor inflation, as well as what you can do if you are seeing strange things in your data.
As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter, FriendFeed, LinkedIn, or by e-mailing omniture care [at] omniture dot com.