Response Time Is Critical To Mobile Analytics Design

business-team-tablet.jpg

When you design for mobile analytics, the response time (sometimes also referred to as load time) will always come into question. The concept of fast loading pages is nothing new. Plenty of material exists on the web that covers everything from designing web sites to developing apps.

Every so often I am presented with this question: What is an acceptable response time for an mobile analytics asset? And my answer—“it depends”— generally causes confusion. This is often because the person asking the question is looking for a magic number of seconds that’s regularly quoted on the web by different surveys or studies.

But to provide consistent results can be more challenging than it may appear. There are several factors that will ultimately dictate our success. We can manage some of them through best practices. Others will be completely out of our control.

Let’s take a look at several pieces that may come into play.

Mobile network presents challenges for response time

Mobile analytics inherits many of the same challenges that exist with data-driven apps, which are at the mercy of the mobile networks that they run on. In a previous blog post, I referred to this network as the “digital bridge.” People frequently forget that this digital bridge can be made up of multiple networks and can lead to unreliable bandwidth.

In order to manage the challenges related to mobile networks, consider:

  • Displaying warning messages when a slow connection is detected. This is a common method used with many mobile apps that heavily rely on live wireless connections
  • Providing testing tools that your users can use to obtain objective feedback regarding connectivity, especially in remote locations
  • Promoting the offline feature to minimize the use of wireless connections for assets with less frequent data updates

Data vs. page load

Typically, the response time in traditional mobile analytics implementations is made up of two main parts. First is the data load, which includes the download of results from the database query. Second is the page load, which includes the necessary elements to display on the page.

In order to manage the challenges related to both pieces, consider:

  • Minimizing the query time by tuning the database objects. If the database query takes 60 seconds to return the results on your server, it’s not going to magically take less time on the mobile device.
  • Developing mobile-ready assets (reports and dashboards) with highly focused target deliverables instead of saving desktop reports that are designed for downloads to spreadsheets
  • Designing or leveraging options that can use advanced features to minimize multiple requests for the same report

Adjust based on your audience

One of the reasons why I always say that “it depends” is because the concept of response time is dictated more by user expectations or perception and less by the actual time it takes for the page to load. The terms fast and slow are relative depending on your audience. What may be acceptable to one set of users may not be to another.

In order to manage the perception, study the target user audiences to match the solution with their expectations:

  • With roles that are customer-facing and demand frequent travel, such as executive teams or sales, the expectation may be in single digits—especially if the solution is required for customer interactions
  • Users with analysts or research roles may be more tolerant due to their past experience and type of work

Bottom line

Unless you are taking advantage of new technologies, such as in-memory computing, you’ll need to successfully manage response time. Your users’ perceptions, which are largely influenced by their daily (and sometimes less complicated) experiences with their mobile devices, will have a direct impact on the success of your solution.

Stay tuned for my next blog in the Mobile Analytics Design series.

You may also like the Mobile BI Strategy series on IT Peer Network.

Connect with me on Twitter @KaanTurnali, LinkedIn and here on the IT Peer Network.

This story was originally published on turnali.com and also appeared on the SAP Analytics Blog.