The Mechanics of Loading Analytics Code with DTM

Yes, I know, Launch. But I had this post in the pipeline for some time now, and here you go. As a bonus, I have noted where Launch, by Adobe, handles things differently.

If you came here from my “battle post“, then this is some background that’ll help you understand why I wrote the other post in the first place. Still waiting for Jenn to respond, by the way. I guess she’s now so focused on Launch that she won’t. *sigh*


I think we all understand by now that DTM (and Launch, by Adobe), is pretty much a script generator with a nice UI.

As someone who uses DTM, you work in the UI to create Web Properties, Data Elements, and Rules, to add Tools (or, in Launch, Extensions), and to drop the odd bit of Javascript code into some of the very many editor windows that you find everywhere across the UI.

DTM takes all of these and makes one or more Javascript files, which it stores on an Akamai-supported infrastructure on It does that whenever you hit Save, and when you Publish. The former creates “Staging” files, while the latter updates the “Production” files.

(Launch has a more complex workflow, and it doesn’t create staging files on the fly. Instead, it can create “Libraries” of Javascript files in as many development “Environments” as you want, which include only the changes you explicitly assign to them. Those Libraries can then be pushed through an approval and publish workflow and eventually become the production code.)

The crucial thing is the the DTM Javascript has to be included into your pages. With DTM and Launch, you add a line to the <head> of your site. With Launch, you can also load it asynchronously, which would change everything you read below, so we won’t deal with that option today.

Once the browser loads the file (called “satelliteLib-XYZ.js”), and depending on what you have configured, there will be some Javascript execution, and some more loading.



If you included the “Marketing Cloud ID Service” tool (or, for Launch, the “Experience Cloud ID Service” Extension) in your Property, the satelliteLib will include its Javascript code.

Experience Cloud ID Service as delivered by DTM
If you include the “Adobe Analytics” tool (or the “Adobe Analytics” Extension in Launch), the satelliteLib will load a second Javascript file, usually called “s-code-contents-XYZ.js”. You can see that in the screenshot above, too.

This file is very similar to the good old s_code.js file of back when we implemented manually. It even includes some of the same things: configuration and the core Javascript code.

Depending on how you use DTM, that stuff all comes from you (if you manually host the library in DTM, like Jenn does, in which case it can also include plugins and the doPlugins method), or it is assembled from the Adobe-hosted core code plus settings like for example the report suite IDs.

And there is more: whatever you write into the editor in the “Customize Page Code” section of the Analytics Tool/Extension ends up in a “customInit” structure, which DTM will execute when it loads the page. This is where the cool kids put things like plugins and the doPlugins method.

I very highly rate that I can put custom code into the “Customize Page Code” box, and still have DTM handle the core Javascript code, including very simple updates.

Launch, btw, makes this even better, because it allows you to assign report suite IDs via Data Elements, hence eliminating the need to use

So when exactly does customInit happen? Is it really the same, or can it be made to function exactly like a standard s_code.js file?

To test that, I put a _satellite.notify() into the “Customize Page Code” editor and checked.

Load/execution order of Analytics Tool in DTM
The code is executed before the first Analytics call is triggered by DTM, of course.

There is no difference visible on my simple test page between setting the Customized Page Code to “Before UI Settings” or “After UI Settings”.

Setting code to run before or after UI
In order to find out exactly when the custom code runs, I will probably have to build a more complex Web Property, with DCRs being called in the page and such. Given that Launch is the future, I might skip that.

Exceptions (when Jenn is right)

Analytics comes with the concept of “Modules”. Those are almost like plugins, but not quite.

When (sorry) If you ever download the Javascript code archive, you’ll find three important Modules in there, which you can incorporate into your s_code.js or AppMeasurement.js file:

1. The “Media” Module,
2. the “AudienceManagement” Module, and
3. the “Integrate” Module.

The Activity Map is also realised as a Module in Analytics code.

The big difference between Plugins and Modules is that Plugins are built to be executed inside the doPlugins method, while Modules amend the core code. As such, their deployment goes more deeply into the core Javascript code.

Activity Map is easy. The Module comes bundled with the core Javascript code. But the other three have to be integrated, and that can only currently be done by modfying the AppMeasurement.js file, then pasting it into DTM (or hosting it yourself).

This is the one and only situation where Jenn’s way of customising is better necessary.

Now you know.

One thought on “The Mechanics of Loading Analytics Code with DTM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s