A better way of collecting usage stats in mobile applications

Let me start by setting some context. As a part of my course requirements, I have performed a study on TCP connections of various mobile applications. An interesting phenomenon that caught my attention is the various usage measurement stats being collected by application publishers. Many apps were sending information about the application usage to remote servers periodically. In a research paper titled, “Profiling Resource Usage for Mobile Applications: A Cross-layer Approach”, I learnt that during the time that the handset takes to turn off the radio (IDLE state) after it detects silence for a threshold (this is called tail period) consumes equal amount of energy as to when the communication is active. Now, I see a problem with these usage stats collection services.

Services like AppFigures.com, Splunk MINT, Flurry, Count.ly, Localytics etc help app developers gain insights on how their app is being used. While it is a great idea to use these stats to optimize user experience, periodically sending out data can be bad to battery usage on your smartphones. Here is why –

Let’s consider a device has a tail time of around 5 seconds (most devices have a tail time of 12 seconds). Meaning, the device waits for 5 seconds before turning off the radio after it observes a silence period. Now, let’s consider an app which uses a measurement tracking service that collects user stats every 8 sec or whenever a user performs an action (say for example, a click).

Case 1: Let’s say the user didn’t click anything for 10 seconds. Now the stats collection service will send the stats report in a burst of data to the server after 8 seconds. So, the radio that was turned off after the 5th second, now got activated again due to the burst of data packets. A significant amount of power is wasted during the tail time + the power needed to re-activate the radio.

Dead Battery

Case 2: Let’s consider the case that the user performed a click on the app (a region where clicking doesn’t cause anything to happen on the front end, may be to ensure the screen doesn’t dim off) at the 4th second, the stats collection service sends the data to the servers which means again a burst of data and the count down of 5 seconds is stopped. The radio will not be turned off until 5 seconds after the data transfer to the stats collection server is complete. Meaning, the power consumption isn’t reduced even though there is apparently no change on the front-end.

Case 3: Let’s consider the scenario where despite of any action on the user’s end, the stats collection service send the metrics to the server every 4 seconds. This keeps the radio in transmission state through out the time the app is open. If this app is a gaming app, which you like and you play for a couple of hours every day, the battery is drained super fast not because of the game itself, but the background usage measurement collection service.

Here is what I think is a good way to collect stats while not draining the battery.

These services can collect the stats in the following ways –

1. If the app doesn’t get any data from the internet, say a static game application, collect the stats through out the time the app is open and then send all the collected data at once in a single burst when the user closes the app. Now, there is a chance that the app crashes and the close doesn’t happen in a proper way. In those cases, the app has to check for data collected but not transmitted upon re-opening and then send them right away. In this method, may be the stats are not real-time, but the developer can still get insights while not hurting the resource utilization on the handset.

2. If the app is, say, a music service, it periodically downloads some information like songs or playlist information etc from its server. The stats collection mechanism can use this window to relay the collected stats until that time from previous send. This way, the radio time used by the stats service will be during the radio time used by the actual app thereby not effecting the battery much. This is partially real-time depending upon the intervals in which the app uses the transmission radio.

The same mechanism can be used to ad networks that reload the ads after a certain period of time (say 120 sec). The ad-network module of the app can pre-load certain ads to rotate during the app open time when the app loads for the first time. Or it can also use the radio window of the original app to fetch new set of ads depending upon the need).

This is just my idea and I may be wrong. Comments are welcome.


Feng Qian , Zhaoguang Wang , Alexandre Gerber , Zhuoqing Mao , Subhabrata Sen , Oliver Spatscheck, Profiling resource usage for mobile applications: a cross-layer approach, Proceedings of the 9th international conference on Mobile systems, applications, and services, June 28-July 01, 2011, Bethesda, Maryland, USA

Leave a Reply

Your email address will not be published. Required fields are marked *