Debugging 2017.02

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

The Adobe Debugger
The good old Adobe Debugger has been updated over time, and it is still the most comprehensive tool for Marketing Cloud users/analysts/developers. It still shows human-readable output, and it covers pretty much anything you need, the notable exception being the MCID Service.

Adobe Analytics Debugger plugin

The tool I use most often is without a doubt the Adobe Analytics Debugger Chrome plugin by Tomas Balciunas.

The Adobe Analytics Debugger Plugin
The plugin simply prints a readable version of any tracking request into the Console in Chrome.

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.

Testing for DTM
Visitor should return a function, not undefined.

Visitor.version tells you the version of the Marketing Cloud ID library you have deployed.

Testing for the MCID Library
AppMeasurement should return a function, not undefined.

You can see the version of the AppMeasurement code right there, too.

Testing for the AppMeasurement Library
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.

Checking s_c_il
Each one of those objects can be queried, of course. Most likely, you’ll need to figure out report suite IDs…

Finding the Report Suite ID through s_c_il
mbox should return a function, not undefined.

mboxVersion will tell you what version of the Target library you are using.

Testing for the Target Library (mbox.js)
You might have moved from mbox.js to at.js, in which case: should return an object, not undefined. tells you what version of the code you’re on.

Testing for the new Target Library (at.js)
If you like working in the Console, or you simply cannot install any plugins, check out the list of handy one-liner debugging helpers, and feel free to download the Inofficial Adobe Marketing Cloud debugging Cheat Sheet!


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:

  1. How do you find those requests in the endless list?
  2. Anything specific I should look for?

Finding the interesting requests is easy: use the filter (“demdex”, “b/ss”, “mbox” work well).

Network panel with filter “demdex”
Network panel with filter “b/ss”
Network panel with filter “mbox”

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.

MCID Service request with mid
Analytics tracking call with mid
Target call with mid
If not, then check tracking servers, versions, cookies.


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.


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 format, but it looks cool.

10 thoughts on “Debugging 2017.02

  1. Till

    Hej Jan,

    two little helpers i use (beside Adobe Analytics Debugger Chrome plugin by Tomas Balciunas):

    – Tagtician (for Adobe DTM):

    – Adobe Marketing Cloud Pulse: (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 ;))



  2. 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 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


    1. 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,


  3. Pingback: Adobe Analytics cheat sheet – Best resources to master Adobe Analytics, including Workspace & DTM |

  4. Pingback: #1: Why digital analysts should learn tag management. – The Analytics Practitioner

  5. thesmarthomeninja

    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!


    1. 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.



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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s