This is good news for online marketers, as mobile devices provide increased opportunities (due to convenience and portability) for visits and conversions. But mobile users are also easily lost: upon arriving at a site which is not mobile-friendly, 61% of customers are likely to go to a competitor’s site. So what should we be doing to make sure that we’re ahead of the curve? And how can we be sure that our site is as useful for our mobile visitors as it is for those on a desktop? One way to gain insight into these questions is with Google Analytics (GA) data.

Part I: Overview

There are three types of web property for which you can track mobile traffic in Google Analytics:

a single URL site, which might be:

a non-mobile desktop site

a responsive/dynamically serving mobile-friendly site

a separate mobile site on a different URL (e.g. m.domain.com)

a mobile app

For a single URL site and a separate mobile site, the important metrics are usually the same:

visitors

keywords

bounce rate

traffic sources

landing pages

‘mobile’ report

These metrics enable us to answer major questions about our site and our mobile strategy, including:

Who are our mobile visitors? (mobile report)

What are mobile users looking for? (keywords)

Are they having trouble finding it? (landing page bounce rates, average time on page, page depth)

Google has recently introduced (in beta) a feature for tracking a mobile app. The ‘Mobile App Tracking’ feature uses slightly different terminology, but the concepts are similar:

Acquisitions = Traffic report

Users = Visitors report

Engagement = Visitors/Traffic reports

Outcomes = Conversions report

Questions we should be asking about our mobile app:

Are mobile users finding our app in the Google Play store? (Google Play sources)

How are they finding it (sources)?

Are they abandoning it after install or after opening? (users)

Is it crashing frequently? (engagement)

Is it performing better on certain devices? (users)

Are they converting better or worse than average/expected? (goals, transactions)

Is there a problem with the conversion funnel? (goals, transactions)

So how do we use these metrics/reports to find the answers to our questions?

Part II: Visual Guide

Desktop/Single URL/Responsive Tracking

The “Mobile” report on its own is somewhat limited. For example, you can’t view landing pages and also segment out just the mobile traffic (at least not with the default report). So instead, I often use advanced segments in the other reports to limit my data to mobile traffic.

The problem with the default ‘Mobile Traffic’ segment is that it includes tablet traffic as well. There is a default segment for ‘Tablet Traffic’ only, but in order to view mobile traffic without tablets you’ll need to create a custom segment.

The way we’ve done this for the Distilled analytics account is based on screen resolution and uses Regular Expressions (RegEx):

Name: ‘Mobile - no tablets’

Include: ‘Mobile (Including Tablet)’ containing ‘Yes’ AND

Exclude: ‘Screen Resolution’ Matching RegExp (1\d|[7-9])\d\d+x.*

What this RegEx means is that this custom segment should include traffic from mobile devices but exclude traffic from devices with a screen resolution of 700+ by anything. You may decide to tweak the RegEx depending on how large (or small) a device you want to include. (Some of the larger smartphones also fall in this range, but then again maybe these should be treated as tablets.)

Once you’ve got a sense for your mobile traffic, you’ll want to compare mobile and desktop traffic using multiple advanced segments. In addition to the non-tablet mobile custom segment, you may also need to create a ‘non-mobile’ segment: in this case, use ‘Include: Mobile; Containing: No’.

When we apply all three segments, we can see a graph which compares the difference between mobile, tablet, and desktop traffic:

This allows for a quick overview comparison of high-level metrics such as overall number of visits.

Using Analytics to Define a Mobile-Friendly Approach

If you’re just starting out to create a mobile-friendly website, you can use your regular site’s data to figure out the best approach (e.g. responsive, adaptive, or a separate mobile site).

Important metrics:

Visitors: what percentage is from mobile devices?

In the example above, only 5% of visits are from mobile, non-tablet devices. The proportion of mobile visitors can help in deciding how important a mobile-friendly strategy is to your overall online strategy. Even if this percentage is currently low, however, the numbers are increasing all the time, so whether it’s low priority or high priority, it should still be a priority. A low percentage of mobile visitors means you can afford to implement your mobile approach more gradually, with just the top pages, and build out as needed.

Keywords: is there a noticeable difference in search terms?

Organic keywords are a primary dimension in the Traffic Sources > Sources > Search > Organic report. A quick glance at top 10 mobile keywords compared with the top 10 non-mobile keywords should tell you whether people are finding your site using different keywords on mobile devices. If the mobile keywords are drastically different, you may want to consider a separate-site approach, which will allow you more freedom in optimising for mobile-friendly keywords. A middle-ground option is to serve different HTML on the same URL based on device, which allows you to have different meta descriptions and page titles when someone searches on a mobile device. If there is no real difference, however, you may choose to use a responsive design and simply re-arrange page elements to accommodate different screen sizes.

Bounce rate: is there a big difference between desktop and mobile visitors?

This data is in the Traffic Sources > Overview report:

If you see a significantly higher bounce rate for mobile devices compared to PC visitors, you need to make sure that your mobile visitors can access the content they’re looking for, and that they don’t have to pinch and zoom to do so. It may be, for instance, that your site navigation isn’t touch-friendly and so mobile visitors are stuck on the homepage/landing page.

Landing pages: which pages have a disproportionately high (or low) bounce rate for mobile devices? What about conversions?

The Landing Pages report is under Content > Site Content > Landing Pages. You can compare mobile and non-mobile bounce rates with those advanced segments. I also like to use the red-and-green ‘Comparison’ view for checking bounce rate because it’s a quick visual check of how each page is doing compared to the site average:

Remember that if your landing page is a blog post, as in the above example, a high bounce rate is normal. What matters here is not necessarily the actual metric, but the difference between mobile bounce rate and desktop bounce rate (although of course if you see an unusually high bounce rate across devices, that page may need to be investigated further).

Traffic Sources: is there a difference between desktop and mobile traffic sources?

This report is found under Traffic Sources > Sources > All Traffic. You will need to change the primary dimension to ‘Medium’. ‘Medium’ is the term for the highest level traffic types: direct traffic (here classified as “(none)”), organic and paid search, referral traffic, and any campaigns you’ve set up. This way (with your two custom advanced segments) you can see any discrepancies between mobile and desktop for the different traffic sources, and find out if you should be focusing on a particular traffic source with your mobile strategy:

This is an interesting example, because recently there has been an issue with some mobile referrer data. The iOS6 (iPhone/iPod operating system) uses Google's encrypted search by default and due to the way Google delivers its mobile SERPs this search traffic is recorded as direct traffic. Android 4 is also losing some referrer data. Some of the discrepancy here (showing direct traffic as 40% mobile and 16% desktop, vs referral traffic 17% vs 23%) could be due to this. All is not lost, however: Annie Cushing has created this custom report to help find your iOS6 traffic.

Site Speed: does your site take longer to load on mobile devices?

The Site Speed report is found under Content > Site Speed. The first thing to check is a mobile vs non-mobile comparison of average page load time.

We can’t take this metric too seriously, however, because it’s so easily skewed by a single instance of long load time. So if the load time looks unusually long, dig deeper into the particular page(s) having trouble.

If you do have a long load problem, consider whether large and difficult-to-load content (such as large images) is really adding anything to your site. If so, there are ways to minimise load time while maintaining the desired look for your site. Compress any images on the page as much as possible without lowering the quality, delete any unnecessary HTML or CSS, and compress those as well. If the mobile version of your site is responsive (or if you don’t have a mobile version at all), this will also clean up your desktop version. If you can’t compress enough elements to make a mobile page load in under 5 seconds, though, you may need a separate mobile site. Try testing your site(s) with the Google PageSpeed Insights tool. This tool provides information and recommendations for cutting down load times.

What about tablets? All of these metrics can also be used with the ‘Tablet Traffic’ advanced segment, in order to decide whether you need a separate tablet strategy. General best practice is to display the desktop version of the site to tablets, but this may be changing as screen sizes become more varied.

For more ideas on useful data for choosing a mobile-friendly approach, Aleyda Solis has written a post on how to perform a mobile site audit.

Some Extra Data for Tracking Responsive/Single URL Performance

Responsive Click Tracking

If you already have a responsively designed site, you may want to check that your call-to-action buttons are visible and effective when the page elements are rearranged to fit a smaller screen. Henry Zeitler has explained a way to track mobile clicks on a responsive site, which he terms “responsive click tracking”.

Setting Up a Custom Dashboard for Mobile Data

We can also create a custom dashboard exclusively for mobile data, and/or to compare our mobile traffic with our desktop traffic and look for areas which are over- or underperforming. This allows a quick check-in on all the different reports at once.

You can create your own custom dashboard, using the data we’ve looked at above, or use these basic sample dashboards that I’ve put together:

Comparing mobile data with desktop data: NOTE: to actually compare mobile and desktop data with this dashboard you need to apply the ‘non-tablet mobile traffic’ and the ‘non-mobile traffic’ custom advanced segments. Otherwise it will only display site-wide metrics.

Separate Mobile Site Tracking

Setting Up Tracking on a Separate Mobile Site

Many companies with a separate mobile site have not properly implemented their GA tracking code and are effectively losing the data from their mobile visitors. Mongoose Metrics did a recent study on the GA implementation of companies with separate mobile sites. Out of 75,000 websites, 41,344 had a separate mobile site and used GA tracking on their main website. Of these 41,344 sites using GA tracking, however, 37% aren’t tracking their mobile site at all!

Steps to implement GA on a separate mobile site

Implement tracking code on mobile site pages (as you would with a desktop site).

Set up a separate profile which only tracks traffic to the mobile subdomain. You should have a ‘default’ profile which contains all of the data from both the main site and the subdomain, a mobile-only profile which is limited to data from the mobile subdomain, and a desktop-only profile which is limited to data from the main desktop site.

The important reports and metrics for a separate mobile site are roughly the same as for a single URL site. Keywords are extra important because you have more freedom to create unique mobile-specific content. Site speed is also very important.

A couple more:

Redirects: do a quick check of the ‘mobile’ overview report in your mobile-only profile…if you’re getting a lot of non-mobile traffic to a separate mobile site, something is wrong with the redirects. (The same is true in reverse on the main site analytics.)

You’ll find this in Audience > Mobile > Overview:

Comparing mobile site visits to desktop site visits: you can use ‘hostname’ as a secondary dimension in your site’s unfiltered profile if you want to see m. visits versus www. visits.

The Mobile App Tracking implementation is a bit trickier to set up than web tracking: it requires the app developer’s input, using the Software Development Kit (SDK) for Android and iOS. The GA guidelines to best practice for setting up app tracking help you figure out whether to use multiple web properties to track your app.

Implementing the tracking code (2-part process):

Set up your new web property in the desired account: select “App”, and get your unique Tracking ID

Download the GA SDK for Android and/or iOS and add the code with your Tracking ID

Where are your users coming from when they download your app in the Google Play store? (Acquisitions > App Marketplace > Google Play > Sources)

Note that this particular report only uses acquisition data from the Google Play store. If your app is not offered on GP there will be no data available.

Are they abandoning it, either after install or after opening? (Engagement > Behavior > New vs Returning, Loyalty, Recency)

These three reports (New vs Returning, Loyalty, Recency) will help you figure out whether users are continuing to use the app after installation.

New vs Returning report:

You can check this report to see whether you need to focus your attention on retaining current users or reaching out to new users.

Loyalty report:

In this example, the user engagement is high, with a majority of users returning over 200 times. So in this case, perhaps the focus should be on encouraging new visitors and new downloads, as the app itself is good enough to retain them once they’ve downloaded it.

Recency report:

The report in this example shows that most users are using this app multiple times a day. The usefulness of the recency report, however, will depend on the purpose of the app. If it’s a social network, like Facebook, you’d expect visits multiple times a day. If it’s an app to find the nearest car dealership, you might not expect even the most dedicated customer to log in frequently. So remember that this report depends on context.

In this example, the iPhone sends 4 times as many visits as the iPad and iPod Touch, but also iPhone and iPad users are using the app for longer sessions than iPod users. These are discrepancies worth looking into.