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.
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 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
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.
Visitor should return a function, not undefined.
Visitor.version tells you the version of the Marketing Cloud ID library you have deployed.
AppMeasurement should return a function, not undefined.
You can see the version of the AppMeasurement code right there, too.
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.
Each one of those objects can be queried, of course. Most likely, you’ll need to figure out report suite IDs…
mbox should return a function, not undefined.
mboxVersion will tell you what version of the Target library you are using.
You might have moved from
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.
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.
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).
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.
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.
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 yyyy.mm format, but it looks cool.