Google Analytics

When Google Analytics E-Commerce Reporting is just… broken?

Posted at April 19, 2011 | By : | Categories : Google Analytics | 1 Comment

There is a longstanding thread on the Google Analytics Help Forum discussing accuracy problems with Google Analytics e-commerce tracking and reporting.  This thread has continued to grow considerably since it was started in January of 2009 and accuracy issues with Google Analytics e-commerce reporting carry on –  in fact, getting worse.  However, I’ve recently narrowed down what I believe is the significant cause behind most of these issues.

I’ve worked with a number of new clients in the last several weeks to address e-commerce issues. My prior posts have revolved around that fact that a properly implemented GA e-commerce integration is pretty bulletproof, i.e. within 5% accuracy. In 99% of cases where there are major problems, they are from implementation mistakes, not problems with GA itself.

A Simple Cause for Missing Data

There is a common mistake that I’ve seen taking place more and more frequently as companies have migrated to async code.  They are:

  1. The e-commerce integration code isn’t migrated. This will break tracking or source attribution, or otherwise mangle your data quality.
  2. The e-commerce code is updated to async style, but error-checking and character control aren’t implemented.

Let me explain on point #2 further

The async standard code uses apostrophes to encapsulate text strings, i.e. ‘this is a product name’. In JavaScript, function calls and text strings have to be evenly encapsulated. Thus, this would break the script: ‘this is caleb’s favorite product’. Notice the three apostrophe’s in that string? The ‘ in “caleb’s” will break JavaScript. If that is your product name in your GA e-commerce tag, then JavaScript would have been broken and the transaction would not have been recorded into GA.

In order for the JavaScript to NOT error there would have to be an escape character (a before the ‘, like this: “…caleb’s…) or the apostrophe would need to be encoded (bad idea – makes your reports hard to read) or removed (best idea).

The Case of a Simple Apostrophe

Now, this becomes an issue because apostrophe’s are surprisingly common in product names and weren’t usually escaped with the classic code since the default code was quote mark encapsulated. I.e. like this: “this is caleb’s favorite product”. The apostrophe in the middle of the string is fine in that case since it is quote encapsulated.

What I’ve been seeing is that the programming logic in many e-commerce integrations has been updated to use async when rendering out the GA code, but not to control against the apostrophe issue. Thus, lots of errors. But, hard to detect errors because they only come up when people order things with an apostrophe in the, which isn’t going to follow a typical pattern by browser type or geography or even seasonality in most cases.

How to Check if You’re Affected

How do you see if this is affecting you?

  1. Are your GA e-commerce transaction numbers off by more than 5%? If so, then you have a problem.
  2. Do a simple search against your list of product item names in the GA report for products. Simply search for “‘” (without the quotes, i.e. a and then a ‘ which will tell GA to look for any product names containing an apostrohpe).
  3. If the above search returns no products but you do sell items that do have apostrophes in the names, then you are probably suffering from this issue.
  4. You can take the checks a step further by looking back in time to see when the culprit item names stopped showing up. It’ll probably align with when your change to async launched. Additionally, spot-check orders: look for days where GA is low in its transaction count. Evaluate those orders for ones with items that have apostrophes, then look in GA and you will probably NOT see those order ID’s (this is if you need further ammunition about the problem before taking it to the developers to point out their mistake – along with a pizza or order of Mocha’s for everyone in the room).

I hope this helps!  If you’re affected by this issue – try the steps above and post a comment below.  Of course, our support team is always available to help should you need an extra hand.

-Caleb

Share

Comment

  • Will Young

    October 8, 2013 at 2:03 am

    How amusing that the humble apostrophe should be the cause of such panic and confusion. This post and your responses in the related forum thread have been hugely beneficial in zeroing in on a problem for one of our clients. Goes to show how useful older blog posts like this still can be.

    Thanks Caleb.

Leave a Comment