What I write about mostly on this blog has to do with analytics, specifically Adobe Analytics, fka SiteCatalyst.
But this is just one in the large collection of tools your friendly marketer uses to do her job. Analytics allow her to capture data for analysis and observation. She can also use the data to drive aspects of her site, such as personalisation.
Other parts of her toolkit allow her to manage SEM spend, email marketing, testing, targeting, site search, social presence and a ton of other aspects of customer interaction.
Most vendors have realised that offering more of that toolkit makes for bigger deals and easier integrations, so almost all are now offering cloud-based solutions that cover more than one angle. Adobe is one of those vendors, and the offering is called the “Adobe Marketing Cloud”.
(Sorry for the long-winded introduction, I just want to make sure I explain when and why using the Visitor ID Service is a good idea.)
So when your marketer uses more than one tool, integration makes sense. Obviously.
Let’s look at an example.
Let’s say she is using Adobe Analytics and Adobe Target. Her analysts have sifted through a lot of data about how customers acted over the last months and they think they have discovered a segment of visitors that should spend more money if only they were presented more relevant banners across the site.
So your friendly marketer wants to try, and for that she needs to take the segment her analysts built and use that in Adobe Target.
Right, this is it with the preliminaries, now we’re going back into the basement, where light is neon and bits dance in heavy metal racks and through bright, yellow cables.
What does “taking a segment and using it” actually mean? How is a segment defined?
Ah! Good questions you ask, young apprentice!
Segments are essentially defined by rules, any kind of rules. They usually contain visitors, of course, because visitors is what your friendly marketer really cares about.
So using a segment in another part of the marketing cloud means that this other part must be able to identify each visitor that is part of the original segment as such.
Remember how we identify visitors? Yes: the visitor ID!
Note on privacy: Just to be explicit here. The tools do not have to know who these visitors are! It is enough to be able to identify them as the same totally anonymous ID in Analytics and Target. I think this is an important distinction, mostly because in some markets in Europe, collecting any personal data is highly restricted.
Example: I forgot my shopping bag in a corner shop, so I went back to collect it about 5 minutes later. The shop keeper remembered my face and gave me the bag. He doesn’t know who I am, but he was still able to identify me as the person who forgot the bag.
The Adobe Marketing Cloud wasn’t built from scratch. It came to life over time as Adobe (and Omniture before that) built some tools and acquired others, then integrated all of them. Those individual tools all had to identify visitors when they were standalone tools, and so they all had their own mechanism for doing so.
I wrote about how Adobe Analytics does/did it two weeks ago, so you should know that.
And today I want to show you the way forward, the Visitor ID Service.
The idea is that in the future, all the parts of the Marketing Cloud should be using the same visitor IDs. That would enable them to integrate very tightly, at a visitor level. Meaning: Find a segment of visitors in one tool, do something with it in another. Bliss.
I think we all agree that is a good thing, and I know your friendly marketer wants it, so the remaining question is: how do you implement it?
There are some things you need to check:
Your company must be enabled for the Marketing Cloud. You should probably ask your friendly marketer or analytics manager to work on that.
If you are using
AppMeasurement.js, you need at least version 1.3, and if you’re on standard
s_code.js, it has to be H.27 or later.
For those of you on Adobe Target, make sure your
mbox.js is version 48 or later. The AppMeasurement libraries for Flash, Flex & Air must be at least version 3.8.
The second step is to configure the file.
At the very top of
visitorAPI.js you have to configure two or three lines. You will need to add your report suite ID into the first line and your tracking server into the second (and potentially tracking server secure into the third).
I have previously explained where to find the report suite ID, and the tracking server(s) can be found in the configuration section in the
s_code.js file. Sometimes they are hidden away just above the “* DO NOT ALTER ANYTHING BELOW THIS LINE ! *” line.
Make sure the values match the values in your current
s_code.js file, otherwise there’ll be tears and “visitor cliffing”. Visitors who had a perfectly valid visitor ID will be assigned a new one, temporarily inflating the count of unique visitors on the site, making your friendly marketer sad.
The third step is to add this file into all of your pages or templates.
<head> tag which is perfectly fine.
The fourth — somewhat optional, but very recommended — step is to track whether the library works or not. The documentation tells you what to track and to wait for the coverage to be 100% before moving on. It does not tell you that you can assign the variable in the
s_code.js file so you don’t have to do it on each page.
The fifth step is to tell Adobe Analytics to use the new visitor IDs.
For that you just use the new
Visitor object to set the new
s.visitor “variable”, like so:
s.visitorID = Visitor.getInstance("RSID");
Those of you who are using a tag management system have it easy. You will likely be able to do the whole change in your TMS and noone will even notice!
Please make sure you test thoroughly before you put the change live, though! Visitor cliffing is not catastrophic, but it can mess up the data quite a bit and your friendly marketer might be slightly less friendly if you do that.
As usual, the documentation in the online help is pretty good, so you might want to give that a try as well.