DudaMobile + Google Analytics = #Fail 

Sometimes 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.

DudaMobile makes it really easy for webmasters to create a mobile site which is hosted by DudaMobile.  That’s a great thing.  I love it.  But in order to get a user to the mobile site, they provide webmasters with some javascript which does a 302 redirect.  Oy vey. 302…  <shutter>  In addition to the SEO problems that are bound to pop up, especially as there is now lots of duplicate content problems for webmasters since they have a 2nd site hosted on a DudaMobile domain.  But I digress…

The 302 javascript redirect that DudaMobile provides ends up passing referral information from the site the user came from instead of the original referrer.  As a result, the poor webmasters who are hoping to have Google Analytics tracking for their mobile sites end up just seeing a bunch of self referrals and have no sense of how there mobile site is performing vis-a-vis their acquisition channels.  According to this Google Analytics Forum Post, @Arkansas Traveler mentioned that the DudaMobile support team said that there is no workaround to this.

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.

The Fix…

Just replace your old DM_redirect.js file with DM_redirect_working.js and you’re on you’re way to proper mobile tracking. Make sure to keep the next line javascript line that includes the DM_redirect function (that’s the one that has your site name listed in it.

https://analytics-ninja.com/dudamobile/DM_redirect_working.js

One more thing…

DudaMobile turns off domain hashing since they use _setDomainName(none).  This means that all cookies on the mobile.dudamobile.com subdomain are written to the explicit domain AND don’t have a hash.  Setting aside the bug that I discussed earlier with _setDomainName not invalidating hits when called for the wrong domain, in the case  of users going to multiple DudaMobile sites, their web browser won’t be able to distinguish between the cookies so you might see some really weird referral information from sites your users might not have even visited.  As my friend and mentor Caleb Whitmore has told me many times, “make sure that domain hashing is turned on.  GA fixed that issue 2 years ago people…”