getMarketingCloudVisitorID in DTM

Hi Lukasz,

Can you send me a private message with the DTM Company, Property, and URL you are adding this to? 

Thanks!

Tacia

Hi Tacia,

This worked.

Thank you very much.

Hi Tacia,

I'm getting a "Uncaught TypeError: Cannot read property 'getMarketingCloudVisitorID' of null" error message when I try this method.

I'm setting it as a data element using Custom Script.

Any ideas on why it would throw this error?

Cheers,

Ed

Hi Ed,

Can you send me your Company Name, Web Property, and Data Element name via a private message? I can take a look.

Thanks!

Tacia

Hi Edward ,

We are looking into why the error is being throw. Ideally there should not  have been any error. However please look at the alternative solution suggested below to get marketing cloud visitor id value.

1. 1. Create a data element based on a cookie :
      
   2. Create a second data element based on a custom script that will get the value from the data element above and use regex to extract the value for MCMID:

Thanks & Regards

Parit Mittal

"Create a second data element based on a custom script that will get the value from the data element above and use regex to extract the value for MCMID:"

Quite frankly, this is an awful answer and I'm stunned that someone from Adobe would even suggest it. It is absolutely absurd that each client should be using a backup method of a regex to scrape a cookie just to get the ID. Why does "_satellite.getVisitorId().getMarketingCloudVisitorID()" not just work and why is it so ridiculously complicated (i.e. why not just give us a _satellite.getMarketingCloudVisitorID() shortcut)? What happens when you decide to change the cookie? All your clients are just SOL and left scrambling, right?

I'm so sick of the simplest of things being needlessly and unbelievably impossible with Adobe. Is there any hope of that ever changing?

A few notes to add to this, for posterity.

Internally, DTM instantiates an object from the Marketing Cloud library's Visitor "class" (object), similar to what is shown here (also pasted below, in case the link breaks):

var visitor = Visitor.getInstance("INSERT-MARKETING-CLOUD-ORGANIZATION-ID-HERE", {
     trackingServer: "INSERT-TRACKING-SERVER-HERE", // same as s.trackingServer
     trackingServerSecure: "INSERT-SECURE-TRACKING-SERVER-HERE", // same as s.trackingServerSecure
     // To enable CNAME support, add the following configuration variables
     // If you are not using CNAME, DO NOT include these variables
     marketingCloudServer: "INSERT-TRACKING-SERVER-HERE",
     marketingCloudServerSecure: "INSERT-SECURE-TRACKING-SERVER-HERE" // same as s.trackingServerSecure
});

In practice, DTM abstracts that away into _satellite.getVisitorId() and returns visitor, so that is what you get from the _satellite.getVisitorID() method.  If you're going the "vanilla" route (shown in original post), this is the missing step from the original link that actually defines visitor (which, incidentally, is now a 404 page. Someone decided to change some underscores to a hyphens in doc url taxonomy, and broke a lot of doc links... Here is the current working link: getMarketingCloudVisitorID ).  So this part is the DTM specific syntax.

From there,  getMarketingCloudVisitorID() is a method of the Visitor "class" (object), which is the Marketing Cloud ID Service tool's syntax, which returns the actual marking cloud visitor id (what you see in the AMCV_XXX cookie, or from the mid= param in the AA request).

So _satellite.getVisitorId().getMarketingCloudVisitorID() is "complicated" because it is chaining two methods from two different tools together.  And it should work if you implement the marketing cloud visitor id service as a tool in DTM. 

As for why they couldn't provide a shortcut like _satellite.getMarketingCloudVisitorID(). Personally, I don't really see the big deal about this.  An extra method call thrown into the chain isn't some kind of earth shattering rocket science for anybody who codes on the regular.  Better to break it out into conditions to check if the methods exist instead of chaining them. Or at least wrap in a try..catch.  Regardless, all of this is coding 101 level stuff.

Also, the Visitor object has a lot more uses than just returning the mid= value, so it makes sense that DTM should have a method that returns the full instance of the Visitor object.  And at that point, making "convenience" functions for specific things becomes a question of how tightly you want to couple two tools together.  Best practice is to make coupling as loose as possible, to maximize flexibility.  Granted, one of the most common use cases for all of this, is getting the mid= value.  But, it's not all that common for implementations to require it to begin with.  I have dozens of clients on marketing cloud id service and only a few of them require this sort of thing (usually for other 3rd party integrations such as qualtrics).  

Abstracting all of it to a Data Element is... ehhhhhh... more often than not, probably overkill, in practice.  But in general it is good practice to make use of DE's, just in cases.  And again, sure, Adobe could bake that into a prefab DE, but again, question of coupling tools.  Yeah they are both Adobe tools, but I'm pretty sure they aren't maintained by the same dev teams. But even if somehow they are, loose coupling almost always trumps all. 

I definitely agree that scraping the AMCV_XXX cookie for the mid value is a bad idea.  Today we can see that the cookie contains pipe delimited values, and we can see that "MCID" is the 4th value, and the actual mid (what is in the mid= param in the request, and what is returned by the above methods), is the 5th value. So we can easily parse this from the cookie

(btw, regex...really? Overkill. Just use your favorite method to grab the cookie value,  and do var mid = "value".split('|')[4];). 

Except.. Adobe does not actually provide any official documentation or any kind of guarantee about the formatting of the cookie. So this works today, but there is no guarantee it will work tomorrow. 

Hey Josh,

Thanks for the thoughtful response, I appreciate it. Just wanted to touch on a few things:

This is really interesting, but where are you getting this info from? Is it documented somewhere (hopefully on Adobe's site) or did you extrapolate it from Adobe's code?

So the challenge for me is that I haven't been able to hunt down a _satellite API (you're gonna start to notice a pattern here). I'm just looking at the autocomplete for _satellite. in Chrome's Console (an Adobe consultant even mentioned this as the way to go to me). When I have to go another level deep and go through all the functions ... well that's where my frustration comes in. The syntax of this may be coding 101 stuff, but how am I realistically supposed to find this stuff if an Adobe consultant is telling me to just pour through autocomplete?

Maybe I'm just searching for the wrong terms or the wrong stuff, but my takeaway was that the Experience Cloud Visitor ID was supposed to be a pretty big deal. For me, someone who supports an Enterprise level company, we've got our fingers all over the place, so being able to toss the IDs between multiple systems is critical ... and doesn't feel like it should be this hard. (Side note: if there's documentation that talks more about the Visitor object I'd be curious as to what else it can do.)

And there's the reason that regex isn't necessarily overkill. What if the Adobe changes something and we end up grabbing a 4th value that's no longer the ID and don't even realize it. With the regex at least we eliminate that possibility.

Thanks again for your thoughtful response! It's appreciated to see something of this depth here!