It has been almost 3 years since I wrote my article on debugging. I read through it the other day, and couldn’t help but notice that my workflow has indeed changed. Time for a new article!
I’ll stick with client-side this time, as this is where the changes have happened.
The second big difference is that in most projects, I no longer debug only Analytics. These days, I need to check that a bunch of other tools do the right thing, too — at least the Marketing Cloud ID Service and Target are more and more often deployed alongside Analytics.
Thankfully, tools have been updated, and new tools have popped up.
Adobe Debugger
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-adobe-debugger.png)
Adobe Analytics Debugger plugin
The tool I use most often is without a doubt the Adobe Analytics Debugger Chrome plugin by Tomas Balciunas.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-adobe-analytics-debugger-plugin.png)
It does cover the MCID Service, and makes some reasonable recommendations.
It does currently handle Analytics only, and it is available only for Chrome, but hey. I’d wager that alone would be a good reason to switch to Chrome.
DTM Switch plugin
The folk at Search Discovery have created the DTM Switch plugin for Chrome & DTM Switch add-on for Firefox.
This tool only does two things, but those two things are pretty important: it allows me to set DTM to debug and to switch between production and staging DTM libraries.
Absolutely crucial if you build anything in DTM.
And yes, there is an argument that I’m relying way too often on the debug output DTM gives me, plus a sprinkling of _satellite.notify() calls. It feels like those days when I was programming in BASIC on the Commodore 64, way before I knew what a debugger is. Yeah, I’m that old.
Console / Firebug
While technically, nothing has changed that much in the last 2.5 years, there are more useful things you should know about using the browsers’ built-in consoles/inspectors/whathaveyous.
First, how do you find out whether the browser loads all the tools that you have deployed? Here we go:
_satellite should return an Object, not undefined.
_satellite.appVersion will tell you what library version you are using.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-satellite.png)
Visitor should return a function, not undefined.
Visitor.version tells you the version of the Marketing Cloud ID library you have deployed.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-visitor.png)
AppMeasurement should return a function, not undefined.
You can see the version of the AppMeasurement code right there, too.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debug-appm.png)
s_c_il should return an array of Marketing Cloud-related objects, such as the MCID instance, the tracking object, the Activity Map module, and possibly others.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-scil.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-scil2.png)
mbox should return a function, not undefined.
mboxVersion will tell you what version of the Target library you are using.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-debugging-target.png)
mbox.js to at.js, in which case:
adobe.target should return an object, not undefined.
adobe.target.VERSION tells you what version of the code you’re on.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/02/170207-debugging-atjs.png)
Payloads
Beyond knowing that some code has been loaded, and that it is the right version, you might want to know whether the code actually does the right thing — sends the right data, to be exact.
Apart from the tools mentioned above, you can use the Network console that your browser sports.
The online help explains what the parameters mean quiete nicely: for the MCID Service, for Analytics, and for Target.
Two things I want to point out on top of that:
- How do you find those requests in the endless list?
- Anything specific I should look for?
Finding the interesting requests is easy: use the filter (“demdex”, “b/ss”, “mbox” work well).
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-network-demdex.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-network-bss.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-network-mbox.png)
And here is a really important bit in all this: does the integration between MCID Service, Analytics, and Target actually work? How do I tell?
Well, it’s all in the parameters.
Check for the “mid”. If it is there on all three calls (and it is the same!), then you’re good.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-mid-visitor.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-mid-analytics.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/01/170207-mid-target.png)
Charles
I have used and liked Charles for some time now. Nevertheless, I have recently changed the way I use it, slightly.
Before, I used to rely heavily on the “Map Local” and “Map Remote” features when I wanted to inject/modify Javascript in the pages of those sites I was working on.
These days, I really only use the “Replace” feature.
I guess the change reflects that I almost exclusively deploy with DTM these days, so all I need Charles for is loading DTM from Adobe-hosted in situations where the site hosts the libraries but doesn’t update them often enough.
Notes
How do you know whether someone prefers looking at the tracking requests in the Network tab, or using the Adobe Analytics Debugger plugin?
Easy: check whether their console is at the bottom of the window, wide, or on the right side, slim but tall. The latter is good for the Adobe Analytics Debugger plugin, whereas the former is better if you look at the requests in the Network tab.
And regarding the hip/strange title of this article: it occurred to me that debugging is something that will evolve all the time, meaning this won’t be the last article on the subject. Versioning therefore is necessary. Well, maybe not in yyyy.mm format, but it looks cool.
Web Analytics for Developers 
Hej Jan,
two little helpers i use (beside Adobe Analytics Debugger Chrome plugin by Tomas Balciunas):
– Tagtician (for Adobe DTM): https://chrome.google.com/webstore/detail/tagtician-for-adobe-dtm/hiaoiehpkillodoeillmodjcadmfmcbg?utm_source=chrome-app-launcher-info-dialog
– Adobe Marketing Cloud Pulse: https://chrome.google.com/webstore/detail/adobe-marketing-cloud-pul/ocdmogmohccmeicdhlhhgepeaijenapj?utm_source=chrome-app-launcher-info-dialog (new to me, but useful because it shows all Adobe Tools in one debugger)
Tagtician is great because it shows the used DTM Rules, but also the full library. It shows the used code in the rules, you can search after rules and code, you can export all this in csv, … (yeah i am a fan boy ;))
Greetings
Till
LikeLike
Agreed on Tagtician. There’ll be a post about it in a couple of weeks.
LikeLike
I like Tagtician plugin …
LikeLike
Hello there – I have a question about checing for Doubles calls or Duplicate calls.
When I worked for Samsung at my last job – I used Fiddler to carry out debugging, checking to make sure that the tags were in fact implemented properly and if there were errors I would then suggest changes that the clients could make to the code so that the tags were a) being picked up and b) double or duplicate calls weren’t being made.
At my new job at Kindred plc, having just started 3 weeks ago they’ve asked me to do the same on their site. Accept for the fact that I can’t use Fiddler because there are security issues so I’ve reverted to using Adobe Debugger instead. The site being debugged is http://www.unibet.co.uk and it uses DTM.
The question is can a site integrated with DTM be checked for double or duplicate calls using Adobe DTM Debugger tool? I guess these are request images with identical information being submitted to the Adobe servers – sending the same information twice or a multiple of times.
When I did the tests at Samsung they hadn’t migrated to DTM yet – so testing for Double or duplicate calls made sense because Analytics was being implemented manually and I know with DTM it’s different. I suspect that problems with Double tracking calls or Duplicate tracking calls do not occur with DTM. I have expressed this to my new employers but they want me to check anyway.
How do I check for these issues on Adobe Debugger? Thanks
LikeLike
Hi Amardeep,
You write “double or duplicate calls”. Can I ask you what you mean, exactly?
If it is about each page only sending a single tracking call, then the easiest would be to use the Network tab in the browser’s console.
Are you not able to install any plugins in your browser at all? Because those would help…
Best regards,
Jan
LikeLike
Nice summary
LikeLike
Hey @Jan Exner
Saw your adobe summit session on automating via the Json file you taught me how to create in brackets. LOVED it, thank you so much for the good old “know how” from some real experience. I’m curious about something on this topic. The debugger you used and claim to use int his article – is by far my favorite debugger ever. I actually reached out to the developer and thanked him personally and chatted back and forth for a bit. Recently, I was told specifically that i can only use Charles Proxy to debug due to accuracy concerns (which I have NEVER noticed a problem with using the adobe debugger extension by Tomas)… Have you ever noticed it missing any calls or hits? I’m not a big fan of Charles myself and was pretty shattered when I was told to use only Charles proxy considering its brutality of an interface and the way it is structured/functions. I’m just curious for my own sanity – have you ever noticed the debugger by Tomas to ever have missed any hits/calls/events etc? Thanks in advance, love your work!
LikeLike
Hiya,
Thanks a lot!
I haven’t seen it miss any tracking calls, but it is true that using a proxy such as Charles is “safer”, in the sense that the proxy will tell you what the browser actually sent out, whereas a Javascript plugin in the Console could in theory be the victim of all sorts of things happening in the browser, and therefore it would be more likely to miss stuff.
How about this: Use the plugin in your day-to-day work, but keep Charles (or Fiddler) on stand-by for the cases where you wonder whether everything is fine or not.
Cheers,
Jan
LikeLike