Blogs

Mobile Analytics – From Implementation to Analysis

By Aaron Maass posted 07-10-2014 10:31 AM

  

Intro to Mobile Analytics – how does it differ from the fixed web?

Now that we are into 2014 I am sure all of you understand how important mobile is to your business.  But just in case you have been in a cave or under a rock for the last 4 years, here are some pretty staggering statistics about the Mobile web.

  • 58% of all US consumers already own a smartphone.  Source - comScore
  • Over 1.2 billion people access the web from their mobile devices.  Source - Trinity Digital Marketing
  • 31% of adults own a tablet device.  Source - Pew Research Center
  • 80% of smartphone owners and 81% of tablet owners use their devices in front of the television. Source - eDigitalResearch 
  • Total mobile app downloads for the year 2017 is expected to hit almost 270 billion. (Chart below) – Source – Gartner

So as you can see mobile is here, it is growing and it needs to be part of your measurement plan.  However, measuring mobile is not the same as measuring your website.  Why?  Well the user experience on a mobile device is completely different then the experience on the fixed web, especially if you are using an app.

Not only is the user experience different but the data collection method is different depending on which tracking software you use and which platform your mobile app is available on, such as iOS or Android.

Along with data collection differences there are also metric differences.  Apps do not have pages in the traditional sense, they are more interactive and therefore how we measure and report on these applications is different.  But what isn’t different?

Your customer doesn’t change from the web to mobile so having a plan in place to measure customer behavior across devices is important to your long term success

Mobile SDKs – what they are and how to use them

Just as you would create a tagging plan for your website, you need to create a tagging plan for your mobile application.  This should begin while the app is still in wire frame development and you should meet with the business stakeholders to get an idea of everything that you want to track inside the application beyond the basics.  Once you have a tagging plan in place you can have your developers track everything necessary and you can move into the QA stage.

The first part to any mobile measurement plan is to ensure you are collecting the correct data.  The mobile SDK (Software Developer Kit) is the code that you will use to implement your tracking on your mobile app and is similar to the code that you implement on your fixed website from a high level standpoint.  What I mean by it being similar to the website tracking code is that they both collect data about user interaction and send that data back to your analytics servers.  The way they are implemented and the code itself are actually completely different but they both accomplish the same goals.

Each analytics platform, such as Google Analytics or Adobe Analytics, has its own SDKs and these could vary from operating system to operating system.  For example, Adobe currently has 8 SDKs available in their admin section, two for iOS, two for Android, one for Windows8, one for Blackberry, one for Symbian and one for Silverlight and Xbox.

Mobile QA – How do I QA an app on my phone?

So you have created your tagging plan for your app and your developer has taken this wonderful tagging plan and implemented it in the app and sent you the latest build of the app to test.  But you don’t have Charles or Fiddler  (or any other web debugging proxy) on your phone so how are you going to see what data is being passed in your app?  Great question!

You can actually proxy your phone through your computer and see the server calls that are being generated from the app in real time through your web debugging program.  How do you do this?  It is fairly easy and below is a step by step process.  We have also created a video that explains these steps which can be found here. https://www.youtube.com/watch?v=MoNiJjV5ZcU

Step One

Make sure that both your phone and your computer are running on the same network.  Next you have to know what your IP address is of the computer you are going to use to run the web debugging software.

Step Two

Once you have the IP address, you then need to set up manual proxy on your phone.  This is basically the same process on both iOS and Android.  You need to go to your settings on the phone and then to your wireless network.  You need to change your proxy setting from off to manual which is usually done through the advanced settings.

Step Three

For the proxy address you will input the IP address of your computer and most all web debugging programs run through port 8888 so you will need to enter that also.  Once that is done you are all set.  Open up your web debugging program on your computer, then open the app on your phone and you should start to see all the requests from your phone in the web debugger.  Happy QA’ing!

Measuring mobile – Reports and Analysis

So you created your tagging plan, your developer implemented the SDK, you QA’d the code and everything is being collected correctly.  Now it is time to create some reports for your app.  What types of metrics should you be using in your reports?  What do you consider success in your mobile app?  Success is going to differ from app to app but if you are reporting just unique visitors and app starts you aren’t doing it right.

So what metrics make the most sense for mobile apps?  Here is a good list for a start:

User Activity Rate – this will allow you to understand if your customers are continually using your app.  You want to divide the amount of app installs by the amount of unique users you have over a certain period of time.

User Activity Rate = App downloads/Unique Visitors

This sounds simple but not every download occurs on the same day so you will want to use segmentation to find out your retention rate.  For example, you would create a segment of users that downloaded the app on in the first week in September and then run a unique visitor report for the month of October with the September segment applied.  This will give you the amount of unique users that downloaded your app the first week of September but are still coming back in October to use the app.  You can set your time periods to whatever you like, just remember to use segmentation.

Retention Rate – this metric will allow you to understand if users are retaining or deleting your app.  It is calculated as follows:

Retention Rate – App Downloads/App Uninstalls

Very simple yet effective metric.  If this metric is negative then you know you have a huge issue.  More people are uninstalling your app than installing and you need to figure out why, and fast!

Engagement Rate – this metric will allow you to understand how many of your users are actually engaged with you app.  This is actually a combination of metrics that make up a segment which can be then trended over time to find out if you are gaining or losing engaged users.

  Engagement Rate = (F or TS or UI)

What does that mean?  It states that engagement is equal to a certain threshold of frequency(F), time spent(TS) or user interaction(UI).  You need to define what your threshold is for each of these items.  How often do you think an engaged user should open your app?  Every day?  Twice a day? How frequently should they return?

What about time spent, what should be the minimum amount of time they should spend in the app to be considered engaged?  5 minutes, 10 minutes?

Finally, user interaction.  What do you want the user to do the in app?  Watch a video? Share a story?  Play a game?  What actions indicate engagement?

Once you have defined these thresholds you can create a visitor segment to match each threshold in an OR statement to create your engaged visitor segment.  This segment can then be trended over time to understand if your mobile app visitor engagement is increasing or decreasing.

What these metrics and reports should all lead to is analysis.  Once you unearth an anomaly you can then dig deeper into the data to find out why it happened.

So why should you have a measurement plan, collect data, report on data and analyze the data around your mobile app?  Perhaps you could ask the makers of the app Candy Crush who are currently generating $875,382 a day (A DAY!!!!) from their best selling mobile app.

http://www.theweek.co.uk/games/57153/what-flappy-bird-new-app-taking-candy-crush

- See more at: http://maassmedia.com/blog/mobile-analytics-from-implementation-to-analysis/#sthash.vHEaSQj0.dpuf

Permalink

Most Recent Blogs

Log in to see this information

Either the content you're seeking doesn't exist or it requires proper authentication before viewing.