A few of our clients have been seeing referrals in their Google Analytics reports from their own sites: something unexpected, but not unheard of. There could be a few culprits in this crime against data. Digging a bit deeper into the reports, it seems that, for the instances I was looking at, most of the referrals were being seen on the clients’ mobile sites.

If the mobile version of a site is accessible at a subdomain different from the main site, then a light form of cross-domain tracking should be implemented to preserve Analytics data between the versions of the site.  By default, Google Analytics is set to treat different subdomains as separate entities, but by explicitly specifying a domain name for a subdomain, Analytics cookies can be shared, and the user’s same session can be tracked continuously. With subdomains, setting the domain should suffice, but the problem with the mobile sites was not that they were hosted on a subdomain, but rather how mobile users were directed to this subdomain.

For at least one of the mobile versions of our clients’ sites (hosting and implementation provided by a third party), users were being redirected to the mobile site through a JavaScript “redirect,” which is not a proper 301 redirect! Users hit the desktop version of a site, then a document.location assignment takes place through JavaScript, and the browser is sent to a subdomain hosting the mobile site. Because the browser is not receiving a 301 response from the server, this redirect is treated as a referral on the mobile site, and the original Analytics session ends.

Although these issues were specific to the third party mobile site providers used by our clients, issues with self-referrals may pop up even if you’re rolling your own mobile site solution and not opting for a responsive site. Below are a few solutions to tackling this referral problem.

SOLUTION 1

The best solution here would be to handle the redirects with server-side technology. Since a majority of our clients run Apache, the .htaccess file can be edited to redirect traffic that matches mobile user agents. If the user would like to view the full version of the site, a cookie can be set, disallowing further redirection to the mobile site.

This Stack Overflow answer addresses this exact issue, and takes setting and reading a cookie into consideration. Other server technologies will require different approaches for redirecting, but the basic idea still applies: We will want to preserve the search data by issuing a 301 redirect to the mobile site.

SOLUTION 2

An alternate solution lies in server-side scripting in the site’s code itself. It’s the same basic approach as the previous solution, except this is totally built into the site itself rather than being handled in the site’s configuration file.  This may be a preferable solution since there are a number of PHP libraries for mobile detection, cutting out the legwork of trying to account for user agents on your own and freeing up what could be a massive .htaccess file. The following example will be in PHP (assumed to be placed in a header template for a site), and is including mobiledetect, but the basic idea should follow in other languages:

<?php
// See http://mobiledetect.net/
include('Mobile_Detect.php');
$detect = new Mobile_Detect();

if($detect->isMobile()){
  if(!$_COOKIE['no_mobile'] && !$_GET['from_mobile']){
    header("Location: http://m.website.com" . $_SERVER['REQUEST_URI']);
  }
  elseif(!$_COOKIE['no_mobile'] && $_GET['from_mobile']){
    // Set cookie to remain in desktop version of site.
    setcookie('no_mobile', 'true');
  }
}
?>

SOLUTION 3

Some clients may not have the “luxury” of server-side scripting on their hosts and will have to rely on a strictly JavaScript-based solution. It can work, but special precautions need to be taken to ensure correct functioning.

Google Analytics has a method to transfer cookies through a query string so that sites with different domains, but are united in ownership, can maintain continuity in data. The _link() method is essentially “glue” for cross-domain tracking in Analytics, but here, we can leverage it for our referral issues on the subdomain.

Normally, tracking a subdomain requires only explicitly setting the domain name in the implemented Analytics code, but since users in this case will not be sent to the subdomain with a 301 redirect or by manually following a link, Analytics will see this as a referral. If, instead, users are sent to the subdomain with a query string containing cookie data and the Analytics code is set to interpret this query string, the original search data will continue through this browsing session.

(The following is modified from the JavaScript used to take users to one of our client’s mobile site and is only an example of implementation.)

Modified Analytics script for both mobile and desktop versions of the site:

<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXXX-X']);
  // Setting domain name on mobile site
  _gaq.push(['_setDomainName', 'website.com']);
  // Processes query string with Analytics cookie info
  _gaq.push(['_setAllowLinker', true]);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script');
    ga.type = 'text/javascript';
    ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 
      'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(ga, s);
  })();
</script>

JavaScript for desktop version of site:

<script type="text/javascript">
setTimeout(function(){
  // Determine if user agent is mobile.
  var mobile_agent =
  (/iphone|ipod|android|blackberry|mini|silk|windows\sce|palm/i.
    test(navigator.userAgent.toLowerCase()));
  // If it's a mobile user ...
  if (mobile_agent) {
    if (
      (window.location.search.indexOf('from_mobile=true') == -1) 
      && !(document.cookie.indexOf('no_mobile') > -1)
    ) {
      try {
        // Analytics object should exist; use it to set link
        if (typeof (_gat) == 'object') {
          // Use actual Analytics ID instead of UA-XXXXXXX-X
          var pageTracker = _gat._createTracker("UA-XXXXXXXX-X");
          pageTracker._setAllowLinker(true);
          // ... and use the actual URL you are redirecting to.
          window.location = pageTracker._getLinkerUrl(
            'http://m.website.com/');
        // If the Analytics object doesn't exist, go anyway.
        } else {
          window.location = 'http://m.website.com/';
        }
      } catch (err) {
        window.location = 'http://m.website.com/';
      }
    } else if (
      window.location.search.indexOf('from_mobile=true') > -1) {
      var d = new Date();
      d.setTime(new Date().getTime() + (5 * 60 * 1000));
      document.cookie = 'no_mobile=true; expires=' + d.toUTCString() + ';'
    }
  }
}, 500);
</script>

With this setup, there is a chance that the Analytics data will not be passed along. The JavaScript for redirection with the query string should execute only after the Analytics cookies are set. As seen above, the JavaScript will call the _link() method if the _gat object exists, having been created by Google’s JavaScript; otherwise, the user will be carted to the subdomain, and a new session will be created.

(Note: The same basic treatment of cross-domain tracking should apply here with Google’s new Universal Analytics, but the JavaScript solution above will differ. Since most of our clients are sticking to Traditional Google Analytics for the time being, this solution still applies.)

An out-of-the-box solution for mobile site creation may be a quick way to engage the growing segment of mobile visitors, but be cautious in your implementation if you’d like to maintain accurate Analytics data.