DudaMobile Google Analytics FIX
DudaMobile + Google Analytics = #FailSometimes I find myself really bothered by 3rd parties who claim to have Google Analytics integrations not take the care to make sure that is done correctly. Indeed, one of those companies is DudaMobile.
image from the DudaMobile site
The strange thing about the DudaMobile situation is that they have some sort of official partnership with Google Analytics. Indeed, when you search for Google Analytics and DudaMobile, there are lots of articles about this relationship out there. I didn’t take much time to read into exactly how this partnership works, but my understanding is that it is different from the actual DudaMobile product.
Let’s take a look at a pizzeria that DudaMobile highlights on their site, see the problem in action first hand, and then I’ll provide the fix.
When I go to Hawthorne’s Pizza from a Google Search, I indeed see the referral information properly reported by Google Analytics.
When I change my user agent, I’m redirected to their mobile site, and my referrer data is lost.
Here’s the utmz cookie:
Things getting even stranger….And here is where things get even weirder… If you take a look at the template code from DudaMobile, they have some wonky logic where they are calling up to 3 different trackers. And yep, you guessed it, they are calling _setDomainName inconsistently which always leads to problems.
In the Hawthorne’s case, unfortunately, their GA code is not even present on the mobile site. It is supposed to be referenced under externalGaqID. What blows my mind is that if it was indeed there, it shouldn’t even run because _setDomainName is called for a domain that is explicitly incorrect.
I’ve done testing to this regards and have been directly in touch with a top member of the GA developer team about this. Strangely, GA does run even when _setDomainName is called in this manner. I am convinced it is a bug in GA, but an incorrectly defined _setDomainName always used to mean that GA would not execute. So, for users who actually added their GA account number into the DudaMobile backend, forget about self-referrals, they’d see NO DATA. (Barring this anomaly).
Update… I just chatted with my friend @thyng who seems to think that _setDomainName would indeed not inhibit hits from firing in cases where it was declared appropriately once before the improperly called method. In other words, he doesn’t believe it is a bug, but just they way that GA works. I’m still a bit skeptical, but I respect David’s opinion here. Personally, I still think it is buggy behavior because _setDomainName is supposed to help determine GA’s cookies scope. In any case, if _setDomainName is not called correctly to the domain that it is supposed to be set on (i.e. if the _setDomainName doesn’t match document.domain), one thing that will certainly happen is that that particular tracker will spawn a new VISITOR on every hit. As far as DudaMobile goes, that means that visitor and visit counts are being way inflated. #ouch
So let me put this in bold… even with this “referral fix,” GA will still INFLATE the number of visitors and visits to the DudaMobile site for the improperly configured (website owners) tracker.
Back to the referrals…In any case, I was totally stumped about how to get around this issue for clients since getting DudaMobile to update there GA code seemed like a stretch. (To be fair, I’ve not dealt with them personally, this is just based on client feedback and what I’ve seen in a few forums). The proper thing to do would be to A). Update the DudaMobile multiple tracker situation so that they have setDomainName called correctly. B). Capture the document referrer on the client side and pass it to the mobile site C). Use _setReferrerOverride on the DudaMobile site.
Until… Based upon the Product Forums post, I received a tweet from @Nikalytics
I answered that without DudaMobile’s help, we were stuck. DudaMobile needs to update their GA code.
And then Monica shared a wonderful insight with me
BRILLIANT! I was (am) so excited that I decided that I must blog right away. :-) Of course, I hastily tested this, and it does indeed seem to be that functions in the same way that _setReferrerOverride would, except that it can be set in the URL instead over directly in the GA tracking code.