The 2 Faces of the Audience Manager – Analytics Integration

So here you are, wondering. Your friendly marketer has told you to add a new tool to the toolbox — Adobe Audience Manager. She told you that you have to implement some code for it to work. You checked the help site and came away none the wiser.

Let me help you.

There are currently three approaches:

1. work with someone who knows, e.g. Consulting,
2. implement AAM along-side Analytics (“DIL code”), or
3. use “server-side forwarding”, where Analytics automatically hands data over to Audience Manager

If you now think “the 3rd approach sounds as if it is the easiest one”, yes, I concur. It is also the recommended approach.

Recommended — server-side forwarding

The idea is that Analytics and Audience Manager sort out data propagation between themselves, with minimal changes necessary on your site.

Literally the only change necessary is that you add the Audience Manager Module to the Analytics core Javascript code.

You get that module from the Code Manager, just like the AppMeasurement.js code that you need for Analytics.

Once you have done your part, contact your consultant or Customer Care, so that Adobe can enable server-side forwarding.

And that is it.

How do you know it worked?

Here’s an easy test.

Open your page, look at the Network tab in the browser console, find the Analytics tracking call (filtering by “b/ss” helps).

Click on the request, then switch to the “Response” tab on the right hand side.

You should see something like this:

If you see a very simple postback that only says something like “success”, then server-side forwarding has not yet been setup properly.

DIL code

Before we had server-side forwarding, this was the only way to go.

“DIL code” is essentially Javascript that defines Audience Manager in your browser. If it is properly setup, it is able to grab all the payload data off the Analytics call, then send it to Audience Manager separately.

You get your DIL code from Adobe, usually from a consultant. This is due to the fact that DIL code is specific to the client and the Analytics implementation to a certain extent.

There is one big thing you need to work out before you include the DIL code. The question is “what data do I want to send to Audience Manager?”

I’m thinking here in terms of how exactly should the DIL code trigger a call to Audience Manager, or how often.

With server-side forwarding, everything that is tracked into Analytics also ends up in Audience Manager. That is good practice, and it becomes obvious if you look at it the other way round: if it is important enough that you track it in Analytics, it is likely a candidate for making segments.

So the obvious first thing is: we want a call to Audience Manager at page load, just like for Analytics. Easy.

Analytics is also often used to track user interaction — things like button clicks, tool usage (car configurators, mortgage calculators, etc.) for tools built into your site, downloads, and other things.

Technically, these are usually grouped under the term “custom link tracking”. I have written about that some time ago in Tracking Links & Actions, if you need a quick refresher.

With AAM and DIL code, you should see a call to AAM whenever a call goes out to AA, too. Typically, the AAM call happens just before the AA call.

The DIL code is perfectly able to handle that on its own, all you need to do is to include it in your page, create the “DIL object”, and initialise the SiteCatalyst (Analytics) integration.

Note that this has to happen just once on any given page!

Audience Manager, unlike Analytics, does not have to be triggered manually in a scenario like this.

The calls marked in yellow are made by the DIL code. The first one (“event?_ts=…”) transports the payload data, where as the second one (“dest5.html”) loads an iframe that’ll handle a lot of Audience Manager’s functionality.

If you’re implementation is good, every “event?_ts=” call should correspond to one “b/ss” (Analytics) call.

What? Where? How?

Ok, a little bit more detail.

When you get the DIL code, it usually comes in three pieces, or it contains three distinct things.

1. The “core DIL code”, comparable to the core s_code, the library that enables Audience Manager in the visitors’ browsers,
2. a (parameterized) call to DIL.create(), which sets up the DIL object properly, and
3. a (parameterized) call to DIL.modules.siteCatalyst.init(), which “connects DIL to Analytics”, so to speak.

The easiest way to implement DIL is to keep those three pieces in a single Javascript file (I’d call it “dil.js”), in the exact order above, then load that file just after you load AppMeasurement.js in your pages.

This is an example of a valid DIL implementation. A very simple one.

<!DOCTYPE html>
<html>
<head>
    <title>Test for Occurences &amp; callbacks</title>
</head>
<body>
    <p>
        This page is a test. It includes MCID Service, Analytics, and <a href="step2.html">a link</a>!
    </p>
    <p>
        This is a <a href="#" onclick="var s=s_gi(s_account);s.linkTrackVars='events';s.linkTrackEvents='event2';s.events='event2';s.tl(this,'o','Mein Link');">non-sensical but tracked link</a> right here.
    </p>	

    <script src="VisitorAPI.js"></script>
    <script src="AppMeasurement.js"></script>
    <script src="dil.js"></script>
    <script>
        s.pageName="Callback Test Page 1";
        s.t()
    </script>
</body>
</html>

Some people load the DIL code in the page, as above, but then place DIL.create() and DIL.modules.siteCatalyst.init() into the doPlugins method. This is NOT necessary. DIL is perfectly able to handle all Analytics calls itself, and putting it into doPlugins does not add anything to a basic setup.

Having said that, placing those calls into the doPlugins method is not an issue, either. DIL handles that scenario just as well.

If you are using a tag manager, like DTM, your mileage may vary.

The easiest way to handle DIL is probably to have the three pieces in a single file, and to make sure that file is loaded after Analytics. That should really be it.