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

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

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.version tells you the version of the Marketing Cloud ID library you have deployed.

Testing for the MCID Library

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

Testing for the AppMeasurement Library

Checking s_c_il

Finding the Report Suite ID through s_c_il

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

Testing for the Target Library (mbox.js)

adobe.target should return an object, not undefined.

adobe.target.VERSION tells you what version of the code you’re on.

Testing for the new Target Library (at.js)

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:

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”

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

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.