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!

15 thoughts on “Debugging

  1. Pingback: Dynamic Variables | Web Analytics for Developers

  2. Pingback: Debugging – the URL | Web Analytics for Developers

  3. Pingback: Modifying Data Server-Side | Web Analytics for Developers

  4. Pingback: Finding a ‘Report Suite ID’ | Web Analytics for Developers

  5. Pingback: Data Warehouse & Data Feeds | Web Analytics for Developers

  6. Pingback: Tracking Mobile Apps | Web Analytics for Developers

  7. Pingback: Tracking Internal Search | Web Analytics for Developers

  8. Pingback: Tracking w/o Javascript | Web Analytics for Developers

  9. Pingback: Ode to Charles & Map Local | Web Analytics for Developers

  10. Pingback: Processing Rules – Positive or Precise | Web Analytics for Developers

  11. Pingback: A Short History of Processing a Hit | Web Analytics for Developers

  12. Pingback: Tagging Forms (w/o Losing Money) | Web Analytics for Developers

  13. Pingback: Debugging 2017.02 | Web Analytics for Developers

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