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*
Loading…
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 assets.adobedtm.com. 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.
Tools
Examples:
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.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2018/04/180501-mcid-in-lib.png)
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 s.sa.
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.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2018/04/180501-order-cpc.png)
There is no difference visible on my simple test page between setting the Customized Page Code to “Before UI Settings” or “After UI Settings”.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2018/04/180501-before-or-after.png)
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.
Web Analytics for Developers 
Good post Jan!
LikeLike
Hi Jan,
I follow your analytics article and i found it really helpful. thanks for making life easier for beginners.
Could you please help with the scenarios where creating a custom code in “Before UI setting” or “After UI setting” really makes the difference.
or we don’t have to worry on that part and we can create custom code on any of the option( before or after UI setting)
thanks in advance
LikeLike
Kuidip, i believe Before or After UI is only relevant if you are setting beacon variables in your custom code. It essentially sets which code gets to set variables last,
LikeLike