Mobile User Experience, the Real 2015 Internet Trend

In her annual report for KPCB back in May, Mary Meeker cited a number of trends, statistics and metrics that show the increasing importance of online activity such as the growth in internet users to 39% of the population globally, the growth of mobile phone users to 73% penetration of the population globally (40% of that being on smartphones), the growth in mobile data traffic up 69% in the past year, the time adult users in the US spend online per day (mobile up 51%), and the implications of all of those various statistics for many businesses.

But in all of her 196 slides, the main thing she failed utterly to report on is how all of those metrics and business are affected by the performance of those online business and apps.

The problem is that it’s easy to take performance for granted, but if you look at all of the business metrics that Meeker cites, whether its messaging/notifications, user generated content (Pinterest Pins, Snapchat/Facebook Video uploads, live gaming streams, audio remixes etc.), just in-time products and services, and every other category of commerce, the amount and velocity of activity is directly affected by the performance of the sites and apps. In fact, performance is so critical to these statistics that Facebook explicitly cited it as the reason for re-architecting their mobile applications from hybrid HTML5 to native iOS and Android and the resulting improvements in their user engagement metrics they achieved due to the better performance.

But if there is one industry where the connection between performance and business results should be abundantly obvious, that has to be in retail. If your website is slow to load, especially on mobile devices, then customers will do less business with you or they may even abandon you completely.

This summer, AppDynamics teamed up with Internet Retailer to measure the homepage mobile performance at 3G and 4G network speeds of the top 500 retailers globally based on their revenue. IR provided AppDynamics with the URLs to measure, and we used our Browser Synthetic Monitoring product (now in beta) to measure the performance of the websites and record the results using our unique Speed Index and Visually Complete metrics in addition to a host of other values including the resources loaded per page, the first render times, and the complete size of the page (or page weight) in MegaBytes.

The results of these measurements are published as part of Internet Retailer’s 2016 Mobile 500 reference guide that was published this month both online and in print. In addition to industry trends and analysis, the database version of this guide provides a summary of key data about each of the 500 retailers, including financial, operational, and corporate summaries, and a snapshot of mobile site performance as measured by AppDynamics. The websites were measured at 30-minute intervals over the course of a week from locations in North America, Europe, and Asia with the Chrome browser and mobile network profiles.

Result Trends

What the measurements show is that there is a very broad spread in retail website performance. As you might expect, the best websites were visually complete in the 2-3 second range on 3G network profiles and 1-2 seconds on on 4G network profiles. At the extreme opposite end of the spectrum were sites that had average visually complete times on the order of 30, 40, and even close to 50 seconds, at both 3G and 4G network profile speeds. Needless to say, the likelihood that customers will be sticking around that long for a page to load starts to drops off dramatically. Studies by companies such as Google have shown that introducing delays of as little as 500 milliseconds into search results can start to have a seriously negative effect on revenue.

Strategies for Improving Website Performance

Among the better performing websites, there are three strategies that website operators can take to try to improve their site’s performance.

The first approach is to try to keep the size of the web page in general as small as possible. In general the data suggest that each megabyte of page size can cost you about six seconds of visually complete time at 3G network profile speeds. The best websites are able to do a bit better than that, but, the less well optimized sites can be way slower. For example, one athletic clothing retailer’s homepage had a page weight of 3.2 MB, yet a visually complete time of more than 34 seconds, or 10 seconds of visually complete time for each MB of page content.

Of course, keeping the page size small is particularly challenging for the retail sector because the natural tendency is to want to fill the page with lots of interesting and compelling product images or a fancy UI/UX experience to appeal to the consumer. But companies need to be very disciplined about understanding the performance impact of their graphics and UXD choices or they can quickly bloat the size of their pages, slowing them down, turning customers off due to the poor performance and thereby wasting all of the time, money, and effort they put into trying to attract customers to their site in the first place.

The second approach is to try to minimize the number the number of resources loaded per page view. The data shows that each resource loaded can carry a “performance” tax of anywhere from .05 seconds to .2 seconds, but should average around 0.1 seconds for the faster websites. website owners to be especially careful when it comes to loading third party resources as these can introduce significant delays. Again, the tradeoff is that third party resources can provide content or services that would be impractical or inefficient for the website itself to own (such as social media content and images) or which are tied to revenue generating strategies of the site such as advertising networks, but if they slow the site down to the point where users are abandoning the page, then it defeats the purpose of incorporating the resource.

Consider for example the 3G data for a popular retailer of video games whose home page had 248 resources, a page weight of 4.13 MB, and took just under 30 seconds to be visually complete due to the time it took to download all the images of games whereas another retailer of sports equipment had a homepage with a similar total page weight of 4.12 MB, but only 140 resources and a visually complete time about one third (10.3 seconds) of the video game retailer.

Most browsers only have eight independent simultaneous threads that they can use to download resources, so when your web page design has lots and lots of resources, the browser can get stuck cycling through its thread pool repeatedly, causing it to bog down and take longer than a site of similar size but with fewer resources to load.

A third approach is to carefully manage and optimize the order in which content is loaded on the site to provide the user with the best perceived experience of the website. This is where the speed index measurement of the site comes in as it provides a relative measure of performance that can differentiate among websites with similar visually complete times to show which site will be perceived by the customer to have better performance. It accomplishes this by measure the ratio of percentage of content delivered over time. For example, consider two website with the same visually complete time, yet website A renders 90% of its content in the first 10% of the visually complete time, while the website B only renders 10% of it’s content in the first 90% of the visually complete time and the last 90% of the content in the last 10% of the visually complete time. Website A will have a much faster speed index score since the user will perceive the website performance to be much better since they can see most of the content very quickly, whereas website B will be perceived to perform much worse and will have a much slower speed index score because the user had to wait so long to see most of the content even though both pages had the same visually complete time.

Looking at the 4G data, for example we see a popular furniture retailer with a visually complete time of 10.6 seconds and a speed index of 2.9 seconds compared to a another furniture retailer with a similar visually complete time of 10.5 seconds yet a speed score of 6.6 seconds. They both have similar visually complete times, but the users will perceive the former retailer’s website to be more than twice as performant than the latter retailer’s website.

Summary

Retailers face a host of contradictory requirements in designing and developing their sites to optimize their revenues and other business KPIs. To achieve the best results, retailers need to carefully consider how their design decisions affect the performance of their websites. Poor design decisions or ill-conceived trade-offs can result in web pages that can be very slow to load, causing today’s impatient consumers to abandon them.

To optimize their design process, retailers should consider using a Browser Synthetic Monitoring solution to see how their decisions and trade-offs are affecting their site performance and availability independently of all of the vagaries that can be associated with real-user performance monitoring.

By using Browser Synthetic Monitoring, companies can get a consistent baseline measure of their sites actual and end-user perceived performance to more accurately assess the impact of different design and implementation approaches.

Furthermore, by combining both Browser Synthetic and Browser Real-User Monitoring, companies can get a comprehensive view of their customers real and perceived experience to optimize their business goals, KPIs, and objectives.

Screen Shot 2015-08-21 at 1.54.20 PM

Image showing a snapshot of some measurements from the IR Mobile 500 report.

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.

16 Metrics to Ensure Mobile App Success: Part 2 User and Engagement Metrics

In my previous post, I discussed the value of monitoring performance metrics. Analyzing app crashes, API latency, application latency, app load per period, and network errors will ensure your app is running optimally and your users are able to access your mobile app in a timely manner. In this post we’ll dive into exactly how your users are using your app — where are they coming from, what device are they using, how often are they using your app, and more questions that you need to be asking to ultimately have a successful app.

As you recall from my last post, there are four categories 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

User, usage, & demographics metrics:

  1. MAU/DAU – The monthly active user (or daily active user) is a coarse metric that highlights the user base of the app. Keep track of your MAU’s and its trends (is it growing/shrinking/stagnant?) This metric is particularly important if your revenue model depends on advertising for which a large user base is required in order to be successful.

  2. Device and OS metrics – Apps are consumed on a wide variety of devices. You need to know how/where your key users use your apps – what devices (smartphones, tablets, IoT devices) and what OS/version (iOS 8? iOS 8.x? iOS 7.x, etc.) to focus your efforts on where your users are.

  3. Geo metrics – Don’t ignore the geography aspect of app usage. Are your users in the US (or is it outside the US)? Where do you see the usage within the US? Which states? This kind of data will enable you to identify issues faster. For example, if you have an app that targets a broader geography but only gets regional traction, you can now start to dig into the reasons why.

How to track these metrics?

Again, App Stores provides basic download data but lack real-time view into the true usage of the app. Look for solutions that provide instrument apps to track this information in real-time and with detailed device, OS, geography granularity.

Engagement metrics:

  1. Session length – Session length is measured as the time period between app open and close. It indicates how much time your users are spending in your app per individual session. The more engaged the users are, the longer their session length.

  2. Session interval – Session interval is the time between the user’s first session and their next one, showing the frequency with which your users open the app. This can signal the immediate value gained from downloading and running the app.

  3. Retention rate – We know that many apps are downloaded are never used more than once, but the value of the app or the experience wasn’t what it should be. Retention is measured as the percentage of users who return to your app based on the date of their first visit. Retention, or “cohort,” tracking highlights your most engaged – and valuable – users, creating better targeting opportunities and personalization of the app experience.

How to track these metrics?

Engagement metrics are provided by solutions that provide rich app analytics. Also, your notion of engagement may vary. Look for solutions that tracks these metrics out of the box, or can get these metrics with some customization.

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

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.

How to Build & Support a 5-Star Mobile App: Future Proofing Mobile App Strategy [VIDEO]

How can you plan and strategize your mobile app for the future? In the fifth, and final part of our video series, How to Build & Support a 5-Star Mobile App, we discuss how to ensure the future quality of your app and maintain success. Hopefully, you’ve put, or are planning to put, into practice what we’ve already established as necessary to build and support a 5-star mobile app.

If you haven’t seen the other parts of the series, Mobile Application Strategy Identifying Mobile OpportunitiesEnsuring the Quality of the Mobile App Experience, and Using Key Metrics to Optimize Mobile App Strategy, check them out now!

Audio only:

Interested to see how AppDynamics can help with your mobile app? Download a FREE trial today!

How to Build & Support a 5-Star Mobile App: Using Key Metrics to Optimize Mobile App Strategy [VIDEO]

DAU, MAU, crashes, stalls? Which metrics should you be analyzing to optimize your mobile app? In the fourth part of our video series, How to Build & Support a 5-Star Mobile App, we debate which metrics and KPIs should you look towards more measuring the success of your app? Obviously, the overarching metric you want is your app store rating, and how to make a 5-star mobile app. But how exactly can you get there?

If you haven’t seen the other parts of the series, Mobile Application Strategy, Identifying Mobile Opportunities, and Ensuring the Quality of the Mobile App Experience, check them out now!

Audio only:

Interested to see how AppDynamics can help with your mobile app? Download a FREE trial today!

How to Build & Support a 5-Star Mobile App: Ensuring Quality of the Mobile Application Experience [VIDEO]

In the third part of our video series, How to Build & Support a 5-Star Mobile App, we start discussing the importance of the user experience with a mobile app. Obviously, app store ratings play a large role in driving downloads and ultimately the success of your app. How can you create a coveted 5-star mobile app?

If you haven’t seen the first or second parts of the series, Mobile Application Strategy and Identifying Mobile Opportunities check it out now!

Audio only:

Interested to see how AppDynamics can help with your mobile app? Download a FREE trial today!

How to Build & Support a 5-Star Mobile App: Identifying Mobile Opportunities [VIDEO]

In our second video installment of the How to Build & Support a 5-Star Mobile App, we delve into the use cases where the mobile form factor is best leveraged. If you haven’t seen the first part of the series, Mobile Application Strategy, check it out now!

Jonah Kowall, John Rakowski, Kalyan Ramanathan, and I discuss mobile-specific use cases and how an app developer or app owner can build and strategize to maximize their apps success once it goes live in the App Store or Google Play. Enjoy!

Audio only:

Interested to see how AppDynamics can help with your mobile app? Download a FREE trial today!

How to Build & Support a 5-Star Mobile App: Mobile Application Strategy [VIDEO]

Recently, I sat down with John Rakowski, Jonah Kowall, and Kalyan Ramanathan to discuss the strategy and planning behind building and supporting a 5-star mobile app. It was a lively discussion given their previous experiences with Forrester, Gartner, and Crittercism, respectively. They all came into the panel with diverse opinions, which led to some interesting debates on how to prioritize and strategize for creating a successful mobile app.

This is the first part of the series, with more to come.

Audio only:

Interested to see how AppDynamics can help with your mobile app? Download a FREE trial today!