(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.
CNAME
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:
visitor.marketingCloudServer visitor.marketingCloudServerSecure
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.
Note
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…)
Web Analytics for Developers 
@Jan Exner – 4.3 version of iOS and Android SDK’s now support the Visitor ID Service. Do you know of any documentation that helps describe the implementation beyond this short help page?
https://marketing.adobe.com/resources/help/en_US/mobile/ios/mcvid.html
LikeLike
Hi,
I don’t, no. Looks like an interesting topic for a blog article, doesn’t it?
The thing is: there is not much to do, really. The Visitor ID Service sits parallel to all the other parts of the Marketing Cloud. It has one job: provide a central visitor ID for all tools. There really isn’t that much to configure.
It’s still a topic definitely worth an article or two.
LikeLike
Completely agree that it’s worth a deep dive Jan and thanks for the reply about implementation. As far as future blog articles, I would love to see you talk more about what the VisID Servce and specifically the setCustomerIDs method in the service. It seems that clients will be able to pass our own customer ID’s into the service to find matches as well but will that data come out on the other end (sic:)) and be available in Data Warehouse feeds or is the VisID Service a black hole?
I thought it was that implementing the new SDK’s was as easy as setting the MCORGID in our config files as well but when I implemented in iOS and Android I get this lovely error:
ADBMobile Error : ID Service – Service returned error (Partner ID is not provisioned in AAM correctly)
Thanks for the great blog! Always look forward to Tuesday’s to see what you’re talking about.
LikeLike
Thanks for the flowers!
Re the customer IDs – I’ll write about that as soon as there is something to write about. For now, they do nothing as far as I know.
For the AAM provisioning you can contact your CSM, they should be able to do that. I think it depends what contract you have (old style SiteCat vs new Analytics) and possibly some other things.
LikeLike
Is visitor.setCustomerIDs needed to sync customer ids in CRM system with Adobe ids in Audience Manager? If we implemented _satellite.setCookie, would we still need visitor.setCustomerIDs? Or did you mean none of them is needed, if we have a prop or an evar in Adobe Analytics tracking the customer ids? Thank you!
LikeLike
https://helpx.adobe.com/marketing-cloud/how-to/unified-profile.html Here is the video about using setCookie when deploy with DTM, but when I did a search on the internet, there are a lot of people discussing how to use setCustomerIDs through DTM even Adobe staff. Could you explain more? Thank you very much!
LikeLike
Hi BC,
Feel free to give more detail about what you want to do, but as I read your questions, I’d say the answer is yes, use setCustomerIDs.
Cheers,
Jan
LikeLike