The following is the tale of some investigative work I did for a company which approached me to help them with their Google Analytics tracking for their online store. This company, like so many others, sells items on the Internet and wants to be able to properly attribute their sales to the correct channel using Google Analytics. Not surprisingly, in addition to having subdomains they were using a third party shopping cart and needed to have cross domain tracking configured.  Pretty simple.  Or so I thought…

  Shopify Homepage


As it turns out, the third party shopping cart they were using is called Shopify.  As far as being an intuitive user interface that makes it easy for non-technical users to set up their store, I certainly see a lot of positives with Shopify.  Unfortunately, Shopify also tried to make setting up Google Analytics “dumb proof.”  In the end, trying to figure out why I couldn’t properly set up a simple, working basic GA tag led me to be “dumbfounded.”   Shopify has a very simple interface where one simply needs to copy and paste their Google Analytics tracking code in order to get started.  


shopify pasted GA code  


However, as soon as you save the file, Shopify takes the Google Analytics code and rewrites it to match their own settings. In particular, they are choosing to _setDomainName to “none”, adding _setAllowLinker (which would indeed be  required for cross domain tracking) and switched to dc.js.  (I am not sure if the folks at Shopify paid attention or not, but to use the DoubleClick cookie, users are supposed to update their Privacy Policies accordingly.  I didn’t see any sort of notification to do so on their site.  Oops.)


shopify code rewrite      


Of particular interest to me is that Shopify is using setDomainName = none.  As my friend Caleb Whitmore of Analytics Pros has told me on more than one occasion, “setDomainName(none) is the devil.” That is because in addition to removing the domain hash (which was deprecated as a requirement for cross domain tracking in August of 2011), this method writes the Google Analytics cookies to the EXPLICIT domain.  In other words, if the site is www.example.com, then the GA cookies are written to WWW.  If a site needs to do tracking across a subdomain, this is simply not possible using _setDomainName(none).   When I first started providing code for Imogene and Willie (which has their main site template and the Shopify store on a “shop” subdomain), I began by providing them proper code that would handle both subdomain tracking (by setting GA’s cookie scope to the root domain), and cross domain tracking (by providing linker functions to bind to the action of form posts).  I started my purchase process from their homepage (on WWW), and everything looked good.



shopify homepage GA  


 But as I noted above, we were not able to update the setDomainName method on the Shopify store (shop.imogeneandwillie.com).  As a result, we are forced to add linker functions that are normally reserved for true cross domain situations, in order to share the cookies across subdomains.  


shopify CART ga


Now to the issue of cross domain tracking.  Normally, one needs to use _link or _linkByPost to append cookie values to links and form posts respectively, or use _getLinkerUrl (the preferred method imho) to add the values directly to hrefs or form actions.  Noticing that the site did not use any of these methods, my team provided script that would look for the particular form in the Shopping Cart and pass on cookie values so that they would make it to the Checkout.



  form action added small

The next page in the checkout funnel did indeed indicate that our code did have the proper cookie values passed to it.

shopify checkout setcookie - Copy


But a very surprising thing happened when I navigated to the next page in the checkout process.  My cookies were reset; i.e. the visit became a new Direct visit.  Same domain (checkout.shopify.com).  Same GA code (including the setDomainName nonsense).  I was totally stumped and give major props to my man David Vallejo for finding this.

  As it turns out, Shopify caches the GA cookies as they exist on their store and then writes them server-side within the checkout.  Since, on the client side, in both the store and checkout they forcibly turn off domain hashing, as a user proceeds through the checkout their cookies are reset (wiped-out) if there is a discrepancy between the cookie value with domain hashing and the cookie value without it.

shopify cookie reset  

Ultimately, it seems to me that some of the developers at Shopify simply did not understand how GA’s cookies are supposed to work.  It would have been a much cleaner solution if they would simply enable client-side cross domain tracking and not mess with the cookie scope (setDomainName) at all.  Certainly, they should be more transparent about what they are doing in their documentation.  I feel it is quite a lot of chutzpah on the part of Shopify to assume that they know what is best with regards to GA, and completely hijack the stores ability to configure GA in the correct way.  To be fair, had they gotten it right I’d feel differently.  As a personal note to developers out there, if you’re doing any sort of integration with Google Analytics, please work with a professional.  From a developer standpoint, Google Analytics is really not that hard at all.  However, “small” mistakes can have “huge” business ramifications.  Don’t mess with this stuff unless you truly know what you’re doing.

Until next time,

Yehoshua