Recently, I participated in a great little conversation on Twitter regarding how to handle a very specific reporting need. A user asked how he could tie individual user IDs on his site back to data from the user’s first visit. For example, this user needs to see the original entry page for various users. This seems fairly straightforward on the surface of it, but when you take into account the effects of clearing cookies, changing browsers, changing machines, etc., it can become much harder.

Typically, we would treat these uncontrollable phenomena that affect unique visitor tracking a fact of life in the web analytics game. Matt Belkin has blogged about this extensively right here on Omniture.com. The method I am about to suggest is definitely not for everyone and should only be considered where a system is in place to assign unique IDs to individual visitors in a reliable manner. By this, I mean that the unique ID must be assignable to a user on every single request that the user generates, without exception. It’s an awesome solution in the right environment—intranets, webmail apps, desktop apps, etc.—where you have a way to identify the user on every page view. If there are “‘logged out” page views, though, please proceed with extreme caution.

I should note that it’s also great for sites that, for whatever reason, do not want Omniture to set a cookie. This doesn’t necessarily get around cookie deletion and other similar limitations of visit/visitor measurement, but setting s.visitorID will prevent new s_vi (visitor ID) cookies from being set on users’ computers. Thus, the variable allows you to set your own visitor ID cookie and pass its value into SiteCatalyst.

(Admittedly, what I describe below doesn’t completely address the need of the user who originally asked me about it. I think it’s still worth covering, though.)

Beginning with code version H.9, the SiteCatalyst JavaScript code allows you to assign your own visitor ID to users on your site; the Data Insertion API contains this functionality in the form of the <visitorid> element. This means that can marry a visitor ID to each user ID on your site and then pass that visitor ID whenever the given user ID views a page on your site. For example:

user_id visitor_id
bgaines 16278468165
paurigemma 79018759816
jlebaron 67859175781
cknoch 47698185678

Then, whenever a user hits your site, your servers would detect the user ID (e.g., bgaines), and look up the appropriate visitor ID from the table (16278468165) and place this into the s.visitorID variable:

s.pageName="Intranet Home Page"
s.visitorID="16278468165"
s.channel="Home"
...

This is actually pretty cool. Cookies are a good method for associating visit/visitor behavior (as described in a previous post), but if you can assign out your own visitor ID values, you aren’t bound by cookie deletion or any of the other limiting factors mentioned above. When a user logs in, you can track him/her as a unique visitor regardless of browser/computer/cookie status. (Yes, this also means you can track visits for users who do not accept persistent cookies. Huzzah.)

A few warnings straight out of our Knowledge Base:

  • As described above, you must be able to set the s.visitorID variable on every page of the visit. If you cannot do this, then the s.visitorID implementation is not for you.
  • Similarly, if set, the s.visitorID value for a visitor should not change (in other words, if I can navigate your site anonymously and then sign in, only then allowing you to know who I am, make sure that this does not cause the visitor ID to change). If this cannot be reliably achieved, we recommend against this implementation strategy.
  • Any existing Omniture-set visitorID (stored in the s_vi cookie) will be migrated to the new s.visitorID value one time without cliffing the visitor (counting the visitor twice and inflating visitor counts.
  • We recommend pushing the update at the time of least traffic to the site. When the update is pushed, any active visits will end causing an inflation of visit counts for the day. If the update happens when traffic is minimal, you reduce the effect of the spike.

The reason it’s so important to be perfectly consistent in assigning visitor IDs when using this system is that if Omniture code ever does not see an s.visitorID value, it will set an s_vi cookie, and begin to count data for a new visit/visitor. If you then begin to pass an s.visitorID value mid-visit, SiteCatalyst will use that instead, thus counting a new visit where there wasn’t really a new visit. Consider a user who views a “logged out” page and receives an Omniture visitor ID in the s_vi cookie. Then the user logs in, and his username is mapped to the visitor ID pulled from the s_vi cookie. Later, using a different computer, the same user hits another “logged out” page and receives a different visitor ID from Omniture. He then logs in using his former username.

Now you’ve got a problem: Either you change your mapping to reflect the new visitor ID, or you change the visitor ID that you’re using for this user. Either way, you’ve just inflated your visit and visitor counts. If you want to track logged in users across browsers, my recommendation is to just track the logged in pages of your site so that the non-logged in hits won’t inflate visitors. Most sites don’t have enough logged in users for this to be practical, but many do (such as webmail, intranets, on-demand software, etc.).

As described above, implementing a system such as this can allow you to track visitor-based metrics (e.g., Visit Number, Original Referring Domain, etc.) without relying on cookies. This means that, for some types of web applications, a person who last visited your site in 2006 from Sheboygan, Wisconsin, using IE 6 can be identified, three years later, as the same person now logging in from Liverpool, England, using Firefox 3 in 2009.

As always, please feel free to follow me at OmnitureCare on Twitter and/or FriendFeed. I’m also available by e-mail at omniturecare@omniture.com and would love to hear from you via any of these channels!

6 comments
darren
darren

When using s.visitorID in an environment where there are no persistent cookies will pathing reports work?

Samrat
Samrat

A very useful info for intranet implementations as well as e-stores. However, why take the trouble of assigning unique id's when the username itself is unique and measurement is being done on logins than on cookies? Doesn't the s.visitorid take in alphanumeric values? Sam Samrat D'souza

benrobb
benrobb

I've been thinking about this lately and present the following as a work in progress, though not a completed solution. Many web applications require a user to login to in order to access the desired functionality. SiteCatalyst itself is an example of this type of app that you have to login to in order to get the full functionality. Under the assumption that we measure at the level we can optimize and with the further assumption that I'm not interested in streamlining the login experience, it might make sense to have the application go into its own report suite where in order to access the app, a visitor must login (identify themselves) and the approach you've outlined above then works. Now we obviously wouldn't want to throw away the people on the login page, we would want to capture that in a global report suite of some kind, but it does give us a report suite dedicated to the web application, one in which we've accurately identified all our visitors across browsers, computers, mobile devices, etc. It's visitor identification nirvana.

Ben Gaines
Ben Gaines

Great question, Darren. The answer is yes. When s.visitorID is used consistently (i.e., on every page), SiteCatalyst relies on that value instead of the s_vi cookie value to tie page views together into a visitor path. Thus, page views from users who don't accept persistent cookies can still be organized into paths when using this variable.

Ben Gaines
Ben Gaines

You bring up a good point. You could, of course, use any unique identifier, including the user ID. I presented the information the way I did for one reason: it shows that you can add an extra layer of obfuscation if necessary; I would imagine that some organizations are not comfortable with the idea of passing the actual user ID into SiteCatalyst.

Ben Gaines
Ben Gaines

Ben: Great point. The multi-suite approach crossed my mind as I was researching the post, but I didn't get a chance to think it through completely. Thanks for supplementing my research with a really valuable suggestion!