Mobile App Monitoring Best Practices

For many companies, and up until about just five years ago, the only metrics for how well a mobile app performed were network call errors and whether it crashed or not.

But those times are long behind us, as there’s nothing simple about today’s mobile apps. Issues are harder to find and fix than ever. Your app developers and quality engineers do testing before releasing the app to an app store. They go through all the common paths to find any issues or errors. But even with all this searching, it can still be difficult to find the source of an issue.

Technical complexity isn’t the only thing that’s exploded over the last five years — user expectations have become more complex as well. Mobile app crashes and network issues aren’t the only things that could result in what could be classified as a bad user experience.

An app could be technically operating, but that doesn’t mean it’s operating in a way that’s satisfactory to a user. Expectations have grown exponentially — primarily because the bar has been set so high. Users compare every app experience to some of the top players in the app store, like Facebook, Gmail, or Instagram, amongst others.

These extreme expectations go hand in hand with mobile apps because a good chunk of their business comes from organic user growth. About 30-50% of a mobile app’s users find the app by fiddling around in app stores like Google Play and Apple iTunes, or through advertisements. Unlike websites, mobile apps must be downloaded from app stores, and the app rating is displayed right at the top. This means that your business will lose out in mobile customer acquisition if you don’t have good ratings, regardless of how good your marketing strategy is. And obviously, good ratings come from satisfying user expectations.

To drill down a bit, here’s what a user is expecting from your mobile app, in addition to it being stable and error free.

  1. Highly responsive: Your app should load screens with content in less than 200 milliseconds, otherwise the application can be perceived as slow. Obviously, this number varies according to the geographical location of the user.
  2. Simplest experience to achieve a goal: Mobile apps should be built to achieve a goal in the simplest way possible because mobile devices have limited screen real estate and often suffer from limited attention span from users.
  3. Quick response to customer issues: Companies exchange hundreds of emails and spend multiple days to determine the source of an issue. For each customer, his or her issue is the most urgent one at that moment and should be addressed immediately.

During AppSphere 2016, I presented the following six best practices for mobile app monitoring with the goal of better meeting user expectations.

  1. Can you tell the health of your application in a second? You need to have a holistic view of your KPIs (key performance indicators). These KPIs must include crash rate, error rate, latencies, and a business metric (this could vary for different businesses, e.g., revenue, engagement, conversion, etc). The KPI view should be installed in every visible area of your mobile team section. Everybody should know the health of the application at any given minute.
  2. Whose problem is it anyway?  Always know a quick way to tell what’s causing the issue and what tools you should have to help you. If you’re consulting multiple teams to see if they know the root cause of the issue, then you’ve already lost your customer’s trust. Your users and customers see you as one company and not as multiple teams or processes. You should have ways to point out the exact line of code that’s causing the issue.
  3. Are you asking your customers too many questions? Empower the customer voice with technical context. When users or customers have a bad experience with your app and they reach out to you for help, the last thing you want to do is to ask them what flow they went through, the buttons they clicked, or the type of phone they used. You should have tools to tell you the exact flow a user went through and how your code behaved through this flow.
  4. Who’s using your app, and how are they different? Understand your customer environment. You should know the geographies your application is used in and consumer preferences in different regions.
  5. Can you reproduce issues with certainty? This is the funniest one. Often a manager would go to his or her engineer and ask to fix an issue, and the developer would come back to say, “I can’t reproduce this issue.” So, the problem just happens for limited users only and isn’t important? Well, you aren’t going to meet customer expectations with that excuse. You should have a way to tell exactly the way a user got to that problem, so you can follow the steps and reproduce and address the issue.
  6. “Are you creating apps for the fun of it?” You aren’t, so you should have a way to correlate business and application performance. When your application is down on conversion or customer retention, you should know if that was driven by application performance or the business value.

These best practices should lead you to view your application through the right lens and help you keep up with user expectations.

Learn More

Learn how our Mobile Real-User Monitoring solution can help you today. 

3 Strategies to Building Your Next Mobile App

Options are great – except when there are too many of them. It should be taught on the first day of Mobile App Development 101 that too many options will just paralyze and frustrate the user.

On a macro level, the same is true for all myriad options you face when it comes to building your mobile app. However, a comprehensive blog covering all of your options would be roughly the size of the internet. Instead, this guide will help you categorize your options and see a way forward, but you may still need to do more research to find the exact match for your skills and goals.

If you’re up in the air about how to build your mobile app, it helps to narrow it down to three options:

  1. Developing native, directly for iOS or Android
  2. A mobile-optimized development tool
  3. Some sort of hybrid approach

Here’s an overview of some advantages of the first option over the others.

When to Develop Native

The world of app development involves more than iOS or Android, but those two comprise 97 percent of the smartphone OS market. Developing native makes the most sense in one or both of those worlds.

Optimal Experience

When customer experience is paramount, nothing beats native. Apps built within the official app guidelines and within the proper ecosystem have a distinctive look and feel shared by all native apps. Typically, users will register this as a responsive, high-quality, intuitive app experience. You are also able to directly use any of the peculiar affordances of the device, such as the camera or the GPS, whereas in other approaches you may have indirect access through a variety of plug-ins.

App Store Placement

Some developers say that the biggest benefit is getting placed in the app store of the respective OS. Native apps will automatically be considered for inclusion on the app store. If you are using some other mechanism than native apps, then developers need to ensure that the output will produce an artifact which the app store will consider for approval.

After all, if you can’t be found in the app store, you’re basically wasting your time since it will be much more difficult for your potential audience to find your app if they have to go to some other source to find it, and it will take a lot more time, money, and effort to educate your potential audience about where to find your app. This may not be as much of big issue if your app is intended only for a private audience, such as a company’s internal stakeholders only, for which they may operate a private enterprise app store, vs. the general public.

The counter argument is that the app store is no replacement for marketing. Regardless, you have to get out there and promote it no matter where users go to download it. Unless it’s immediately popular, it could easily get buried amid all the other apps. The whole art of mobile app marketing and user acquisition, engagement, and retention is an entire subject unto itself, usually referred to as Mobile Growth. You can look for meetups in your area or entire conferences which are dedicated to the tools and techniques for acquiring and growing your app user base.

Regardless of your app store or mobile growth strategy, it won’t matter how many people download your app, all of your efforts for engagement, retention, UI/UX design, A/B testing etc. will be completely moot if the app doesn’t perform well. There are innumerable studies showing that consumers will delete or abandon an app/brand due to a single poor mobile experience, and app performance is one of the single largest contributors to the consumer’s experience of the app.

Ultra-Fast Graphics

Another differentiator where native apps excel is if your app depends on ultra-fast graphics. If you are creating a static, information-rich app, it won’t matter. On the other hand, native does better at handling animation and rapid refresh rates. On Android, in particular, you can program directly at the operating system layer using the NDK (native development kit) in conjunction with your Java Android app. You need native if you intend to have fluid access to high-level components like the camera and geolocation.

The biggest costs derive from the development time and the fact that you are tied to the OS. When it’s time to scale up and expand to another OS, you have to start all over again.

Security

Security is the second most quoted reason for going with native. The more moving parts, the more holes there are for cybercriminals to exploit. For the security of your native app, pay attention to the most common attack vectors that seek out weak SSL, unprotected data storage and areas where malware can deliver code injection. Also, make sure that you stay on top of the latest updates from the platform vendors, which frequently include security patches for vulnerabilities that have been identified. In some cases, your app may actually be removed from the store if it hasn’t been updated to include the latest fixes.

If your team has chosen to go native, your next decision is whether to start with iOS or Android. Here are a few considerations:

When to Go iOS Native

Apple continues to come in second in mobile market share, but the iOS app revenues are enormous. Depending on who you talk to, developers chalk it up to better quality or better branding. Strong engagement with loyal Apple users is certainly one of the top reasons to develop an iOS native app. In any case, the truth of the matter is that 94% of US app store revenue goes to the top 1% of monetizing publishers. Many developers say that the biggest benefit of iOS is a lower degree of fragmentation. You’re dealing with one manufacturer, instead of the wide range of different hardware types on Android. But even Apple now has devices in the market which can no longer run the latest versions of iOS, so you will have to make determinations if you will only support the latest devices and cease updating your app for older devices.

When to Go Android Native

Android is where many developers start due to the relative ease of working in Java. More importantly for most companies, Android has the largest user base around the world, not only in developed economies, but especially in developing countries where the much lower cost of Android handsets makes them much more attainable. This is particularly true in the largest growing market of China where there are also many local domestic Android handset OEMs.

If you are looking to expand to new markets and other countries, Android will get you much broader reach. And while each individual Android user may not monetise as highly as iOS, many strategies are linked to having a larger audience at lower ARPU.  If you’re going to go to Chrome OS in the future, Android is the logical place to start since Google is making it possible to run Android apps on Chromebooks. Even Microsoft is getting on the Android bandwagon with its acquisition of Xamarin, which can output Android apps (though not native).

When to Use a Hybrid-Native Mobile-Optimized Development Tool

When mobile was young, development tools that worked across platforms were the way to go. These tools became the preferred platforms for developers when skills were scarce for native programming. There was (and still is) intense pressure to get to market quickly and teams could use these tools to support both platforms from a single code base and development environment. These mobile-optimized tools helped developers collapse the learning curve and incorporate features and functionalities from other popular apps as they only had to learn one IDE but could create native apps for both major mobile OSs.

Today, these platforms are still popular for beginners who may be intimidated by trying to learn native development in Swift or Java and companies using a single dev team to support both iOS and Android or whose developers have existing programming and development skill sets that they are leveraging for mobile development. Here are a few of the most prevalent mobile-optimized tools on the market now:

1. PhoneGap

Adobe acquired this powerful, enterprise-level development tool a few years ago and it has flourished. Adobe also donated the open source project called Cordova to the Apache project where it continues to be developed and maintained with committers and contributors from both Adobe and many other companies. Both beginners and experienced web development professionals tend to love it because you can start from basic HTML and Javascript. Also, if you use the Cordova open source version, it is entirely free, but you also have the option to get advance for fee features with the Adobe version, which will appeal to many enterprises.

This technology essentially allows you to embed HTML5 apps in native containers, and it even includes plug-ins that allow you to access native affordances like cameras, gps etc. from javascript code. The main advantage of this approach is that it allows develops with skills in web applications to become mobile application develops. Many companies have web development teams that can now extend their capabilities to develop mobile applications. For many people, it’s also much simpler to learn HTML5, CSS, and Javascript than it is to learn a native IDE like xCode and Android studio and their respective programming languages.

There are also many projects such as Monaca that have developed entire UI/UX libraries that very closely resemble native design guidelines like Material Design, so that apps built using it look for all intents and purposes indistinguishable from native applications. Even more importantly, the ability to use the styling properties of CSS it makes possible to quickly and easily change the look and feel of these apps.

Of course, one of the disadvantages of this approach is that it relies upon having a web container embedded in a native wrapper. The embedded web container does not have any of the chrome of a stand alone web browser (which is why it can look like a native app), but it also doesn’t support the standard web timing and navigation APIs defined by the W3C, so it becomes much more difficult to monitor the performance of the app. The web container also can add significant overhead and may limit the ability of the app to work off-line without significant effort to use local storage.

2. Appcelerator Titanium

Over the years, Appcelerator has added capabilities like cloud services, mobile back-end as a service, a vast library of extensions, support for Node.js and crash analytics. Developers from all over can come together and work in the most popular languages, including HTML, PHP, JavaScript, Ruby and Python. Developers tend to love it or hate it, to the point where it has broken up application teams.

3. Kony

This is another one that’s been around for nearly a decade and has seen the app market flip from B2C to B2E. Kony is a good rough and ready system that always seems to be one step ahead of technology. Kony seems to be particularly useful to companies that can’t or don’t want to have dedicated native app development teams.

4. Xamarin

Nobody can say Microsoft isn’t trying. They seem to have turned on a dime from advocating for Windows Phone to pushing a cross platform app development IDE. Part of that strategy involved acquiring this independent app development environment which is based on the open source Mono project, though there has always been close collaboration with Microsoft over the years. It’s a good platform to help developers learn C# for native iOS or Android. Microsoft is still the standard in many large corporate environments and those types of companies tend to have internal developers who are skilled in using Visual Studio and .NET to develop both internal corporate apps and external customer facing applications.

Xamarin makes it possible for these types of developers to use their existing skill sets to develop mobile applications for the most common smartphone platforms. This is particular important since in many large enterprises, employees had already adopted these devices for their personal use, so it was not practical to mandate use of Windows Phone devices, which, in the end, Microsoft is now de-emphasizing with its recent write-offs in its phone hardware divisions. Given the tiny market share of Windows Phone devices, these companies were also hard pressed to produce apps iOS and Android, and they needed a way to do that with their existing teams and skill sets.

In the meantime, it gives you a clear cut, interactive dashboard with real-time metrics for the most common app KPIs, though there can still be some bugs, such as the problem with the way Xamarin wraps NSProxy. This can cause an issue if you want to monitor the performance of an iOS app produced using Xamarin, since you need to wrap the NSURLSessionDataDelegate in order to interpose on delegate operations so that its usage can be monitored.

When to Go With a Hybrid

More developers have turned to hybrid options over the past few years just to keep up with customer expectations. B2E moves fast and competition is fierce, so companies feel pressured to generate the user experience of a native app, but with the shorter development times and pre-built components of a mobile-optimized platform.

1. Ionic

Whenever developers mention hybrid, Ionic usually comes up among the top hybrid options. Some teams start out by building a CSS framework with the SASS extension language to contain the native look and feel. It’s built on HTML5, and AnjularJS is emerging as the go-to way to drive app features. The next gen Ionic will have drag-and-drop programming capabilities, so expect a flood of new developers to try it out. The community of Ionic developers is already strong and helpful.

2. React Native

Many developers have said that React Native is the closest thing to working in native, but with the addition of a framework and active support community. It was put together by Facebook developers, so the development itself is done entirely with a combination of React and Javascript. You have to come in with plenty of Javascript experience and know how to solve common app development issues around containers and APIs. On the other hand, if you want to build an app on both iOS and Android at the same time, and want performance that is close to native, this is a very useful tool.

It is somewhat ironic that this approach has come out of Facebook, since Facebook itself very publicly and spectacularly made a complete architecture switch from a hybrid native approach several years ago to fully native apps, and the main justification for making the switch was improved performance which resulted in very significant improvements in key business outcome KPIS such a the time spent in app, number of photos being uploaded etc. which are critical measures for Facebook that have a very direct influence on their bottom line which is dependent on selling ads.

There was much debate and discussion in the technical community at the time about whether or not Facebook’s hybrid implementation was the problem, and not the architecture choice itself. For example, some argued that Facebook had essentially just been cramming it’s website into a native container rather than explicitly programming it as a native/hybrid app from the ground up.

Of course, very, very few companies have the scale of a Facebook both in terms of the number of users (wouldn’t we all love to have the problem of a billion plus MAUs?) and the amount of the content being run through the app, so any performance hit from taking a hybrid approach is much less likely.

3. Mobile AngularUI

This is one of the new advanced hybrids. Mobile AngularUI is ideal for enterprise-level developers who are comfortable with Bootstrap 3 and AngularJS modules. However, it also has built-in mobile components like switches and overlays that aren’t in Bootstrap 3. If you’re not a fan of jQuery, this hybrid bypasses it for libraries like fastclick.js.

Summing Up

Native development in iOS or Android (or both) makes the most sense to take full advantage of the native capabilities and if you have development teams that are experienced in the native IDEs or you have hired a third party development house that can do the same. Mobile-optimized platforms like Appcelerator Titanium and native-hybrid Phonegap are best for single environment development teams and when devs don’t have the skill sets or inclination to learn Java and Swift. However, a hybrid approach using technologies like HTML5 can run the risk of making it harder to monitor the performance of your application, especially once it is in production. It can be a fast way to get a minimum viable product on both Android and iOS especially by leveraging existing skill sets from the web or other programming languages.

Regardless of what approach you take, it is imperative to monitor the performance of your app once it goes into production, so you can then iteratively upgrade and refine the app based on metrics and user feedback. It may be tempting to just rely on app store ratings and reviews to get feedback from your users on problems, bugs, crashes etc., but by that time it may already be too late if the user has deleted the app due to a poor performance experience. More over the poor ratings and reviews are public and may negatively influence other new users from even trying the app.

Consequently, no matter what approach you take, it is absolutely imperative that you have a strategy and plan for monitoring the performance of your app in real time.

We’d love to hear which route your dev team chose in the end and what were the deciding factors. If you used a mobile-optimized platform or a hybrid that wasn’t listed here, let us know in the comments what you found and how it worked out. Similarly, let us know about your experience in monitoring the performance of your application, and if you haven’t started yet, then get in touch so we can help you get going.

 

 

16 Metrics to Ensure Mobile App Success: Part 3 Business Metrics

In post 1, I walked you through the metrics 1 through 5 on how to properly monitor and analyze performance metrics. These stats include app crash rate, API latency, end-to-end application latency, app loads per period, and network errors. By properly monitoring and optimizing for these metrics, a mobile app development team can ensure their app performs at an optimal rate to best suit their user experience. 

However, in post 2, I took the analysis to the next step so you can adequately measure your user and engagement metrics. Statistics such as MAU/DAU, device and OS metrics, and geo metrics allow an app developer to understand their users and how they’re getting to the app. While metrics like session length, session interval, and retention rate allow you to understand how your users are using your app. 

Today, we’ll go into business metrics. The vast majority of app devs are here to make money, so how can you optimize your app to bring in the most revenue? 

Business metrics:

  1. Acquisition cost – Customers find your app through a wide variety of channels – organic search via the App Store, word-of-mouth, paid campaigns, or in-app referrals. This metric allows you see where users came from, but also how they behave once they start engaging with your app. The number of app downloads from a given source is important, but not as important as the value users drive when they’re immersed in the app experience.

  2. Transaction revenue – Transaction revenue is the value of transactions supported via the mobile app. While transaction revenue applies directly to apps that support mCommerce transactions (shopping, travel, financial services, etc.), it can also be approximated for non-commerce apps. For example, an app that supports a field service agent can be assumed to support $X of transactions per use (where $X is the cost of executing the transaction thru an alternate channel like phone call or a truck-roll)

  3. Abandonment rate – Abandonment rate is the ratio of transactions annulled to transactions initiated. Transactions may be abandoned due to a wide variety of reasons: the performance and experience of the app were not up to the user expectation, the app crashed, the user changed their mind, etc. Whatever the reason, it behooves the app team to understand the user journey and analyze why the transaction was abandoned.

  4. LTV – Lifetime value is your primary revenue metric, representing the value of the app and how much each app user is worth during their lifetime. LTV isn’t limited by whether you consider revenue as a dollar amount or some other metric like social sharing or articles read, and can be split by average monthly value or value per customer across all channels.

How to track these metrics?

The business metrics an enterprise cares about could vary dramatically from company to company. Find a solution that can track all these metrics without extensive app code rework.

16. The mother of all metrics – the app star rating

A note about app metrics wouldn’t be complete without paying homage to the most public of all metrics – the App Store ratings. No market provides such a public testament to an app and its effect on its customers. However flawed the system, users – prospective, existing, etc. – pay attention to this rating. A poorly rated app will bear consequences in the long run, so do all you can to improve your App Store rating.

Interested in getting insightful data and performance metrics? Check out a FREE trial of AppDynamics Mobile RUM today!

The Future of Mobile Payments

In my earlier post, I talked about the different methods mobile app developers can monetize their apps. Discussing the comparisons between free vs. paid apps, in-app purchases, and e-commerce apps. 

In this post I’d like to look towards the future. How can mobile developers best utilize the latest mobile e-commerce technology that’s being rolled out?

So what are the key mobile app e-commerce payment options looking like going forward in 2015? Well, according to Business Insider, mobile payments will likely be up to 15 percent of total payment volume in the US by 2019, meaning $818 Billion in transactions. It’s not surprising that all the major mobile tech companies are looking to provide mobile payment solutions for consumers, merchants, and mobile app developers. Here are some of the main options:

Samsung Pay

One of the somewhat surprising announcements at March’s annual gathering of the mobile tech industry at the Mobile World Congress in Barcelona, was Samsung’s announcement of their own payment mechanism called, Samsung Pay, (Really? Never would have guessed). The announcement is based on their acquisition of LoopPay in February, and it will be included on their new devices, also announced at the show.

Android Pay

This is a new payments mechanism targeted at mobile app developers with an API layer to support secure payments for companies on Android both in physical retail stores and in mobile apps. Google Wallet will continue as a separate product aimed at consumers.

Google also bought the assets of ISIS (renamed SoftCard), which had been an effort by the three major carriers in the US to implement their own alternative mobile payments mechanism. This represents another reason why mobile payments were slow to take off in the US because the carriers were eager to try and get a slice of the business for themselves, which they had started to roll out in a few select US cities. But the carriers weren’t having much more luck than Google, and with Apple getting into the fray with their system, the carriers were finally willing to see the writing on the wall and threw in the towel.

Apple Watch

Speaking of Apple, despite never going to MWC, they still stole the show with the Apple Watch announcement by saying that you would be able to make payments simply by tapping on your Apple Watch. This isn’t particularly interesting or innovative because it still requires that you have your iOS device with you, which already has Apple Pay on it. So the watch is really just a way of triggering the payment from your phone. If it is relying on the phone to connect to the terminal via the NFC chip, then the phone will have to be within several inches of the terminal to make the connection. This kind of defeats the purpose of using your watch in the first place.

PayPal

Not to be left out, now that PayPal is separating from eBay, they announced at MWC that they will be acquiring Paydiant, a startup developing technology for NFC-enabled card readers. They are planning to launch by the end of 2015 with card company CapitalOne, Subway, and MCX. Of course, potential success will depend on the number of retailers upgrading to NFC capable terminals beyond the current 220,000 already in the US, but as we saw earlier in the article, there are strong incentives coming for that.

Microsoft

Microsoft seems to be intent upon launching their own mobile payments system to compete with ApplePay and Google Wallet/Pay. The thought is is it’ll be included in Windows 10 OS and Windows Phones, but they are the underdog here and will have a seriously uphill battle particularly on the phone side given their small penetration and that desktop/laptop sales are flat if not decreasing.

Bottom Line

So, what does it all mean for mobile app developers?

The key thing to remember, which is where this all started, is conversion rates are vital to achieving your desired business outcomes. Since most enterprises are not in the mobile app business itself, their applications are designed to help monetize their products and services. The key to improving that monetization is to make all aspects of the payment possible as smooth and as simple as possible for the consumer. The less information the consumer has to enter, the better the conversion rate. Factors limiting mobile payments are primarily related to trust and convenience concerns and the critical mass of availability and adoption.

The new payment options will continue to be slow to take, but you need to start learning about them and preparing and planning for how you will utilize them in your apps and for your industry. Once we get into 2016 and beyond, it’s likely we could see rapid acceleration of mobile payment adoption.

Comparing Mobile App Monetization and Payments Methods

Just to set the stage for this blog post, according to BCG, Banks handled $410 Trillion (yes, with a T) dollars in non-cash payments in 2013.

These days, nearly all businesses are becoming software-defined, and much of that software business is increasingly becoming mobile business. According to a recent report by Akamai called the State of the Internet, “The volume of mobile data traffic jumped by 54 percent year over year, and grew 11 percent quarter over quarter”.

For mobile application developers, one of your key metrics to be concerned about is conversions. The whole reason you developed your app in the first place is to achieve a particular outcome. The conversion rate measures the number of customers/users that complete or accomplish a desired outcome. Of course, the desired outcome will vary greatly depending on the type of app you are developing. This typically means the desired outcome is trying to monetize your app in some fashion.

In this article, we’ll review the main monetization mechanism for mobile applications and the related options for payments. There are four types of monetization/payment strategies for mobile applications: direct, indirect, hybrid, and e-commerce payments. These options derive from the basic mechanics of how nearly all of the major mobile application stores operate.

Direct (Paid) App Monetization

When submitting your app to the App Store, you need to decide whether this will be a free, or paid app.

Now, if you choose the direct monetization mechanism, things are relatively simple and straight forward. The customer pays for your app, downloads it and you get paid directly by the App Store. Their cut of the fee is usually a 70/30 split between you and the App Store. In this case, you know your earnings are directly proportional to number of downloads you get. Your main task now is to try and drive as many downloads as you can by whatever means you can (usually marketing and promotion through any number of channels such as your website, paid search, Facebook App Install ads, etc.). How best to promote your app is a whole other topic in and of itself.

There are two main problems with the direct paid monetization model. The first problem is many users are reluctant or outright unwilling to pay for an app upfront just from the app store description and a few screen shots. This reluctance also varies depending on the platform. For example, iPhone users tend to be more willing to pay for apps upfront than Android users (regardless of the OEM of the device).

The second problem, especially for most enterprises, is selling mobile apps is not your core business. Rather, your company may be in any industry (Finance, Healthcare, Travel, Insurance, Automotive, Transportation, Services, Retail, etc.) and the mobile application is just a way for a customer to more easily and conveniently interact with or obtain your company’s services or products. Moreover, if you are in another industry, then the paid app store mechanism probably won’t even work for you because the margins on your products or services can probably not allow a 30% cut to be taken by the app store operator.

Indirect (Free) App Monetization

Given the resistance of consumers to pay for apps up front or your business is something other than selling mobile apps, the next monetization strategy if the indirect method of giving your app away for free and making money another way.

Obviously, it’s a lot easier to get a larger number of people to download your app if it is free. Although it is still incumbent upon you to market your app to build your audience. The most common monetization strategy for free apps is either to monetize the audience itself or to provide some other mechanism to make money from your customers.

If you do have a large audience of consumers, the most natural way to monetize that audience is to sell ads.

The mobile app advertising ecosystem has become increasingly sophisticated. All of the major platform providers have their own ad systems that app developers can integrate, and there are any number of third-party advertising networks that you can use. Many of these networks have advanced algorithms to try and match the availability of supply of ad opportunities with demand for ad placements through a process called real-time bidding and programmatic buying that seek to optimize revenue for the app developer and costs/exposure for the advertiser.

The trick for the app developer is to balance the need to make money from ads against the perceived annoyance of having to see ads by the user. The problem is even though mobile phone screens have been getting bigger, it is still a relatively very small piece of real estate through which they can interact with your content. Too many ads and you may cause users to abandon or even delete your app, or simply interact with your app less frequently. Which will be fewer opportunities for you to earn money from ads for that user.

In order to try and address these issues, there has been a lot of innovation in the mobile app ad industry to try and find ways to make mobile ads more amenable to app users. For example, the use of video ads had seen large increases because video tends to be more interesting to users than other types of banner type ads. However, you still have the same problem if the content of the video is irrelevant to a particular user, it could be even more annoying to them. Abandoning a video jeopardizes your monetization since some require their ad to be fully watched. Another option growing in popularity is “rewarded” ads where, by watching an ad or performing some sort of an action, the user is rewarded with some value that can be used within a game such as credits or virtual goods or currency.

Hybrid (Freemium) App Monetization

Perhaps one of the most popular monetization strategies is the hybrid, most often referred to as the freemium, model. In this approach, the app itself is free to download and use, making it much easier to build a larger audience. So how does the app developer make money? Well, only certain functionality is available for free. The basic functionality may be all that is needed for many users, but for some smaller percentage of users, they will want the additional features that can only be purchased and unlocked from within the app. For game type apps, the paid content may unlock advanced levels or make it possible to play faster, or without the interruption of ads, or to get better weapons or goods such as clothing. For other types of applications, the advanced features may consist of “pro” capabilities, like larger storage, or file sizes, or speeds, etc.

While the conversion rates for the freemium model can vary widely depending on the type of app, it’s not uncommon for the percentage of users who pay for in-app content to be in the single digits. Regardless, if the audience is large, even that small rate of paid usage can produce excellent monetization for the savvy developer.

E-commerce App Monetization

The main challenge with the e-commerce monetization model is your business has to have some other billing relationship with the customer independent of the app store. The reason this can be a challenge is if you don’t already have a pre-existing relationship with the customer, then obtaining the customer’s billing information through the mobile app itself tends to have a much lower conversion rate than it does if the information is initially obtained through some other channel, usually a desktop/laptop web app/site.

The reason for this is the well-proven phenomenon it’s still relatively inconvenient to enter a significant amount of information via a smartphone interface. In fact the probability of them completing the task drops off exponentially with the amount of information the user has to enter.

The main vehicle for e-commerce payments is with credit or debit cards. This is one of the factors that explains why iOS users tend to monetize better than Android users, because Apple did a much better job of collecting users credit card information in iTunes long before it even introduced the iPhone. Once Apple already had a significant number of credit cards for iTunes, it was natural to extend the mechanism for the purchase of apps in the App Store.

Unfortunately, Google did not have an equivalent system when they launched Android, and they’ve never been able to make as much progress. Also, at some level, consumers had a psychological expectation, set with search on the web, that services from Google are free, so why should they pay for anything? One could also argue that Google’s main reason for promulgating Android was to protect its search business and more and more consumers were moving to mobile devices as their primary on-line activity, so it has been suggested that direct commerce was always a secondary priority for Android.

While customers are becoming increasingly comfortable with online commerce, there are still many who are afraid of fraud, identity theft, or hacking (especially given some of the recent well-publicized incidents). These people are unwilling to give their credentials inside mobile app or to have them stored in an account with the vendor. This means that they have to enter their information each time, so it isn’t stored, but that also means that they are less likely to complete a transaction.

Given these challenges, the technology industry has been working hard to come up with mechanisms to make all of these issues and concerns easier both for consumers and vendors.

Why It’s So Difficult for Devs to Create Apps for the Apple Watch

Well, that didn’t take long. According to an article on Reuter’s some people are reporting their first impressions of the Apple Watch and, unsurprisingly, they are already complaining about the performance of the apps on the Apple Watch.

As an engineer who started my career working on real-time embedded systems for industrial automation, I can tell you what a Herculean task it can be to get a tiny piece of hardware to run very sophisticated software on comparatively low spec CPU. All the while having it execute quickly to provide a responsive end-user experience. The tradeoffs between cost, CPU capability and speed, power drain, software functionality are nearly impossible to navigate and satisfy all of your goals. There’s the old product managers joke that you’ve got three options: cheap, fast, and good, but you can only have two.

For developers creating applications for the Apple Watch or creating extensions for the Apple Watch for existing applications these complaints show two things:

  1. You have to completely re-think the nature of an Apple Watch app UI/UX
  2. You have to be laser focused on every aspect of your app that contributes to the performance of your app on the Apple Watch

Re-imaging UI/UX of apps for Wearables

One of the complaints in the article illustrates this point perfectly: “The maps app, surely the answer to wandering pedestrians’ dream, is so slow it makes me want to pull out my paper Rand McNally,” says The Wall Street Journal’s Geoffrey Fowler.

This seems to be a perfect example of not carefully examining the use case for an application and making sure that the UI/UX of the app has been properly redesigned to match the experience of the user. If I’m wandering around on foot, as Fowler supposes, then it makes no sense to have a complete maps UI on my watch, which would surely require a ton of data to be transferred from the phone to the watch and cause it to run very slowly.

Rather, the prime use case for pedestrian use of a maps app would be navigation, where the watch app is prompting me only with navigation cues such as “turn left on Main St. in 25 meters”, in which case the UI would be a simple as a left pointing arrow whose length is proportional to the distance remaining and a bit of text with the name of the next cross st.

As a developer or application product manager, your mantra should be Fit for Purpose. Don’t try and port your entire app UI to the watch. Only put that portion of the UI on the watch that is explicitly required for a particular action. Let the phone do what it does well, and let the watch do only the micro interaction required for a part of the workflow specific to using the watch.

Let’s look at another complaint from Nilay Patel of theverge.com who is quoted as saying “There’s virtually nothing I can’t do faster or better with access to a laptop or a phone except perhaps check the time.” Though the statement may be a sarcastic statement, it shows the underestimating the wearable UX.

To show just how silly Patel’s comment is, let’s look at the fitness use case. This is an example of where I think the Apple Watch has the potential to make health and fitness tracking appeal to the general public rather than just the niche market of fitness enthusiasts or quantified self-geeks.

Let’s consider the act of jogging, cycling, or even just walking. Now a lot of people already bring their phones with them when they exercise, and many of them even use specialized fitness apps like Strava, RunKeeper, MapMyFitness, MyFitnessPal etc. to track their activity, share it with friends via social media or even just listen to music while they are doing their activity.

But the key thing is that once the activity is started, the phone is usually tucked away in a pocket, a cycling jersey, a fanny pack, or even an armband, and anyone who has tried knows that its a pain in the neck to take your phone out to interact with the app while you are doing the activity.

Now, for a small niche of enthusiasts like myself and my triathlete friends, we will also wear specialized fitness trackers from Garmin or Timex on our wrists or attached to the handlebars of our bikes so we can see our data like pace, cadence, distance, elapsed exercise time, and power output.

But for the vast majority of the general public, they are not going to shell out another $300+ for a single purpose fitness tracking wearable. With the Apple Watch, on the other hand, one can easily imagine a significant number of people who would be willing to spend that money for a multipurpose device that connects to the apps on the phone and lets them interact with them naturally and easily while they are doing their various activities.

There’s no way, for example, that I’m going to pull out my very expensive and fragile iPhone (or even risk mounting on my handlebars) while I’m bombing down Panoramic Highway on Mt. Tam at 40 mph on my road bike in order to check my pace, but it would be quite simple for me to take a quick glance at my Apple Watch to see the data.

Laser Focus on App and Watch Kit Extension Performance

OK, for now, let’s assume that you’ve already carefully thought through your use cases, and now you are building your app and/or the WatchKit extension for your app.

According to the reviews published on Wednesday, the apps need upgrades to load more quickly. Again, the article says that Patel claims loading an app required the watch to pull tremendous amounts of data from iPhones.

No matter how carefully you’ve thought through the scenarios, you still need to know exactly what your app is doing and all of the factors that are contributing to the performance of the app during development, test, and production.

You need to understand how much data you are transferring and how long it’s taking.

Now you could try and instrument the app yourself with a bunch of timers and variables on your method calls, but that would be a waste of your time as a developer when you should be focused on implementing the features your users want that make sense for the watch.

Fortunately, this is where AppDynamics has you covered. With AppDynamics Mobile Real User Monitoring, you can get detailed data about how every aspect of your app and the Watch Kit Extension are performing and track the interactions of the extension with the Apple Watch.

Moreover, the AppDynamics Mobile RUM solution provides you with all of this information through a single portal where you can see how your users are distributed geographically, all the network requests and errors that are occurring, how long they are taking, how much data is being transferred, and you can dig down into any line of code and stack trace to see what’s happening in your app and how that is contributing to the end user experience.

Now get cracking on those apps and extensions for the Apple Watch, and sign up for a free trial of AppDynamics Mobile Real User Monitoring to make sure your apps are delivering the performance your customers deserve and expect.

16 Metrics to Ensure Mobile App Success: Part 1 Performance Metrics

Smart mobile teams know that developing and releasing a mobile app is just the first step in the long journey to delivering a successful and 5-star mobile app. If you have to make your app successful (however you define success – improved brand, more money, more engagement), you need to measure the right metrics, and optimize and iterate your apps to your target goals.

In this blog, we will explore the key app metrics to collect and analyze. But first, let’s break these metrics down into consumable chunks.

At a high level, there are four broad buckets of metrics you need to track for any app.

  • Performance metrics: These IT measures focus on how the user is experiencing the app.
  • User and usage metrics: These data points provide visibility into the user and their demographics
  • Engagement metrics: These metrics highlight how user are engaging with the app
  • Business metrics: Focus on business (revenue etc.) flowing thru the app

If you are wondering – these are a lot of metrics, where do I start? The ideal place to start is to analyze the performance metrics. These are the highest value experience metrics – and if you don’t get them right, the likelihood of finding a large set of users (and business success) will be challenging. After all, if the app doesn’t work well, i.e. crashes a lot or is very slow or unresponsive, why would users download it in droves or engage with it? There is a very clear and direct correlation between your application’s performance and achieving your desired business outcomes.

Screen Shot 2015-04-03 at 2.04.25 PM

Performance metrics

  1. App crashes – Everyone who uses mobile apps has experienced crashes at some point. Crash rate is the average crashes per app loads (an app load is the launch of an app). The typical crash rate is 1-2%, but this varies widely depending on the type of app, its usage, maturity, etc.
  2. API latency – Apps of today leverage several API’s or services. Latency refers to the round-trip time from a request to a response. The general rule of thumb is to optimize to around 1 second response time.
  3. End-to-end application latency – It’s not just enough to track API latencies; you also need end-to-end response time to applications that are powering the API’s. Again, the general rule of thumb is to optimize to around 1 second response time. Users may have some tolerance for slower response times, but the data generally shows that anything over 3-4 seconds total response time and the majority of user (60% or greater) will abandon the transaction and may even delete your app altogether. (Further reading: The App Attention Span Report)
  4. App load per period – This metric is related to the number of transactions or calls over a certain period of time. It is critical because you want to make sure that as the load increases, your application performance doesn’t degrade. Load can be very spiky in nature for some apps, so you need to know that your app can handle sudden changes in load without slowing down.
  5. Network errors – network errors are typically the service provider or HTTP errors seen by the app when the app is interfacing to a networked service. Network errors can lead to crashes or slow response time (with multiple retries).

How to get these metrics?

The App Stores (iTunes and Google Play) provides basic performance metrics. However, the metrics are very limited – with crash data only – and not real-time enough for enterprises to quickly troubleshoot and fix the issues. A few free vendor tools also provide basic crashes reporting capabilities, but mobile team would do better by not settling for just crash monitoring. App teams should look for solutions that provide a comprehensive set of metrics (crashes, app latencies, API latencies and application latencies) to solve all issues affect app end-user experience.

Interested in getting insightful data and performance metrics? Check out a FREE trial of AppDynamics Mobile RUM today!

3 Ways to Deliver 5-Star Mobile App Performance

Smart mobile teams know that delivering a 5-star app is more than just finding a good business use-case and designing an app with wow experience; it’s also about ensuring amazing app performance. Apps that perform well will engage the customer — poor app performance is a sure fire way to lose the customer and their business.

To deliver a first-rate app performance, mobile teams have to master the many variables which affect performance:

  • Mobile OS/devices: The various OS-es (Android, iOS, etc.) and device form-factors (smartphone, tablets, IoT devices, etc.) have unique performance characteristics that will affect app performance. A good mobile team optimizes for the OS and the platform
  • Mobile networks (WiFi, 2G/3G/4G) that provide the data connectivity: The average mobile app can be used on 10-20 networks (from various service providers and in various geographies) and it’s critical to ensure performance across all these networks.
  • API’s and services: API’s provide the core functionality of the app. Hence, the performance of the app is very dependent on the performance of third-party APIs. On average, a mobile app uses 5-10 API’s to provide its functionality.
  • Modern applications: The API’s are powered by back-end applications. These modern applications are complex with microservice architecture and abstractions like containers, virtualization, and cloud. It’s not uncommon for an application to have hundreds of components.

Screen Shot 2015-03-04 at 8.51.09 AM

With so many failure points (millions if you do the math!), it’s no wonder mobile teams focus more on the mobile ecosystem challenges and pay less attention to (or ignore) the back-end applications that supports the API. After all, “doesn’t the IT Ops manage the application?” is the constant reprise from most mobile teams.

But with the stakes of app performance so high, is this the right approach? In this blog, let me highlight three challenges with this approach and explain why end-to-end application-to-app performance management is critical for entire app experience.

1. Mobile transaction = app-application transaction

Mobile transactions are built on API’s powered by the application. So in effect, mobile transactions and their performance are tied to the performance of the back-end application. Mobile teams need to thoroughly understand these dependencies to manage the customer interactions in a more holistic manner. Only with an end-to-end app-to-application transaction visibility can mobile teams address questions such as:

      • What services and components (app servers, DB, servers, etc.) support the order processing transaction in the mobile app? What components should we focus on when the transaction performance has degraded?
      • What will be the effect of upgrading or changing a particular application component? What mobile transactions would it affect?

2. Proactive performance management and faster root cause analysis

With end-to-end visibility comes better monitoring and management. Now Ops and mobile teams can proactively identify app issues before it affects the end-user and quickly get to the root cause of issues after issues have been identified. For example, it now becomes easy to triage performance issues in these situations:

      • We made a change to the API servers. Is it improving or hurting the app performance?
      • We are seeing more app crashes in the order processing transaction. What services/components should we focus on?
      • Why is the checkout transaction slow? Which supporting components have performance issues?

3. Isolate effects of change and releases faster

In the mobile world, change happens all the time; in fact, 2-week app release have

become the norm now. To support the new app functionality, the back-end applications are also changing at a very rapid rate. With different teams managing the app and the application tiers, the change and release management process may seem a bit chaotic and may cause performance issues (after all, changes are responsible for 80% of all application health issues). So it is even more imperative to track all the changes across the application and the app tier. The app-application dependency needs to be tracked and mapped dynamically. The teams also need an integrated approach for change and performance management that makes it more effective to collaborate and identify change-related issues faster. Having an end-to-end app-to-application view will ensure this view and help address questions like:

      • The app performance has degraded. Is it because of the app or the application release?
      • How has the latest upgrade of the app/application affected the app performance.

In summary, app performance is extremely critical. 86% of users will delete an app after one poor experience. With such a high bar, it is vital that mobile teams focus on end-to-end app performance management to leave nothing to chance.

AppDynamics provides comprehensive end-to-end mobile app performance management. Not only does it monitor app issues like crashes, slowness, latencies, etc., but it also correlates these app issues to back-end application health. With this comprehensive visibility, customers can proactively manage performance and quickly identify the root cause of issues, thus ensuring amazing mobile experience.

If you want to try out the AppDynamics mobile solution, click here.

Bugs: The Secret Killer to 5-Star Mobile App Reviews

Bugs. Once upon a time – and not so very long ago – that word had only one meaning: annoying little critters that crawl, sting, bite, and can generally make your life a misery.

But in today’s modern technological age, the word bug has a new meaning: flaws in software applications. Though the word is the same, the two meanings are quite different. However, both terms represent a common theme: annoyances.

Bugs can wreak havocOptimized-iStock_000013467170_Small

The little bugs that infect computer code may not have wiped out millions of human lives – at least not yet (a computer bug reportedly nearly triggered World War III in the 1980s). But software errors certainly have caused deaths on a smaller scale through incidents such as aviation, traffic, and medical accidents.

For the most part, though, death isn’t a likely consequence of bugs infesting the code of modern apps. But other forms of devastation? Absolutely. In a recent study we conducted with IDC, we found downtime costs Fortune 1000 companies between $1.25 billion and $2.5 billion every year. (Interested in the full report, click here)

There’s also NASA, whose $327 million Mars Climate Orbiter disintegrated entering orbit around the Red Planet, the result of a coding error. Or check with Intel, they released an entire line CPUs in the 1990s containing a bug that caused an arithmetic error. Lots of red faces and an epic PR fail in addition to the cost in cash.

The point of these examples is to show no matter how small the issue, the results can be catastrophic.

When bad news can be good news

Sure, it’s bad to have bugs and issues in your application, however, they’re nearly unavoidable. Your home may be spotless, pristine, and clean as clean can be. Even so, there are bugs in your home. You can count on it. Same goes for the computer code your developers craft to power your app. It’ll contain bugs.

You can turn the bad news into good news by finding those bugs during the development process. Solving the most critical issues in the development and QA process is imperative.

However, once in production, it’s vital to be able to monitor your application and react accordingly to performance issues. In the same IDC report mentioned above, we found 13 percent of application failures last more than a full day. Doesn’t sound that terrifying until you realize the hourly cost of these downtimes ranges from $500,000 to $1 million PER HOUR.

The half-life of bad app reviews

Nowhere in the world is a review so prominent and vital to success as in mobile apps. Imagine if before you went to any restaurant you had to see their Yelp rating — it would probably affect your decision, right?

These aforementioned bugs now become nasty when they’re affecting your App Store rating. The success of your app hinges on this. In a different study we conducted with the University of London, we found 86% of users deleted an app after a poor performance (Read this report here). As we’ve been told countless times, “you never get a second chance at a first impression.”

What’s interesting, is the differences in tactics among the iOS App Store and Google Play. Since Google Play has fewer stringent rules on going live with an app — no intensive review process like the App Store — some independent developers can go live with their first iteration on their app and release new versions based on user feedback. However, they have this luxury because they’re independent devs and not major brands who’s image is reliant on a good product.

Major brands can’t simply iterate their product based on user feedback; they can’t afford that first wave of bad reviews. As a mobile evangelist, I’m constantly on the lookout for tools which can give me an insider’s perspective into my end-user’s behavior and how they’re using the app. These insights help me maintain a seamless app experience, react quickly to performance issues, and the most important part, preserve a good app store rating.

Interested to see how AppDynamics Mobile Real User Monitoring (RUM), can help you maintain your 5-star app? Download a FREE trial today!