(Ah, the title… see what I did there?)
Just two days after my article about the Visitor ID Service, my colleagues in Engineering and Product Management released a new version of Reports & Analytics and made a couple of nice changes to the Visitor ID Service.
So, essentially, forget everything I said last time. Maybe not all of it, but there are two aspects that I have to revisit (ah, I did it again!) and one that I’d like to mention.
The Visitor ID Service can now handle CNAME implementations.
Two new variables allow you to tell the Service which domain it should use for cookies. These are:
Set those two and the Visitor ID Service can be used to track visitors across domains.
The online help explains nicely why that works, even with Safari and other browsers that have a strict policy regarding 3rd-party cookies.
Report Suite ID
Or rather not.
In my last article, I wrote that when you instantiate the Service, you do so using the report suite ID. That is no longer the case.
Instead, you now use the “Adobe Marketing Cloud Organization ID”, which you can get from Client Care when they set you up for access to the Marketing Cloud.
It makes sense to me to replace the report suite ID with something else. Some customers use the Marketing Cloud but not Analytics. Why would they specify an rsid? And what about tools that have no concept of a report suite? Why would I give Audience Manager an rsid? Or Target? It would make no sense!
So if you implement the Visitor ID Service now, you pass the MCORG ID into the “constructor” rather than the rsid.
Visitor IDs & Customer IDs
You can now specify IDs for your visitors that come from your back end systems.
For example, if a visitor logs into your site, you now know who it is and you can send that data into the Visitor ID Service along with the normal tracking or targeting.
A visitor can have more than one customer ID and you can assign those IDs to names that make sense to you.
I want to point out that, currently, that data is not used by any of the tools of the Marketing Cloud, but there is likely going to be some new cool functionality at some point that uses the data, so why not start preparing now?
Note: do not pass any identifiable information into the customer ID! Never! Hash it, if you’re comfortable with that. Encrypt it, if you’re a hero. Or just don’t.
One more thing: if you decide to implement the Visitor ID Service now on the site you are responsible for, you might want to read about the Visitor ID Grace Period.
Essentially, if there is any doubt as to whether your implementation will instantly be available everywhere on your site, you should make sure to use a Grace Period because the Visitor ID Service will otherwise not hand back a visitor ID that Analytics could read on its own, thereby preventing places where Analytics is not yet using the Visitor ID Service to see an existing visitor ID.
You’d end up inflating your visitor counts and upsetting your friendly marketer.
There is also a section in the help on how the Visitor ID Service works, which I recommend.
(Sorry for the short posting this week. I am in the middle of moving to Basel in Switzerland and I’m currently lying on the floor in an almost empty house. Not the best position for typing long blog posts…)