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

[screenshot]

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.

[screenshot]

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.

[screenshot]

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.

[screenshot]

Testing for the MCID Library

AppMeasurement should return a function, not undefined.

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

[screenshot]

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.

[screenshot]

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…

[screenshot]

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.

[screenshot]

Testing for the Target Library (mbox.js)

You might have moved from 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]

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!

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

[screenshot]

Network panel with filter “demdex”

[screenshot]

Network panel with filter “b/ss”

[screenshot]

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.

[screenshot]

MCID Service request with mid

[screenshot]

Analytics tracking call with mid

[screenshot]

Target call with mid

If not, then check tracking servers, versions, cookies.

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.

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , , , , , , , ,
Posted in AppMeasurement, DTM, Integration, Javascript, Page Code, Tips
3 comments on “Debugging 2017.02
  1. Till says:

    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

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,377 other followers

%d bloggers like this: