Google Analytics – To String or Not to String

Est. Reading Time: 4 minutes

Sometimes when a website is not working correctly it causes you do document someone else’s code.  In this case, I discovered something about Google Analytics (“GA”).

The Situation

One of my newly inherited clients recently installed a “popover” advertisement on their front page, as a promo for a new product line, and wanted to track the clicks in Google Analytics.  It wasn’t tracking, however.  The original code installed had a couple of problems:

  1. The page didn’t originally have the GA code installed to send events anywhere. That was fixed.
  2. The page then wasn’t firing the event. The event was there, but there wasn’t an onClick or onLoad being used to reference or “fire” the event back to GA.  That too was fixed, but still no events were tracking.

We are using the new asynchronous (“async”) style GA code in the popover’s HTML.  The popover was being loaded by the homepage in an iFrame. The homepage was still using the older Urchin GA code. I was pretty sure this was the problem. It wasn’t.

Side Note: do NOT use or reference the new async GA code and the old Urchin or traditional JS GA code in the same page.  It is possible to do this by mistake, since the optimal location for the new async script block is at the bottom of the <HEAD> tag at the top of your page/template header, while the older Javascript code or Urchin code usually reside just above the close of the </BODY> tag, usually in your template footer. That way it is likely GA will be pinged for a visit even if the user hits the back button, which was less likely to happen if you were waiting to call GA from the bottom of the page by the tag.

The originally coded event was:

_gaq.push(['_trackEvent', 'the-event-name', 'Click', 1]);

It was bugging me that the arguments Google usually use as examples for GA implementation, and all examples I see of Event Tracking, were a Category, Action and Label that are always arguments as strings. My hypothesis was that GA’s javascript doesn’t like any of the arguments/attributes of an event to be non-string, or in this case a real number — 1 — and not the equivalent string – ’1′. Since there are a variety of explicit and implicit ways you can, and often have to, convert strings to numbers or numbers to strings in Javascript, I guessed that GA’s script isn’t type checking or type casting the arguments and just fails silently.  The code was changed to:

_gaq.push(['_trackEvent', 'category', 'action', 'label']);

After changing the attributes to what I thought would be informative categories, actions and labels, all as strings, it worked. Now tracks the events with Ads being the Category, Popovers being the Action and The-Ad-Name is the Label.

Alittle More on Urchin vs Traditional JS vs Async Google Analytics Calls

One of our developers was correct about another technical issue that wasn’t – I thought it might be the client’s site was using the old Urchin tracker on the homepage, but we were using the async call for the popover we were tracking. That’s isn’t the problem in this case, but I did Google it and they recommend that you never mix the ASYNC, traditional JS, or Urchin scripts on the same page, and have a migration page dedicated to how to convert from either old style urchin or javascript to the new Async code, and they recommend the GA script be the last item in the for all sites.

Why Wasn’t It a Problem?

Since the popover is loaded in an IFRAME, with its own URI and HTML, it is treated as a distinct event by GA.  Sometimes you find good answers out of simple curiosity when something isn’t working.