Original article appeared in iMedia Connection
Using your smartphone to access the web is increasingly common. However, differences in the dimensions of the phone mean different experiences for users. Mobile traffic does not really represent new customers, but existing customers using an extra device or replacing their laptop with a smartphone. If your website doesn't suit mobile as well as it does computer then your conversion rate, and your bottom line, will fall. This is not yet an issue for most, but it will be one day for everyone. Unless a site happens to be suited to mobile traffic by luck, redesign and additional construction will be the only option to maintain current performance. This can require a considerable investment. Determining what will be needed to prepare your site for the smartphone revolution may be critical to the ongoing success of your business.
Many people I speak to are unwilling to face the issue of rising mobile traffic head-on. For them, it represents a threat: If it costs money and time, it's taking resources away from existing goals, for no additional benefit, merely to stand still. Others use the justification that people won't use mobile to visit their site, often comforting reasons, but rarely backed by research.
The thing to bear in mind is that no one really knows how far the rise of mobile will go, or how it will change things. If you scout the various projections, they all come out with mobile forming half of web traffic between 2013 and 2015.
Figures within specific industries can be very different. I have clients who get twice their national average, and others getting less than one-quarter. How closely your stats follow your national trends depends on the demographics of your market, and also how well your site suits mobile. Websites which perform badly on mobile tend to get a lower proportion of mobile traffic.
Don't assume you understand when people will use mobile or what they will use it for. I recently had a conversation with a design agency planning a B2B site for architects. Its assumption was that visitors to such sites would be unlikely to use mobiles for web access. The agency didn't have any reasons to back this up except that it thought mobile web access was mainly done by teenagers. However, it was forgetting about all the times architects get stuck in airports or taxis, and the chance of having a nice neat IT infrastructure on a construction site. Mobile web access is relatively new, so people's patterns of use are evolving just as people's use of the web did when it first started. At the same time, mobile infrastructure is undergoing rapid change, devices are evolving rapidly, and smartphone penetration is far from complete. All these factors mean it's still too early to have learned much about mobile web access. If you want to understand mobile usage of your sites, you're going to have to look for yourself. This means gathering your own metrics, establishing your own benchmarks, and watching for trends.
One thing to watch out for is the seemingly obvious, but incorrect, fact. There'll be plenty of these in the days to come. It seems intuitive that older people will use mobiles to surf the web less than younger people. While this is true, the difference is trivial: In 2011, 70 percent of people in the USA over the age of 65 used mobiles for internet access, compared with 76 percent of younger people. Sure there's a difference, but not enough of a difference to mean you can ignore older users.
The purpose of this article is to tell you how to track mobile activity, not how to design for mobile users, so I won't be going into detail about what makes a good mobile site versus what makes a good computer site. The key thing to take away at this point is that mobile internet is relatively new and that we have much to learn. You need to accept that some of your best ideas about how to do things online may need to change. What works on computer may not work on mobile. Your best designer for computer may make terrible mobile sites. The agency that knows web for the computer may simply be incapable of getting web for the mobile.
Tracking mobile with Google Analytics
There are two methods of tracking mobile visits to your website with Google Analytics. You can use the standard JavaScript tracking code, which will already be present in your site. However, you may prefer to use server-side code for mobiles: The JavaScript code makes several calls from the phone to Google, and may not work properly on slower mobile connections, or may get caught by anti-tracking or ad-blocking systems, or get blocked by the phone's security system. For this reason Google created a server-side code available here.
You need to be careful with the implementation of server-side tracking. Since the same script is called on every page, it can be one of the operations which places the heaviest load on the server. You need to ensure the server is correctly configured to anticipate this.
If you're building mobile apps, you can use the Google Analytics Mobile SDKs. There's one for Android and one for iOS. However, there's nothing for Windows Phone.
Developers need to be familiar with the traditional web-based tracking system which uses ga.js before they can implement the mobile app SDK. It needs to feed data into the existing GA system, which is designed for websites, not apps. This means hyperlinks clicked by people, different web pages with different URLs, and so on. The mobile widget tracking system needs to create "events" which can be described in such terms. So it is up to the developer to determine what constitutes a change of page -- or the clicking of a link -- and to pass that to Google Analytics. For this reason, if tracking is critical to the project, it's probably best to include it in the design process from the beginning. App tracking is more than just dumping some code in, it needs to be part of the application architecture.
In June, Google announced that it would be upgrading the mobile tracking SDK by the end of this summer (2012) to add tracking of features more relevant to mobile apps, such as in-app purchases and ad presentations. Right now Google is open to suggestions for additional features from existing app developers, so if you have an existing Android or iOS app, now's your chance to ask Google for features.
Getting reports from Google Analytics
Google provides a dedicated mobile section in the audience overview, but it is misleading and fairly useless. The main reason mobile traffic will react differently is that the screen on a smartphone is smaller and has very different height-width ratios. Some designs don't rearrange layout properly on such screens, and some graphics can't fit. However, Google Analytics treats tablets as mobile devices. Google Analytics used to treat iPod, iPad, and iPhone as different, but merged them into a single iOS at the end of May. The problem is that the screen dimensions for tablets are just like those of a computer -- iPads are typically running 768x1028, while the Samsung GT runs 1280x800. As a result, tablet users react to websites just like computer users.
The StatCounter data for growth of mobile traffic on the web is for smartphones, and does not include tablet devices. Smartphone, not tablet, activity is what will determine whether you need to upgrade your site. Including tablets in the same stats as smartphones renders such stats useless.
You need to bear this in mind all the time you are examining mobile in Google Analytics because every mobile figure it gives will include tablets. Some "mobile" reports will even include computer devices as well. If you want to use Google Analytics to track smartphone activity, you'll need to filter the results yourself every time.
For starters, don't be fooled into thinking the top-level graph of visits in the mobile report is actually about mobile visits -- it's not. It covers all visits, whether mobile or not. The same goes for the key numbers underneath (pages/visit, duration, bounce rate, etc.). All of these numbers, even though they're in the mobile report, actually cover all visits. You can see where the confusion comes from if you look at the first data table below these numbers. It lists stats for "Mobile=Yes" and "Mobile=No," which is everything. To limit the Mobile Overview Report to mobile devices, you need to add a filter of "yes" in the filter box:
Once this is done, you can use the secondary dimension to review things like search terms and originating site, but the mobile report isn't connected with essential data, like content, landing pages, conversion rate, revenue, or transactions. The mobile report is adequate for analyzing differences between different devices for some very basic stuff like bounce rate, but your best strategy is to forget the whole mobile report section and create a custom segment which you can use anywhere in Google Analytics.
Setting Google Analytics to report mobile
While there's a default segment for mobile visitors, there is no corresponding default segment for non-mobile visitors. If you want to compare mobile with non-mobile activity (and you do), you'll have to create a custom segment.
This is done by opening custom segments and selecting the include option, then selecting mobile, then adding "Containing No." If you don't want to make your own custom segment, you can use mine.
This will add my custom segment to your reports (but I won't see your data). If you've never picked up a shared segment like this before, clicking the link will take you to Google Analytics, where you'll see a message "An Advanced Segment configuration was shared with you." Simply click the profile you want to connect it with, and the segment will appear in your reporting interface:
Once you've done this, you can set your reports to process two segments -- "Mobile" from the default list, and "Non-mobile" from the custom segment list.
However, as we've seen, the default mobile segment in Google Analytics includes tablets. If you're OK with that, skip the next section. However, I recommend creating a segment which doesn't include iPad.
The difficulty is that you can't get at it directly. Stuff like iPhone versus iPad has been moved into a variable called "Mobile Devices Info" which you can't access via the API or segments. There has been much (unhappy) discussion about this in the Google Analytics forums. One participant, David Boyle, SVP consumer insight at EMI, reported that Google is aware of the problem, and is planning a fix, but there's been nothing official from Google.
David's come up with a neat workaround, which is to add a custom segment filtering iPad on the basis of screen resolution. The idea is to dump Google's default mobile segment, and make your own by combining "Include Mobile Containing Yes" with "Exclude Screen Resolution Containing 768x1028." While you can change the screen resolution on iPad, few people do, and this is the best solution I've seen so far.
Why filter iPad out of mobile?
iPad's performance is so different from other mobile devices that it makes it impossible to understand how your site works on smartphones. The bounce rate for mobile traffic on one of my client sites is 37 percent. If I filter iPad out, the bounce rate for mobile becomes 58 percent. iPad forms two-thirds of what Google Analytics reports as "mobile" traffic, and iPad performance on this site is identical to computer performance. Because of its volume, and the huge difference in performance, it totally masks what's going on with smartphones.
Download speed
Speed is a critical issue with mobile. Old timers on the web can remember the days when connection speed was an overriding design limitation. We had the "11-second rule" -- a page had to be completely rendered on the visitor's screen within 11 seconds or they would abandon the site. Design tools such as Dreamweaver constantly showed the total size of the page and its download time as an ever-present reminder to designers. As connection speeds improved, expectations rose, and the 11-second rule became the 8-second rule. Eventually broadband became so ubiquitous designers simply stopped worrying about anything so trivial as how long their masterpieces would take to render. The download time days are back with a vengeance. The 8-second rule becomes the 2-second rule: People will wait 2 seconds for your pages to render on a smartphone. If your pages take longer, people will start dropping out -- fast. Most shopping sites are so laden with graphics there is no way they can render on a mobile in 2 seconds.
The good folks at Google Analytics have added some additional metrics which directly addresses this issue by reporting download times. Rather than measure the download time of every page, Google Analytics samples a subset of your visitors. The average page download time is provided by the "AvgPageDownload" time metric, in "Content > Site Speed" section. Google Analytics also provides the sample size. It is important to recognize sample size is page views not people or visits. For example, 10 people viewing five pages each makes a sample size of 50 page views. This is a new feature, so you won't have much history, and it's possible you won't have information for many pages.
What do you want to know?
At this stage you only need to know two things: What percentage of your visits are mobile, and whether there is any performance difference between smartphone, tablet, and traditional visitors. Smartphone performance on some sites is appalling, while on others it's the same. If mobile performance is different on your site, you need to find out what the distinguishing characteristic is. It will most likely be screen resolution. If there is a difference, you need to track the growth of mobile on your site so you can determine when you will need to make changes to the site (or build a mobile site).
The impact of smartphones on the web will becoming significant and sites that ignore this significance will lose out. Start thinking mobile now.
There are two methods of tracking mobile visits to your website with Google Analytics. You can use the standard JavaScript tracking code, which will already be present in your site. However, you may prefer to use server-side code for mobiles: The JavaScript code makes several calls from the phone to Google, and may not work properly on slower mobile connections, or may get caught by anti-tracking or ad-blocking systems, or get blocked by the phone's security system. For this reason Google created a server-side code available here.
You need to be careful with the implementation of server-side tracking. Since the same script is called on every page, it can be one of the operations which places the heaviest load on the server. You need to ensure the server is correctly configured to anticipate this.
If you're building mobile apps, you can use the Google Analytics Mobile SDKs. There's one for Android and one for iOS. However, there's nothing for Windows Phone.
Developers need to be familiar with the traditional web-based tracking system which uses ga.js before they can implement the mobile app SDK. It needs to feed data into the existing GA system, which is designed for websites, not apps. This means hyperlinks clicked by people, different web pages with different URLs, and so on. The mobile widget tracking system needs to create "events" which can be described in such terms. So it is up to the developer to determine what constitutes a change of page -- or the clicking of a link -- and to pass that to Google Analytics. For this reason, if tracking is critical to the project, it's probably best to include it in the design process from the beginning. App tracking is more than just dumping some code in, it needs to be part of the application architecture.
In June, Google announced that it would be upgrading the mobile tracking SDK by the end of this summer (2012) to add tracking of features more relevant to mobile apps, such as in-app purchases and ad presentations. Right now Google is open to suggestions for additional features from existing app developers, so if you have an existing Android or iOS app, now's your chance to ask Google for features.
Getting reports from Google Analytics
Google provides a dedicated mobile section in the audience overview, but it is misleading and fairly useless. The main reason mobile traffic will react differently is that the screen on a smartphone is smaller and has very different height-width ratios. Some designs don't rearrange layout properly on such screens, and some graphics can't fit. However, Google Analytics treats tablets as mobile devices. Google Analytics used to treat iPod, iPad, and iPhone as different, but merged them into a single iOS at the end of May. The problem is that the screen dimensions for tablets are just like those of a computer -- iPads are typically running 768x1028, while the Samsung GT runs 1280x800. As a result, tablet users react to websites just like computer users.
The StatCounter data for growth of mobile traffic on the web is for smartphones, and does not include tablet devices. Smartphone, not tablet, activity is what will determine whether you need to upgrade your site. Including tablets in the same stats as smartphones renders such stats useless.
You need to bear this in mind all the time you are examining mobile in Google Analytics because every mobile figure it gives will include tablets. Some "mobile" reports will even include computer devices as well. If you want to use Google Analytics to track smartphone activity, you'll need to filter the results yourself every time.
For starters, don't be fooled into thinking the top-level graph of visits in the mobile report is actually about mobile visits -- it's not. It covers all visits, whether mobile or not. The same goes for the key numbers underneath (pages/visit, duration, bounce rate, etc.). All of these numbers, even though they're in the mobile report, actually cover all visits. You can see where the confusion comes from if you look at the first data table below these numbers. It lists stats for "Mobile=Yes" and "Mobile=No," which is everything. To limit the Mobile Overview Report to mobile devices, you need to add a filter of "yes" in the filter box:
Once this is done, you can use the secondary dimension to review things like search terms and originating site, but the mobile report isn't connected with essential data, like content, landing pages, conversion rate, revenue, or transactions. The mobile report is adequate for analyzing differences between different devices for some very basic stuff like bounce rate, but your best strategy is to forget the whole mobile report section and create a custom segment which you can use anywhere in Google Analytics.
Setting Google Analytics to report mobile
While there's a default segment for mobile visitors, there is no corresponding default segment for non-mobile visitors. If you want to compare mobile with non-mobile activity (and you do), you'll have to create a custom segment.
This is done by opening custom segments and selecting the include option, then selecting mobile, then adding "Containing No." If you don't want to make your own custom segment, you can use mine.
This will add my custom segment to your reports (but I won't see your data). If you've never picked up a shared segment like this before, clicking the link will take you to Google Analytics, where you'll see a message "An Advanced Segment configuration was shared with you." Simply click the profile you want to connect it with, and the segment will appear in your reporting interface:
Once you've done this, you can set your reports to process two segments -- "Mobile" from the default list, and "Non-mobile" from the custom segment list.
However, as we've seen, the default mobile segment in Google Analytics includes tablets. If you're OK with that, skip the next section. However, I recommend creating a segment which doesn't include iPad.
The difficulty is that you can't get at it directly. Stuff like iPhone versus iPad has been moved into a variable called "Mobile Devices Info" which you can't access via the API or segments. There has been much (unhappy) discussion about this in the Google Analytics forums. One participant, David Boyle, SVP consumer insight at EMI, reported that Google is aware of the problem, and is planning a fix, but there's been nothing official from Google.
David's come up with a neat workaround, which is to add a custom segment filtering iPad on the basis of screen resolution. The idea is to dump Google's default mobile segment, and make your own by combining "Include Mobile Containing Yes" with "Exclude Screen Resolution Containing 768x1028." While you can change the screen resolution on iPad, few people do, and this is the best solution I've seen so far.
Why filter iPad out of mobile?
iPad's performance is so different from other mobile devices that it makes it impossible to understand how your site works on smartphones. The bounce rate for mobile traffic on one of my client sites is 37 percent. If I filter iPad out, the bounce rate for mobile becomes 58 percent. iPad forms two-thirds of what Google Analytics reports as "mobile" traffic, and iPad performance on this site is identical to computer performance. Because of its volume, and the huge difference in performance, it totally masks what's going on with smartphones.
Download speed
Speed is a critical issue with mobile. Old timers on the web can remember the days when connection speed was an overriding design limitation. We had the "11-second rule" -- a page had to be completely rendered on the visitor's screen within 11 seconds or they would abandon the site. Design tools such as Dreamweaver constantly showed the total size of the page and its download time as an ever-present reminder to designers. As connection speeds improved, expectations rose, and the 11-second rule became the 8-second rule. Eventually broadband became so ubiquitous designers simply stopped worrying about anything so trivial as how long their masterpieces would take to render. The download time days are back with a vengeance. The 8-second rule becomes the 2-second rule: People will wait 2 seconds for your pages to render on a smartphone. If your pages take longer, people will start dropping out -- fast. Most shopping sites are so laden with graphics there is no way they can render on a mobile in 2 seconds.
The good folks at Google Analytics have added some additional metrics which directly addresses this issue by reporting download times. Rather than measure the download time of every page, Google Analytics samples a subset of your visitors. The average page download time is provided by the "AvgPageDownload" time metric, in "Content > Site Speed" section. Google Analytics also provides the sample size. It is important to recognize sample size is page views not people or visits. For example, 10 people viewing five pages each makes a sample size of 50 page views. This is a new feature, so you won't have much history, and it's possible you won't have information for many pages.
What do you want to know?
At this stage you only need to know two things: What percentage of your visits are mobile, and whether there is any performance difference between smartphone, tablet, and traditional visitors. Smartphone performance on some sites is appalling, while on others it's the same. If mobile performance is different on your site, you need to find out what the distinguishing characteristic is. It will most likely be screen resolution. If there is a difference, you need to track the growth of mobile on your site so you can determine when you will need to make changes to the site (or build a mobile site).
The impact of smartphones on the web will becoming significant and sites that ignore this significance will lose out. Start thinking mobile now.
