Recently, I par­tic­i­pated in a great lit­tle con­ver­sa­tion on Twit­ter regard­ing how to han­dle a very spe­cific report­ing need. A user asked how he could tie indi­vid­ual user IDs on his site back to data from the user’s first visit. For exam­ple, this user needs to see the orig­i­nal entry page for var­i­ous users. This seems fairly straight­for­ward on the sur­face of it, but when you take into account the effects of clear­ing cook­ies, chang­ing browsers, chang­ing machines, etc., it can become much harder.

Typ­i­cally, we would treat these uncon­trol­lable phe­nom­ena that affect unique vis­i­tor track­ing a fact of life in the web ana­lyt­ics game. Matt Belkin has blogged about this exten­sively right here on Omni​ture​.com. The method I am about to sug­gest is def­i­nitely not for every­one and should only be con­sid­ered where a sys­tem is in place to assign unique IDs to indi­vid­ual vis­i­tors in a reli­able man­ner. By this, I mean that the unique ID must be assign­a­ble to a user on every sin­gle request that the user gen­er­ates, with­out excep­tion. It’s an awe­some solu­tion in the right environment—intranets, web­mail apps, desk­top apps, etc.—where you have a way to iden­tify the user on every page view. If there are “‘logged out” page views, though, please pro­ceed with extreme caution.

I should note that it’s also great for sites that, for what­ever rea­son, do not want Omni­ture to set a cookie. This doesn’t nec­es­sar­ily get around cookie dele­tion and other sim­i­lar lim­i­ta­tions of visit/visitor mea­sure­ment, but set­ting s.visitorID will pre­vent new s_vi (vis­i­tor ID) cook­ies from being set on users’ com­put­ers. Thus, the vari­able allows you to set your own vis­i­tor ID cookie and pass its value into SiteCatalyst.

(Admit­tedly, what I describe below doesn’t com­pletely address the need of the user who orig­i­nally asked me about it. I think it’s still worth cov­er­ing, though.)

Begin­ning with code ver­sion H.9, the Site­Cat­a­lyst JavaScript code allows you to assign your own vis­i­tor ID to users on your site; the Data Inser­tion API con­tains this func­tion­al­ity in the form of the <vis­i­torid> ele­ment. This means that can marry a vis­i­tor ID to each user ID on your site and then pass that vis­i­tor ID when­ever the given user ID views a page on your site. For example:

user_id visitor_id
bgaines 16278468165
pau­rigemma 79018759816
jle­baron 67859175781
cknoch 47698185678

Then, when­ever a user hits your site, your servers would detect the user ID (e.g., bgaines), and look up the appro­pri­ate vis­i­tor ID from the table (16278468165) and place this into the s.visitorID variable:

s.pageName="Intranet Home Page"

This is actu­ally pretty cool. Cook­ies are a good method for asso­ci­at­ing visit/visitor behav­ior (as described in a pre­vi­ous post), but if you can assign out your own vis­i­tor ID val­ues, you aren’t bound by cookie dele­tion or any of the other lim­it­ing fac­tors men­tioned above. When a user logs in, you can track him/her as a unique vis­i­tor regard­less of browser/computer/cookie sta­tus. (Yes, this also means you can track vis­its for users who do not accept per­sis­tent cook­ies. Huzzah.)

A few warn­ings straight out of our Knowl­edge Base:

  • As described above, you must be able to set the s.visitorID vari­able on every page of the visit. If you can­not do this, then the s.visitorID imple­men­ta­tion is not for you.
  • Sim­i­larly, if set, the s.visitorID value for a vis­i­tor should not change (in other words, if I can nav­i­gate your site anony­mously and then sign in, only then allow­ing you to know who I am, make sure that this does not cause the vis­i­tor ID to change). If this can­not be reli­ably achieved, we rec­om­mend against this imple­men­ta­tion strategy.
  • Any exist­ing Omniture-set vis­i­torID (stored in the s_vi cookie) will be migrated to the new s.visitorID value one time with­out cliff­ing the vis­i­tor (count­ing the vis­i­tor twice and inflat­ing vis­i­tor counts.
  • We rec­om­mend push­ing the update at the time of least traf­fic to the site. When the update is pushed, any active vis­its will end caus­ing an infla­tion of visit counts for the day. If the update hap­pens when traf­fic is min­i­mal, you reduce the effect of the spike.

The rea­son it’s so impor­tant to be per­fectly con­sis­tent in assign­ing vis­i­tor IDs when using this sys­tem is that if Omni­ture 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, Site­Cat­a­lyst will use that instead, thus count­ing a new visit where there wasn’t really a new visit. Con­sider a user who views a “logged out” page and receives an Omni­ture vis­i­tor ID in the s_vi cookie. Then the user logs in, and his user­name is mapped to the vis­i­tor ID pulled from the s_vi cookie. Later, using a dif­fer­ent com­puter, the same user hits another “logged out” page and receives a dif­fer­ent vis­i­tor ID from Omni­ture. He then logs in using his for­mer username.

Now you’ve got a prob­lem: Either you change your map­ping to reflect the new vis­i­tor ID, or you change the vis­i­tor ID that you’re using for this user. Either way, you’ve just inflated your visit and vis­i­tor counts. If you want to track logged in users across browsers, my rec­om­men­da­tion is to just track the logged in pages of your site so that the non-logged in hits won’t inflate vis­i­tors. Most sites don’t have enough logged in users for this to be prac­ti­cal, but many do (such as web­mail, intranets, on-demand soft­ware, etc.).

As described above, imple­ment­ing a sys­tem such as this can allow you to track visitor-based met­rics (e.g., Visit Num­ber, Orig­i­nal Refer­ring Domain, etc.) with­out rely­ing on cook­ies. This means that, for some types of web appli­ca­tions, a per­son who last vis­ited your site in 2006 from She­boy­gan, Wis­con­sin, using IE 6 can be iden­ti­fied, three years later, as the same per­son now log­ging in from Liv­er­pool, Eng­land, using Fire­fox 3 in 2009.

As always, please feel free to fol­low me at Omni­ture­Care on Twit­ter and/or Friend­Feed. I’m also avail­able by e-mail at omniturecare@​omniture.​com and would love to hear from you via any of these channels!


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


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


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!