DTM is quite a bit easier to use and handle than Launch is. Partly, Launch is new and we are all on the upwards slope of the learning curve. Partly, Launch opens up whole new worlds.
For those of you working with/in DTM and/or Launch, this is a pretty cool time.
I once wrote about how and why I blog, so you won’t be surprised to hear that I learn a lot by doing stuff (making mistakes). In the context of DTM and Launch, this is only effective if I can see what I’m doing (wrong), so for me it is vital to see what the differences are between debugging with DTM and debugging with Launch.
Debugging DTM
I have written about this a bunch of times, so let me summarise:
- DTM Switch plugin — vital to switch to staging
- Charles — replace or inject the proper DTM Javascript
- Browser Network tab — see what is loaded
- Browser Console tab — see what DTM does
That’s really all I need, and the bit about Charles is somewhat optional.
Debugging Launch
Now, Launch, by Adobe.
For starters, there is not just production and staging code, but at least one or more development environments, plus staging, plus production.
That means that just adding “-staging” into the path will no longer work. Instead, the/a browser plugin will have to replace URLs pretty brutally.
Luckily, DTM Switch can do that.
And it can automatically pick up your header codes if you click it while you’re in your Launch Web Property. Pretty cool.
![[screenshots]](https://webanalyticsfordevelopers.files.wordpress.com/2018/07/180807-debug-switch-found-environments.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2018/07/180807-debug-switch-switches.png)
Secondly, you have to explicitly build your library when you want to test your changes. This will bite me often, I predict. Stuff you add or change has to be added to your dev library before a build. That, too, will get me. But I’ll adapt.
In terms of looking at what is happening, the built-in tools in your browser are still your friend. Launch is slightly more verbose than DTM, output is clearer when set to debug mode.
You can still inspect the _satellite object in the Console, or look at the source of your dev library.
Note that some functions and attributes have changed. For example, _satellite.notify() has been deprecated, to be suceeded by a proper logging API.
And if you want to look at your library, make sure you omit the “.min” part from the URL, to make it more readable.
Monitoring
Launch is more verbose, but it does not output anything about which Rules it considers or executes, even in debug mode. That is a deliberate decision. Monitoring of those aspects are now handled by a proper framework within Launch, which you can attach to.
In an article on Medium, my colleague Aaron Hardy described how to use the Launch Library Monitoring Hooks.
Aaron rightly states that if you want to see everything that Launch does, you have to define the Monitoring before you load Launch, i.e. in your HTML templates. I can see three ways of doing that, two of which are more practical then the the other:
- Literally put the code into the <head> of your pages (via template, snippet, component, or whatever your CMS likes),
- Inject the code into the page using Launch, or
- Inject the code using Charles.
Of those three, only the last is truly seemless and complete. Seemless in the sense that it doesn’t require any intervention from anyone else but me. It is therefore my preferred approach.
The first approach, while maybe ok on a development or staging site, should clearly not be used on any production environment, and it can be quite a lot of work, depending on how your CMS handles things like this.
The second approach looks ok, until you realise that you won’t see things that happen before the monitors are created and attached, meaning you can only monitor and troubleshoot parts of what Launch does. It has the advantage of not needing any additional tools, of course.
Maybe, someone should write an Extension… or maybe, Search Discovery will at some point add that to their lovely plugin.
Web Analytics for Developers 
Tagtician actually automatically drops the monitoring hook into the page.
LikeLike
Hello! thx for the article! Actually, the problem is in wanting to debug the third party scripts since launch minifies everything in a single script. Will you have any idea how to do it? Regards!
LikeLike
Hi Jesus,
I had an article in the pipeline answering that question.
It will go live on Tuesday, the 5th of March.
HTH,
Jan
LikeLike