BigCommerce Analytics vs. Google Analytics

January 28, 2014
by Max

Hello all,

Thought I’d shed some light on these 2 different reporting platforms as we’ve been experiencing tremendous sales growth and it is important to us as a company to determine the accuracy and efficiency of our marketing methods as well as identifying the reasons for our growth. unfortunately, we’ve noticed these platforms reporting numbers that were extremely off from one another and have been resilient in finding out why!

In the beginning, we set up Google Analytics just as described in Big Commerce (Aug 2012). Since then, reported sales / visitors / conversions have been inaccurate reporting numbers as low as 60% of what BC was reporting. This is frustrating, because as you know, BC cannot do a lot of the great features GA can, like exporting data, or reporting pageviews, goals, conversions etc!

Immediately set up SSL for goal conversion accuracy!
As part of my job in marketing, I use email marketing as a way to direct traffic to the store. Well, it’d be nice to know how much of this traffic is converting, but every time I set up a Google tagged URL (http://support.google.com/analytics/bin/…r=1033867)┬áto track campaigns, we saw tons of people visiting, but nobody converting. I thought this was odd, so I attempted to use my own custom URL, buy a product and see what happened. As expected, I saw my traffic but no conversion. After I set up a 3rd party SSL, this started working. In short, the shared SSL that BC stores use by default confuses GA as it switches your stores root directory (xxx.mybigcommerce.com) at checkout, therefore making goal conversions ineffective.

Understand timezones!
This was a surprising find for us – Once we got goal conversions working, we still noticed order and order size discrepancies. It seemed orders that BC were reporting weren’t being reported in GA until the next day. So who’s right? After confirming both platforms were set to our timezone (EST) we simply looked at the timestamp on an order email confirmation. BC seemed to think it was placed an hour prior, meaning our EST setting was having no effect. Thus, GA was correct! This a bug BC, if you’re going to advise us to set our timezone, at least make it work!

EDIT – This is because Daylight Savings was still checked under store settings. Oops! Easily overlooked though!

What is ‘an order’?
This was an interesting experiment – in comparing number of orders from BC to GA, the number of orders were different. Additionally, in analyzing an number of orders from a particular day on BC and then looking at that SAME number of orders say, 2 weeks later on BC, we would notice the number drop 1 or 2 orders. Why?

  • Refunding (Even partial refunds!) warrants BC to subtract that order from the order number total.
  • GA doesn’t care about refunds.
  • BC will report orders placed on back end.
  • GA will not.

So thats a tricky number to look at and it’s accuracy will depend on how you deal with refunds, etc. We’re thinking it may make more sense to start utilizing store credit as it will push any corrected orders customers want to the goal page that GA can utilize, therefore taking back end BC orders out of the equation.

There’s still tons more to figure out. The next thing we’re going to look into is Unique Visitors, as GA and BC both seem confused as to what this metric truly means. In the mean time, I hope this post sheds some light on these sometimes confusing platforms and also pushes BC to step up their development from a reporting standpoint.

About

Max Avedisian has had the pleasure of working with a extremely broad range of clients in order to bring the best in technology and digital production today. From traveling the world as a production and band assistant, to cutting-edge video production, to next-level graphic and web design, Max Avedisian has serviced a wide range of needs and has met the challenges of many businesses small and large. Max has been professionally pursuing his passions in Digital Design since his graduation from Full Sail University in 2010.

3 comments

  1. |

    Hey Max,

    I’d like to personally thank you for attempting to get to the bottom of this issue we’ve ALL been experiencing. Thank you!
    I have one question about:
    “After I set up a 3rd party SSL, this started working. In short, the shared SSL that BC stores use by default confuses GA as it switches your stores root directory (xxx.mybigcommerce.com) at checkout, therefore making goal conversions ineffective.”
    Couldn’t you avoid this issue you by setting your GA conversion destination to “Equals to” using just the standard “/checkout/order-received” URL?

    Would that make the root directory issue go away? Or is it actually the fact that GA cannot track because of the switch to the root?

    Thanks again?

    • |

      Hello Billy, thanks for your comment.

      That may work, and would be worth trying if you want to save on the cost of an annual SSL. I would assume that the root of the website is important to Google Analytics almost all of shopping carts have a common root throughout checkout. However, in general I would advise using a purchased SSL to get rid of the xxx.mybigcommerce.com as it improves the consistency of the URL’s throughout the checkout experience and makes your website slightly more trustworthy.

      BigCommerce’s SSL is more expensive than your average 3rd party SSL, so compare them to see which is right for you.

      • |

        Hi Max,

        I agree with you 100%. We certainly never want to make the user feel like they are begin directed somewhere else (Especially that far in the conversion process!)

        Cost for the SSL is not a big issue considering the value of sales that could be lost otherwise.

        Thanks again and looking forward to what you discover next!

Leave a Comment