Authenticated UserID vs. Unique Visitor
Many applications require end-users to login in order to access there content. As such, we decided to pass the Authenticated UserID, e.g. aberlinger, of each visitor via sProp1 in Omniture. EVERY (yes every) user must login to access these sites. We started to notice a significant difference between unique visitors and authenticated userID's. Check out the stats below for March 2007:
- 30,710 unique visitors
- 19,708 authenticated userID's
How is this possible? What are the reasons driving the discrepancies in the data? We first need to understand how our analytics solution determines unique visitors as each package has its own proprietary method to calculate unique visitors:
SiteCatalyst determines unique visitor information using several technologies. The primary method of calculating unique visitors is by setting a persistent cookie on the visitor’s browser to uniquely identify the visitor. Cookie technology helps to avoid common pitfalls, for example, IP Pooling, caching, or tracking visitors behind a firewall, when counting unique visitors. If the visitor has disabled cookies on their browser, or if the visitor’s browser does not support persistent cookies, Omniture uses a combination of the IP address and the user agent string to determine if a visitor is unique or not. SiteCatalyst reports a small percentage (usually 1-2%) of visitors who do not support cookies.
Did you notice "cookies" in Omniture's definition above? Perhaps we should research cookies and their impact on analytics data. ComScore and many industry experts have found that cookie deletion can be as high as 40%! Have I totally ruined your day? Are you questioning the sanctity of your reports, especially the ones that end up on your CEO's desk? Wait, it gets worse. I ran some reports which illustrated users logging into our sites from multiple machines, IP addresses and with different browsers, yikes!!! Not to worry, there is a solution!
What we did was implement what Omniture refers to as "Visitor Optimization" where Omniture's proprietary/cookie-dependent visitor ID is replaced with our unique authenticated UserID. Once a visitor logs into the site, their authenticated userID gets recorded as a unique visitor. This takes IP addresses, cookies, and user-agent strings out of the equation, woo-hoo! The trick is to make sure that the authenticated UserID's are passed to each page viewed by each visitor. Guess what? It's working! The numbers match!
Ask your analytics vendor if they can implement the same type of solution. However, the fact that your tool might indicate that your site attracted 1,000,000 visitors when it was actually 750,000 should not matter. Why? Because the percentages of your KPI's will not change. Remember, KPI's are a ratio of visitors to success events/conversion rates over a period of time. In other words, if 3% of your visitors purchase a product, generate a lead or apply for a job...the 3% is what you should be focused on improving in context of the total visitors. While 3% of 750,000 is obviously less than 3% of 1,000,000...the patterns you notice on your site remain the same. I hope this helps, Adam.
3 comments:
What do you think would be the pros/cons of setting this up on a site where only some sections of the site require login?
Can you do this if only parts of the site require login?
Great post, thanks.
Lisa
Lisa,
Great question! Rather than diving into the pros/cons of a "blanket solution," let's discuss a more tactical approach. I recommend setting up a separate report suite or ASI Slot (if you're using Omniture, profiles if WebTrends, etc.) that is filtered on only the sections of your site where users have to login. While I'm all for maintaining a "rollup" report, segmenting your reports will eliminate data inflation. Thanks for your question.
Adam,
Congratulation on making the variance go away. Will try and get this done on our Intranet.
Cheers
Aman
Post a Comment