Magento Google Analytics Code Has Errors

Last week we deployed another successful Magento ecommerce website. To track the visitors we signed up for a free Google Analytics account, and then plugged their tracking code into the admin section of the Magento administrator area. When we applied the API, the site quickly confirmed that the tracking code was in place through the Google Analytics dashboard.

1Google_API
We then waited 48 hours, and then logged in to see how many visitors hit the site. Turns out that none of the visitors were being tracked! Using the error console within Firefox we reloaded the page, and found the problem instantly. Turns out the Magento coders totally messed up when creating their Google Analytics API. Take a look for yourself, here’s the JavaScript they used:

screenshot-www jvfconsulting com 2015-02-20 11-58-49
This is how it should read:

screenshot-www jvfconsulting com 2015-02-20 12-00-09
As you can see the Magento coders have it all out of order, and forgot the most important line of code that created the “_gaq” object:

screenshot-www jvfconsulting com 2015-02-20 12-00-49
We can only assume that this API is broken on all Magento builds! To fix this, remove the tracking code from the Magento Google API in the admin area, then use the JavaScript given to you by Google Analytics, and place it in the footer of your website. Whala! Your site is now tracking visitors appropriately with no errors in the error console.

  • Just like to reflect back some of the experiences we’ve had with tracking pixels on Magento Go or the lack of them…
    Using the standard google api seems to work and is supported by MG.
    But we need to track advertising on FBX and retargeting and cloning sites.
    Placing pixels in the header as recommended by one site somehow interupted the code in MG with regard to the transactions crossing from the http:/ store front end over to the https:/ store cart or checkout. Result was orders doubling and tripling in the cart randomly (when the tracking pixel was active).
    Scrapped code from the header and tried some services recommending pixels in the footer. Similar experience, had to scrap pixels.
    Don’t know if this is because the pixel code was faulty/incorrect or that MG has code errors.
    We notice that Olarkpopup chat routines in the Footer don’t interfere with the rest of the code.
    Interested in any feedback because we are not sure if we will migrate to Magento Community or something else?
    Anyone have any recommendations for e-commerce cms with good tracking APIs?
    Looking at prestashop or shopify or bigcommerce or volusion.
    Do any of you have a preferred ecommerce cms to work on? impresses you?
    thanks

  • I’m pretty sure Magento fixed this error with their last update. Took them long enough to catch on! This is still excellent for those of you who are running older versions since its almost impossible to upgrade without crashing your entire store. lol

  • J.T.

    I run a number of Magento shops off one installation. I used to have one AdWords account, linked ot one Analytics account to track them all.

    We recently started separating the AdWords and Analytics accounts to keep stuff more organised. As that means stopping one Analytics account’s tracking and starting a fresh on a new one, I opted to track to both the new account as well as the legacy account, so that one keeps rolling on nicely, including historic data.

    Here’s how to do it:

    http://www.lunametrics.com/blog/2009/02/26/pitfalls-tracking-multiple-accounts-ga

    However, Magento’s native Analytics support of course only allows for one Account ID. So, like you, I figured I’d just use the footer code textarea in design. But when I look at the source of any of my current pages, generated with the native Analytics code, Magento renders the SEO URL:

    pageTracker._trackPageview(“/products/masks/nasal-pillow-masks.html”);

    What I’m no apprehensive about, by plonking the standard (new) Analytics code in the footer manually, is that it just shows:

    _gaq.push([‘_trackPageview’]);

    Without the full page URL. I know this makes a big difference in Woopra, mainly with URL paramters so I’m weary of doing this now this way.

    Can either of you please report back on this, whether it has affected your content URL reporting?

  • I faced the same problem for one of our clients. Because Google ‘s advise to place the script just above the tag it’s just as simple but better to use design in the system config of MG. This will place the script in the right spot.