Everything but the TMS

You know what the problem with luxury is? You get used to it. And then it becomes hard to enjoy the little things.

I am so used to tag management by now, that when I see how popular the mini-series on the s_code.js file still is, I keep wondering why would people even look at that anymore?

There is a good answer of course: doing things the hard way helps you understand them a lot better than if all you have to do is ticking a bunch of check boxes.

So sorry, DTM, but this one is not about you. Go do some shopping, or spend the day in a spa.

Today, we’re trying to implement Analytics, Target, plus the Marketing Cloud ID Service, the old-fashioned way.

Preparation

(In which you run around the building, frantically, trying to find someone who has access to the bits of information you need)

On top of a test page somewhere, we need:

1. the AppMeasurement.js file
2. a Report Suite ID
3. a tracking server
4. the VisitorAPI.js file
5. a Marketing Cloud Org ID
6. a Target client code
7. the at.js file

Ask your friendly marketer. If she looks at you like you’re from Jupiter, ask your analyst, or try to figure out those values from your live site.

You can easily find rsid and tracking server by looking at the URL of any tracking call. See Debugging – the URL for details.

The Marketing Cloud Org ID should also be visible. Find it using the Debugger Chrome plugin, or look at any call that goes to the demdex.net domain and see whether you can find a “d_orgid” parameter. You have to decode the latter!

Now for the client code for Target, I guess the best bet is to go to any page that has a running campaign. You can either look at the “Request Domain” filed in the Debugger, or use the Console again, go to Network, find any request towards tt.omtrdc.net, then use the first part of the hostname:

Analytics

I feel we should start with Analytics, because.

To get the AppMeasurement.js file (the modern equivalent of what used to be called s_code.js), you can either ask your friendly marketer, or — if you have a login for Analytics — go to Admin > Code Manager and download it yourself.

Take the file that hides behind the “Javascript (new)” link.

Note that you have a link on the right that points to the implementation guide. Bookmark that. It does often help.

The zip file that you get contains the core JS file, some sample HTML, some additional modules and the JS file for the Marketing Cloud ID Service.

For now, all we want is the core JS file. Put it somewhere on your server.

Time to load that file into your test page.

The file as it is does not work, really. There is some configuration to do. The corresponding page in the implementation guide has sample code, which you can just copy and amend.

Note: we used to keep everything together within the s_code.js file, and we can do the same with AppMeasurement.js, but it is also possible to put all the configuration into a separate file. That’s what DTM does! Why would we do that? Easier upgrades of the core JS, of course. And, once again, better control and insight.

I shall copy the sample code into the page itself, for clarity.

For now, I do not include the Marketing Cloud ID Service, just Analytics.

I specify my rsid and tracking servers into the code, then put it all into a <script> tag after loading AppMeasurement.js.

Half-way there.

At the bottom of the page, I add some JS code. All I want is set a page name and a minimum of other things.

Stop me if you think that you’ve heard this one before, but in the spirit of keeping it simple, I shall keep it simple.

If you want to see what I did, the three pages are online.

Let’s load that page, see if it works.

YES!

Two things to note in that screenshot:

1. The Analytics debugger tells us we should implement the Marketing Cloud ID Service. Haven’t done that so far, so fair point.
2. The DTM Debugger on the top right is grey. Poor thing… no DTM here.

Oh, and why does it load twice? It doesn’t. The Analytics server just told it to reload so it could try and set the s_vi cookie.

In my case, that failed. Chrome doesn’t like 3^rd-party cookies too much. My visitor ID for Analytics will therefore be the one found in the Javascript-set s_fid cookie.

… talking about visitor ID …

Marketing Cloud ID Service

… let’s add the Marketing Cloud ID Service!

This step is pretty simple. We just have to include the VisitorAPI.js file and add a line to our in-page Javascript block.

Quick question: in what order do we load AppMeasurement.js and VisitorAPI.js?

Answer: doesn’t matter.

What does matter, though, is that you load both before the code that configures them and creates the s object.

If we load the page now, you can see that the debugger shows a Marketing Cloud Visitor ID. Success!

Btw, if you do not use the Analytics Debugger in Chrome (or you simply don’t use Chrome), you can check whether the Marketing Cloud ID Service loads properly by checking the “mid” parameter on the Analytics tracking call.

The “mid” parameter is only set by the Marketing Cloud ID Service, so if you see it, the Service is working.

You probably noted that I followed the recommendation in the implementation guide and added a prop that tracks the presence of the Marketing Cloud ID Service. Do that!

Target

In order to add Target, we need to find, download, and add the at.js file. The best way to download is described on Download at.js Using the Target Download API in the help section.

As you can see, with my client code “janexner”, I need to pull the file from “admin16”. Yours will be different, of course.

Following those steps will get you a “pre-configured” at.js file, so no need to configure anything else. Just include the file into your page.

A quick check in the console after loading the test page reveals that at.js is being loaded.

Shall we add an mbox and see whether we can run a quick test?Well, we don’t need to add anything to the page. The global mbox can be added safely from within the Target user interface.

How about integrating Target with Analytics?

For the latest versions of both solutions, the integration happens in the Adobe data centres, rather than in the visitors’ browsers. There is a provisioning team that will work with your friendly marketer to get this set up.

So we’re done!

Notes

This was a fun exercise. Now we know what dependencies we need to be aware of between the different pieces of Javascript. There are surprisingly few, actually. Just load VisitorAPI.js and AppMeasurement.js first, then your configuration code, and at.js should be loaded last, as close as possible to </head>.

For you, this might be helpful if you want to do it like I did (manually), or if your TMS doesn’t have defaults for the Adobe tools and you need to make sure everything loads as desired.

After writing all of the above, I had the chance, last week, to change to an account that has a working integration between Analytics and Target (“A4T”), so I took the liberty of changing over to that account. The screenshots and examples in this article are no longer up to date, but the 3 linked pages are, and you should easily be able to understand what I changed.

Big bonus: I can (and do) now target some visitors on page 3.

Having done all of this, and having learned something on the way, there is now but one thing to do: rip it up and start again!

And this time, do yourself a favour, use a tag manager!