Measuring “logged in” visitors without cookies

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"
s.visitorID="16278468165"
s.channel="Home"
...

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!