Debugging

You are a developer – you develop! Also, sometimes, you debug.

Our article today focusses on the latter: how to debug when you are implementing Adobe Analytics.

Let’s start off by finding out what exactly we can expect to debug.

Adobe Analytics has a lot of moving parts, some of them client-side, some “in the cloud”. Debugging the latter is very much an end-to-end test situation, while the former can be debugged “traditionally”.

Client-Side

In the article about variables, we explained how you send data into Adobe Analytics and that it eventually ends up being parameters of the URL in an HTTP GET request.

That makes it fairly easy to debug. You can use all sorts of tools to see what your browser actually sends:

Let’s start with the Adobe Debugger. Here’s what it looks like:

[Screenshot]

Adobe Debugger

The Adobe Debugger is a bookmark with Javascript that when called displays the window you can see on the left in the screen shot. It works with Adobe Analytics (“SiteCatalyst”) but also other parts of the Adobe Marketing Cloud.

The big plus is that it “decodes” the information it finds in the URL.

You can clearly see that this specific page we’re looking at has set s.prop1="DE";.

If your browser has built-in tools or you are using a tool like Firebug you can look for the HTTP request and check the parameters.

[Screenshot]

Firebug

You won’t have the variable names. s.prop1 will instead be c1, s.eVar9 will be v9. The documentation has a list of all symbols.

Apart from that, the actual data you see is exactly the same!

It is also exactly the same if you debug using a proxy like Charles or Fiddler.

[Screenshot]

Charles

Proxies have advantages: they can show you a timeline of requests, not just what the current page sent out. Especially useful when we get to link tracking.

They can usually save a file containing all HTTP traffic they grabbed. That means you can load it back and look at it later, in case you’re not sure about parts of it.

Also, proxies let you tweak the requests, the pages or even the s_code.js file on the fly. (Look for a feature called “Map Local” in Charles!) Extremely useful for testing changes to the s_code.js file before putting it live. Don’t forget to switch it off after testing!

Server-Side

As we said above: there’s not a lot of debugging you can do server-side, mostly because the processing really is a black box. Also, there are a lot of settings that govern how the system processes the data once it has arrived, and some of those settings you will probably never touch when you implement. It’s a bit of a grey area. Or gray area, if you’re in the US.

Our suggestion: run controlled tests!

Here’s how it works:

Say you just made a change to your s_code.js file. From now on, your site is supposed to pick up the “fb_ref” parameter for links coming from Facebook and put the value into s.campaign.

  1. Think of a use case and define a step-by-step test.
  2. Determine what data you expect to see after the test (this is crucial!)
  3. Run through the test.
  4. (Bonus step: check the value in s.campaign using one of the tools mentioned above.)
  5. Log into Adobe Analytics and compare the data you see with what you expected.

Two notes:

  • Make sure you give the system some time before you check the results (see Latency in SiteCatalyst 15 for details).
  • It is imperative that you figure out the expected results before you run the test! I guarantee you that if you run the test first, you’ll be able to explain the results to yourself, no matter how wrong they are. It’s called “confirmation bias“. I even sometimes look at the data and my expected outcome and try to argue that my expectations were wrong. Don’t fall into that trap!

So there you have it, now go and develop something so you can use your new-found skills to debug it!

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 Principles
15 comments on “Debugging
  1. […] yes, this is longer. But if you go back to the article on debugging and check the long URL that was sent on our test page, you can see that using dynamic variables did […]

    Like

  2. […] data, but there are some that do not. We won’t go into the first category again, having mentioned them before. Instead, we’ll explain some of the non-data […]

    Like

  3. […] b) that they can modify the data sent into the Analytics platform! Nothing is more irritating than debugging without knowing what the system can […]

    Like

  4. […] a debugging tool of your choice, look for the actual tracking call being made. You will notice the characters […]

    Like

  5. […] we can see looking at the tracking call in a debugger, this call transports the pageName, props, eVars and three events ‐ prodView, event2 & […]

    Like

  6. […] usual approach is to configure your emulator or device to use a proxy and then use your favourite debugger and check the data being sent in the tracking call by looking at the URL — really not that […]

    Like

  7. Lisa says:

    Thanks for this, Jan, really clear.

    Like

  8. […] a search term, hit enter and wait for the results page to load. Then look at the tracking using your favourite debugger. Check the “variables” that are being […]

    Like

  9. […] have tried to explain what the URL looks like in the articles about debugging here, here, here, here & especially […]

    Like

  10. […] have mentioned Charles before, but today I want to show you my two most common […]

    Like

  11. […] easy. Because it all happens in broad daylight, you can check what a site is tracking using a debugger. Just look at the […]

    Like

  12. […] this point, you can very easily see what happens, which makes this the perfect spot to debug by looking at the URL (do I have to repeat that I use Charles for that? Or did I mention that […]

    Like

  13. […] it until your dreams are filled with cookies, plugins and form elements. You do remember how to debug, don’t you? Look at the […]

    Like

  14. […] 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 […]

    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,398 other followers

%d bloggers like this: