Visitor IDs & Visitor Profile

For months now I must have thought that an article about visitor IDs is really overdue. It is the last remaining principle aspect of Adobe Analytics that I have not explained, I think.

Also, in step 6 of my post on processing hits, I mentioned the “Visitor Profile” and didn’t really explain it.

Bad blogger!

visitor ID

When your friendly marketer looks at how she spends her money and what she gets back for it, she likes to analyse actual people rather than Page Views or Visits. It is really important for her to know that someone who came to the site via paid search two weeks ago has now bought that camera or asked for a call from a sales rep.

Looking at those two events together will tell her whether she has spent in the right places, essentially. Her view on your site is therefore heavily biased towards metrics or systems that analyse people rather than hits. Keep that in mind.

You, of course, are a developer. You know that HTTP is stateless and that if you want to remember anything on a web site, you need to store it somewhere. That somewhere might be a session, a cookie or a bunch of other places. Now sessions do usually time out, so that leaves us with cookies, right?

So, does SiteCatalyst Adobe Analytics store everything a visitor does in cookies? No, not really. That would probably break most browsers at some point.

But it does set one very important cookie called “s_vi”.

This cookie contains a tiny bit of meta data plus a visitor ID.

See those “|” in the cookie value? They delimit the visitor ID.

This visitor ID is how Analytics identifies a visitor. It is sent with every hit (of course, it’s a cookie!) and the system picks it up and records it along the rest of the “variables” you send.

Woah, wait! I hear you say, cookies are per browser!

They sure are. Which is why if you use multiple — say 3 — browsers on your machine, for Adobe Analytics you will be multiple — 3 — visitors. And if you also visit the site in question with other devices, say a tablet and a phone, you will be even more visitors — at least 5 by now. This is something all analytics vendors are currently trying to solve.

Whimsical bonus tip: if you copy the s_vi cookie across all of your browsers, you will actually be counted as a single visitor across all of them! Just in case you’d want to.

3^rd-party vs 1^st-party

We all know that most browsers these days are picky and do not set cookies just like that. They usually refuse to write 3^rd-party cookies which means no visitor ID.

Luckily, there are two fallback mechanisms.

1. If your site uses version H.25.3 or later of the core Javascript code, you will also notice a cookie called “s_fid”, which is set via Javascript and therefore always 1^st-party. The system uses the fallback visitor ID in s_fid if it can’t find s_vi.
2. Should you be on older code, or should the browser just flatly refuse to write any cookie, the system will use the HTTP User-Agent field combined with the visitor’s IP address to calculate a visitor ID. Yes, that is a lot less accurate.

A lot of customers do therefore set 1^st-party cookies. I did write about the difference briefly in the article on tracking vanity URLs but I guess I could do more. *scribbles note*

You can find more about visitor identification in the Adobe Analytics Implementation section of the online help, including information about the new “Marketing Cloud Visitor ID Service”, which will allow you to use one visitor ID across the Marketing Cloud. Definitely recommended for fresh installations and a topic I will come back to soon.

You can also provide your very own visitor ID if you want, but for most people and in most cases, this is not recommended. We’ll come back to that as well.

Visitor Profile

At this point, you can understand how “persistence” works for eVars, right? Whatever value is passed into the system, the back-end stores it according to the settings of the eVar. Over time, there will be a lot of data associated with any given visitor ID.

This is what we call the “Visitor Profile”.

Note that the Visitor Profile stores values on two levels, really: visitor level and visit level. The former persists forever (as long as your cookie lives), the latter expires when the visit does.

There are two built-in reports that illustrate this:

The “Referring Domains” & “Original Referring Domains” reports under “Traffic Sources” — while the former is stored for every visit, the latter is attached at the Visitor level, meaning as long as the system sees you as the same visitor, it’ll report your first ever referring domain.

As an example, say you found this blog via a link on Google but have since added it to your feed reader and usually come directly. Your Original Referring Domain would always be “google.com”, whereas your Referring Domain would have been “google.com” once and “Typed/Bookmarked” for all your visits since. Makes sense?

Going back to the processing steps, step 6 is where all this stored information about the visitor is applied. And what does “applied” mean, exactly?

Think about Success Events and let me explain using an example.

Whenever something important happens on your site — say a visitor shared an article —, you send a corresponding Success Event — say event15, called “Content Shares”.

You also try to encourage visitors to your site, say via social media. Your friendly marketer wants to know whether your posts actually bring people to the site and whether those people subsequently share content (VIRAL!!! Oops, sorry.).

Using the basic principle of Campaign tracking, you capture which post brought visitors to the site at the time when they land. You store that in the s.campaign “variable” (or rather a plugin in s.doPlugins() does that automatically).

I said above that all values that you send into the system are stored in the Visitor Profile, and that obviously includes the tracking code you just sent into s.campaign. So far so good.

Now when the visitor shares an article, the hit contains event15, but not the tracking code, right? This is where step 6 comes in: when the system sees Success Events, it applies them against the values that are currently stored in the Visitor Profile for all eVars that are currently enabled. Because s.campaign is an eVar, the tracking code you sent at the beginning of the visit now gets one point.

The resulting report looks something like this:

I’m afraid the number are exaggerated, but you get the point.

In essence, the Visitor Profile is what makes props and eVars different. Values for eVars are stored in the Visitor Profile, values for props are not.

How long values for eVars are stored and what happens when you overwrite them is controlled by your friendly marketer via the management console in Adobe Analytics. We will explain those settings another day.