So, you have your shiny new mobile application completed, it has passed QA and you have submitted to the application marketplace for inclusion in their listing of available mobile applications. A month goes by and you have had hundreds of downloads. A couple of comments have been posted, pointing out some issues. But for all of the downloads your app has seen, you find that information on usage by your users and the errors they may have encountered is hard to come by. What you failed to think about was “service after the sale”.
Many mobile application developers have come from a web-application development environment where usage analytics of the web application was handled by the web server administrator and errors were logged to server files that were readily accessible. But with mobile native applications, the onus is back on the developer to include management tools within the app from the start.
There are a number of tools available to the developer to track analytics for either the Android or the iOS platforms. The first is Google Analytics for Mobile Apps and another is Adobe Omniture. Both provide mechanisms that can be embedded within the native application to track activity within mobile apps and report that activity to a central site for analytics analysis. With these SDKs, you can track how the app is being used through screen views, event processing, return visits of the app and custom data capture. In addition, there is device-specific data capture such as device type, and screen size. Wouldn’t you like to know who your application users are, which screens the user has used the most, trends in what devices and the screen resolutions are being used? With this information, you can focus improving the application in those areas and be aware of trends in application usage.
The other capability every non-trivial mobile application should contain is a mechanism for obtaining error information. If, heaven forbid, your application crashes, how will you know where to look even if the user bothers to inform you of the error? The developer can create either a process within the app whereby the error information is posted to a backend service or in the case of Android, take advantage of their Error Reporting services. Starting with 2.2 (Froyo), a “Report” button is integrated within the application error dialog box, and once clicked, a built-in error client process will analyze the offending mobile application and create a report with information needed to diagnose it the error. On the receiving end, Google collects the information and makes it available to developers along with tools to diagnose, triage and fix bugs in their applications. Whether focusing on roll-your-own or integrate pre-existing toolsets, it is imperative that developers acknowledge that errors will occur in their applications and plan accordingly to retrieve that error information in order to provide a superior user experience.
Service after the Sale
by Perry Hoekstra on June 14th, 2011 | ~ minute read
