The analogy that sprang to mind was that of conjoined twins. But then I realized it’s just the opposite.
How do we join GA and Google Website Optimizer together so they don’t cross-contaminate each other? The same applies to any other situations where one needs to use more than one GA tracker to send data to multiple UA Web Property IDs.
I spend some of my commuting time answering questions on the GA Support forum. Many questions deal with multi-tracker problems and this is one of them. Rather than a lengthy reply there, I’m posting a lengthy reply here.
We will cover the essentials and then apply them.
One post dealt with GA + GWO and it’s interaction on http://www.pearl-group.com/google-website-optimizer-pro. So this also doubles as a free link and plug for their GWO + Joomla product. Here’s the link to the Google Analytics Support forum thread.
The symptom is that traffic is received from various traffic sources and sales are being made and the transactions are being correctly reported. However, they are being attributed to “Direct” visits and not to any of the traffic sources. Transactions are executed by a 3rd party shopping cart. The important point, however, is not that it’s 3rd party, but that it’s hosted on another domain, regnow.com.
This connundrum, like any debugging task, is not a mystery but a case of finding the break(s) in a single sequence of events. Visitors, Visits and Traffic Sources are all store in cookies. One certainty is that where transactions and Traffic Sources are being reported but transactions are not attributed to traffic sources, the problem is directly related to the cookies. Follow the cookie-crumb trail and you will find the problem.
In this case, there is a twist in the tale and a red herring, but the cause is still on the cookie trail.
Apart from the prime suspect (the 3rd party cart on a different domain), Ecommerce Receipt pages are classic causes of problems because their GA code is different from all other pages.
I also suspected when I saw that GWO was involved, that it could be the culprit. It very often is, through no fault of its own.
GWO reports to it’s own GA Web Property Id and so requires its own GA tracker in addition to the main one on your site. Whatever the reason for the 2nd tracker, there are two trackers reading GA’s cookies. One must remember that cookies are a common resource to all trackers and are neither tracker- nor Web Property Id-specific. That is the rule, in the absence of some careful cookie handling (which should not be tried at home:).
Before looking at the code, we need the Coles notes on the domain hash. It’s the number at the begining of all __utm* cookie values. It is “simply” a numeric value calculated from the (sub-)domain name in which GA writes the cookies. (The need for a domain hash and details of GA cookies is discussed under “The all-important Domain Hash” in Slicing and Dicing Cookies – Part 2 – Body Parts)
Remember we needed to track a visit that started on one domain (pearl-group.com) across to regnow.com, where the transaction is completed. Since cookies are written for a specific domain, the GA cookies written in pearl-group.com will not be accessible to regnow.com. The solution is to pass the data stored in pearl-group.com’s GA cookies across to the regnow.com domain.
Since the domain hash is calculated based on the cookies’ domain, GA cannot use the same domain hash on both domains.
In this case, the following, near-perfect, code for the main tracker sets hashing off. GA then uses the value 1, regardless of the domain to do cross domain tracking.
var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘UA-xxxxx6-8’]);
_gaq.push([‘_setDomainName’, ‘.pearl-group.com’]);
_gaq.push([‘_setAllowLinker’, true]);
_gaq.push([‘_setAllowHash’, false]);
_gaq.push([‘_trackPageview’]);
The only setting that may be unnecessary (but probably innocuous) on the commencing site, is _setAllowLinker. It is only required on the target site. It tells GA running on the target site to accept tranferred cookie information, rather than using it’s own.
The second 2 steps in the recipe are not rocket science but do pose a challenge if you’re unfamiliar with the code of your 3rd party shopping cart or need to rely on the 3rd party’s diligence. Some 3rd parties do GA well, some don’t and some you just can’t tell!
The following code for that 2nd tracker does not expressly use _setAllowHash so the default setting (true) applies on the order page:
var gwoTracker=_gat._getTracker(“UA-xxxxx6-15”);
gwoTracker._trackPageview(“/3970262329/goal”);
As a result, when one first lands on http://www.pearl-group.com/google-website-optimizer-pro, GA’s __utm* cookie values all start with “1.”. When one clicks “Get it Now” and goes to the order page, the 2nd tracker overwrites the first tracker’s cookies because it is using the domain hash. Compare the following Before and After screenshots of the Firecookie (Firefox & Firebug plug-in) log showing the transition. The numbers circled in blue are both the domain hash (125912588) and the randomly generated visitor token (173860778).
Note how the visitor gets a new visitor token number(before: 173860778 after: 2103943756). Since a visitor is a cookie, we just lost one visitor and got a new one.
Look also at the __utmz cookies. The before shot shows that the visitor (me) arrived via an organic Google search. However, when the cookies are overwritten, GA can no longer “remember” the Traffic Source and records it as a direct visit. Anything that happens hereafter, will not be attributed to that search.
It would seem that the simple remedy is to ensure that the settings for the two are kept in sync. While keeping your trackers in tandem fixes many problems and it is vital that that be done, in Pearl Group’s case, by quirk of fate, that is not the cause of transactions being incorrectly!
The data in pearl-group.com’s GA cookies are being passed to regnow.com. In fact, that is occurring before the second tracker overwrites the cookies so the correct cookie data is passed. At this point, we are almost at the end of the sequence of events and the problem caused by the 2nd tracker is certainly causing other problems but is not the culprit here.
Will we be able to find the problem? We’ll take a commercial break …
GA, running on the target site must have _setAllowLinker set to true so that it uses the cookie info passed over instead of creating it’s own.
The cookie info is being passed in this case and it is passed before the correct cookie info is overwritten by GWO’s GA tracker.
However, the problem in this particular case is that the landing page on the target site, is running FireClick and not GA. I did not complete a transaction but we know that GA must be running on the receipt page to be reporting transactions. But by then, the cookies’ info is lost, including the traffic source and so attributes the purchase to a Direct visit.
While the 2nd tracker may not have been the cause of this problem, is it causing other problems? Certainly. All traffic sources will be stored in the cookies by the first tracker. However, in all vists that include a page with the 2nd tracker, will have the cookies re-written as “Direct”
But perhaps that herring needs a closer look! If that receipt page is hosted on pearl-group.com and the GA runs on the visitor being returned to Pearl-Group’s site, it would be the 2nd trackers that will have overwritten the traffic source in pearl-group.com’s cookies.
As I said, debugging involves knowing the correct sequences of events required for a positive outcome and figuring out where it is interrupted. But as Yogi Berra said, “It ain’t over till it’s over”
Brian Katz – Analytics – VKI
As consumers become increasingly digitally savvy, and more and more brand touchpoints take place online,…
Marketers are on a constant journey to optimize the efficiency of paid search advertising. In…
Unassigned traffic in Google Analytics 4 (GA4) can be frustrating for data analysts to deal…
This website uses cookies.