Regardless of whether you are fortunate enough to have had your app written up on a blog, received stellar ratings and reviews on the App Store, or achieved some of your initial goals, you’ll need to be diligent and proactive with ongoing development of your app. Whether you have tasted success or are still seeking it, you’ll need to keep interacting with customers and determine how your app should evolve over time...or if it should.
In this chapter, you’ll explore:
Monitoring feedback and analyzing your app’s performance
Keeping customers interested and involved in your app
Preparing and submitting updates to the App Store
Assessing the future of your app
Some congratulations are due if you’ve made it this far. Launching an app into the App Store the way you did is no small feat. You know, of course, that your job is not done yet. Depending on how everything proceeds, you may in fact just be starting your job...literally. Going forward, it’s possible that your app may allow you to dedicate much more time to it than before you shipped it. You could, for example, become focused exclusively on apps at work, have apps represent an extra or even a sole source of income (through sales or building apps for others), or just see them as a serious (yet fun) hobby.
That type of change will be influenced, in part, by how your app fares in the App Store. Everything you’ve done up to this point has put you in a position to be more successful than your competition. To continue to be at an advantage, you’ll need to recognize that you aren’t at the finish line yet and that there may indeed be no finish line. Before thinking too long-term, however, you’ll want to begin monitoring feedback and looking at the performance of your app once it’s available in the App Store.
More broadly, you can think about two types of feedback for your app: qualitative and quantitative. Qualitative feedback is what people will be saying about your app on websites, blogs, Twitter, App Store reviews, and other channels. This feedback may come directly to you, such as through email, or it may require you to be on the lookout for it, as with a blog review of your app.
Quantitative feedback is numerical in nature, consisting of analytics (you did install analytics as recommended in Chapter 7, right?) and data that Apple provides. By using qualitative and quantitative feedback in conjunction, you’ll have a very complete picture of how your app is performing.
Qualitative and quantitative feedback will provide actionable insight and often requires you to do more significant activities in response to it (e.g., fix or update your app). In this section, you’ll be focused exclusively on where to monitor and collect feedback. Taking more substantial action in response to this information will be covered in the next section. In the meantime, be sure you are answering support requests through Twitter, email, and other channels, as well as engaging customers and media where appropriate (e.g., commenting on a blog post that reviews your app).
Twitter acts as a gateway for what’s happening on the Web. This means you’ll be able to monitor what customers say about your app directly through mentions (when they send an update with “@<yourusername>”), and indirectly when, for example, a blogger may review your app and subsequently share that link on Twitter. The second situation is possible through monitoring keywords related to your app, which I wrote about in Chapter 8.
Once your app is launched, you may want to expand the keywords you are tracking based on how you see customers or the media discussing your app. Although your app probably has a core set of keywords that are most relevant, consider tracking keywords for specific features. Continue to experiment with what keywords to track based on the results that emerge. As you get more comfortable, include search operators to create more advanced and useful queries to track (http://search.twitter.com/operators).
Twitter will not catch every review or mention about your app on the Web. To help gain more comprehensive coverage, you will turn to Google Alerts (http://www.google.com/alerts).
Google Alerts (see Figure 9-1) is a powerful tool that, like Twitter, allows you to monitor keywords. The two differences are that Google will look across the entire Web (five categories, including news and video sources) and will send you results via email (or if you’re more technically inclined, an RSS feed). The alerts will include links to sites that have written or somehow reference something about your app or your app’s features, depending on what keywords you are monitoring.
The monitoring options are very customizable, allowing you to receive an alert immediately, once a day, or once a week. You can also specify the number of results you want in an email. The challenge with Google Alerts, which you also face to some extent with Twitter, is to make the keywords you monitor provide relevant results. Since the Web is considerably more expansive than Twitter alone, the likelihood of spam and irrelevant alerts is higher with Google Alerts. Beyond tweaking your keywords, as with Twitter, try using some of Google’s search operators to make your alerts more effective (http://www.google.com/help/cheatsheet.html).
Your customer reviews on the App Store can represent some of the richest feedback you’ll receive about your app. It’s typical for them to trend on the negative side—especially for $0.99 or free apps—because there is a low barrier to download them and price-sensitive customers will not read your application description. If you are mostly receiving one- or two-star ratings and poor reviews, though, it is a clear indication that there’s a problem with your app.
If there are outliers, and the majority of your reviews are positive, don’t lose your cool. In fact, you’ll want to be aggressive about engaging the most negative critics of your application.
Email is another of your most direct means to receive feedback. Unlike with customer reviews on the App Store, emails from customers require a response from you. Timely support responses are a key component of keeping your customers happy and engaged with your app. I will cover that aspect in more depth in the next section, but note that it should not prohibit you from answering any questions that may arise in the interim.
It’s possible that you have some other channels to receive qualitative customer feedback. For example, if you are in a larger organization, you may offer phone support. You may have also implemented a support tool mentioned in Chapter 5. In general, however, these are some of the key channels to monitor feedback about your app.
The quantitative side of feedback is numbers-based. You’ll be able to use information from Apple and your analytics provider to give you a broader, more data-driven perspective on how your app is doing.
iTunes Connect is where you’ll find all of the Apple-provided data about your app. The first place you can visit is the Sales and Trends area, which is available from the iTunes Connect home page. By clicking that link, you can preview or download the daily or weekly reports for your app, which shows information related to what app was downloaded, the number of downloads (Units), the royalty price (i.e., your portion of revenue from sales), and the currency and country code associated with the download or purchase. A Monthly Free report will also consolidate all free downloads into a monthly report that corresponds with financial periods.
Note that the daily and weekly reports represent trends and should not be considered the financial accounting for the royalties Apple will pay you for your paid app(s). You can find that information in the Financial Reports (discussed momentarily). The reports in this area are purged regularly by Apple, with the daily reports being removed after seven days and the weekly reports after 13 weeks. So, you’ll want to download and archive these reports somewhat regularly.
I’m going to bias you pretty heavily when it comes to the Apple-provided data. You will save yourself some serious headaches and frustration if you use a third-party tool to help interpret this data. The main reason is that these “reports” are really not reports at all, but instead are more like raw data. If you are very handy with spreadsheets, you can manipulate this data in something such as Microsoft Excel or Apple’s Numbers to make better sense of it.
Very intuitive tools are available, however, that provide actual sales reporting and simplify the iTunes Connect data download process. And depending on what analytics platform you implemented in your app, you may be able to see both your sales and your analytics data in one location. The analytics providers can often also collect other diagnostic information such as crash reports, or even help check for piracy (again, depending on how you integrated them). I’ll highlight the options I recommend in the following list, identifying the key differences among them.
Most cases of piracy occur in regions where an actual app sale would have never occurred in the first place. As a result, many developers don’t bother with piracy checks. If you do pursue them, your options include tools such as mtiks (http://www.mtiks.com/), plug-ins from analytics providers, or your own custom solutions.
AppViz is a paid Mac OS X application (offering a 30-day free trial) that was developed by Ideaswarm and will download your iTunes Connect application data and subsequently visualize it for you. Unlike what you receive in iTunes Connect, in AppViz you’ll be able to see data grouped by an app across all regions (which is particularly useful if you have several apps). AppViz can optionally pull in your iTunes reviews and ranking information, giving you a single dashboard to assess key feedback about your app.
Compared to AppViz, the distinctions for appFigures (see Figure 9-2) are that it is web-based, offers automatic daily syncing with iTunes Connect, and thus can deliver daily email reports of how your app is doing. Since you are going to be busy with your app, the latter two features are particularly useful. With appFigures, you won’t have to worry about your reports being purged by Apple before you obtain a copy of them, since they will be downloaded each day for you. Ariel Michael, the co-founder of appFigures, is interviewed at the end of this chapter.
Like appFigures, Heartbeat is web-based. One of the key differences is that depending on whether you choose to integrate Heartbeat into your app as your analytics provider, you can view both sales and analytics information in the Heartbeat dashboard.
TapMetrics is another analytics provider (and, like Heartbeat, is also mentioned in Chapter 7) that can give you a more comprehensive sales plus analytics display of your app’s performance. The TapMini tool (Mac OS X download) will automate your iTunes Connect download data and sync those reports with TapMetrics daily.
Data about downloads and sales only gives you a bird’s-eye perspective about the fact that customers are downloading your app. What it doesn’t help you understand is how many customers are actually using your app over time and what specifically they are doing in it. As you know from Chapter 7, that’s the reason analytics exist.
In general, the analytics you’ll want to pay attention to include the number of sessions for your app (where “session” represents one application open by a customer), sessions per month (also called “frequency of use” by platforms such as Flurry), average session length, number of active users, and number of new users (versus those who might have redownloaded your app). See Figure 9-3.
You may also be tracking a number of events in your app. Because the actions that are important for an app can vary widely, events are extremely important. So, if you didn’t initially add any events to track in your app (e.g., identifying when a customer uses a particular feature or completes a certain task), you should consider adding one or more to give you additional insight. Peter Farago, VP of marketing at Flurry, discusses what you should be learning from analytics and events at the end of this chapter.
Crash logs were mentioned in Chapter 6, as part of beta testing. At this point in your app’s existence, they serve as the most technical quantitative feedback you can receive. You can use the same methods described in that chapter to have your customers send you any crash logs generated by your app (see Figure 9-4); hopefully there are few, if any. Once your app is in the App Store, though, Apple provides a way to view the logs that were submitted by your customers through iTunes, which occurs in the background when they sync their devices (unless they previously opted out of this function). You can view these logs in iTunes Connect within the Version Information screen for a particular application by clicking Crash Reports.
A much more aggressive (and fairly uncommon) way to deal with crash logs is to intercept the events causing the application to crash when they occur, and then prompting a customer to send the reports directly to you when the app is reopened. To explore integrating this type of option, take a look at Plausible CrashReporter (http://code.google.com/p/plcrashreporter/) and MacDevCrashReporter (http://macdevcrashreports.com/). See Figure 9-5 for an example of the latter.
The third-party sales tools mentioned earlier can help you understand the actual payments you should receive from your paid apps. Because Apple has some unique accounting principles that affect when you can receive payments, it’s worth detailing them for you.
To start, select the Financial Reports link from the iTunes Connect home page. When you first visit this area, you will likely not see any reports. Apple only provides financial reports once a month, based on its fiscal calendar. When they’re available, you’ll find seven reports representing the United States (and Latin America), Canada, Europe, United Kingdom, Japan, Australia (and New Zealand), and “Rest of World.” Apple will only provide you a payment when your app sales in any given region are greater than $150. In such cases, you will also see a Payment Advise file for that region, indicating the payment that was made. When the $150 threshold is not met, Apple will withhold payment, rolling it over until the sales are greater than $150 for that particular region in a given fiscal month.
You should also note that payments are typically made three to four weeks after the close of a fiscal month. So, depending on when your app is purchased, it’s possible you might not receive your first check for at least two months. Apple’s most current fiscal calendar is available from the Sales and Trends area of iTunes Connect via the Fiscal Calendar link (see Figure 9-6).
By this point, you are going to be sorting through all types of information and data. As you did with the feedback you received through the pre-App Store development of your app, you should be funneling all of this feedback to make sense of it. This could be as simple as directing customers to a single support email address and internally managing a spreadsheet, or leveraging some number of tools that you implemented to interact with customers and track issues (as discussed in Chapter 5). The point is that after you monitor and collect this feedback, to make smart decisions about how to keep customers engaged you are going to need to prioritize and synthesize it all to make it actionable.
You’ve probably noticed that the qualitative insight supports the quantitative data and vice versa. It’s unlikely, for instance, that you had tens of thousands of downloads when your app launched, only to receive all negative reviews. You will, however, sometimes find anomalies or aberrations between the two, and when you do, you should hone in on why that’s the case.
To help make that happen, you need to have the same customer-focused mindset you had from the outset of this process and throughout your app’s existence. You may have a strong vision and instinct about what should happen with your ongoing app development, but keep listening to and learning from your customers. That’s particularly true of your most strident critics, who might tweet some frustration about your app or write a scathing review about it. Now, you should recognize that your app will never please all customers, and sometimes, no matter what you do, you won’t win over critics. But for each critic who is turned from a foe to a fan, your app will become that much better and less susceptible to these sorts of critiques.
I recommend that you facilitate discussions with some of your customers at least on a monthly basis once your app is in the App Store. These discussions should be prompted by you and could focus on how your customers are using your app, what they like and dislike about it, and what’s missing in it, and inquiring about what new apps they are using (whether competitive, complementary, or just interesting). These conversations don’t necessarily need to be as formal as what you did during the customer interviews. Your purpose with them is to ensure that you continue to have opportunities to listen to and learn from customers so that you can keep delivering on the promise of your application.
A very “cheap” way, at least in terms of actual development costs, to show your commitment to customers and keep them engaged is to obsessively answer their support questions and feature requests. I can’t tell you the number of times I’ve seen App Store reviews that talked about a developer’s responsiveness (e.g., “The developer responded to my email within 15 minutes”) or that were subsequently edited because a developer implemented a feature a customer requested. In many ways, even if your app is not perfect, you will earn goodwill with customers when providing them with outstanding support and being attentive to their needs.
When it comes to support specifically, set a goal for how long it should take you to respond to an inbound query. If you determine this to be five hours, for example, it doesn’t mean you will necessarily solve the problem within that time (unless that’s possible). Instead, you’ll at least acknowledge that you received the request and are working on it. If you have a dedicated support email inbox, you might want to create an auto-reply, indicating your support hours and typical response time. Third-party customer support solutions such as ZenDesk and Tender will automatically assign a ticket to a customer issue and send the customer an email from a template you create.
It is worth reiterating that one benefit of support solutions is that customers will always have visibility into the status of their issue(s). Giving customers this type of real-time transparency helps set their expectation regarding response times while also providing them the confidence that their inquiries are indeed being tracked. Whether through email, Twitter, or other channels, do your best not to keep your customers hanging. Although that’s always been true, it’s particularly important in an “on-demand” world.
Altering the App Store listing for your app can have a positive impact on the interest in your app by highlighting press reviews (see Figure 9-7), awards, or new and upcoming features. You can change a number of items in the App Store without submitting an actual app update (i.e., a new binary) to Apple. The allowable changes include editing the App Store description, URLs (application and support), contact email address, application icon and screenshots, and price. Changing these elements may seem trivial, but they can have a big effect individually and even more so when combined. You can edit these items by selecting Manage Your Applications from the home page of iTunes Connect, choosing the desired app, and then clicking the Edit Information button.
As touched on in Chapter 8, some of the more useful changes you can make include incorporating quotes from customers and reviewers in your App Store description, including “What’s Coming” in the App Store description to highlight the features you are working on, or testing different pricing points, whether as a promotion or to find what spurs the most demand. Click Save Changes at the bottom of the screen, and the changes will usually appear within several hours on the App Store.
For the most part, submitting updates for your app is the best way to keep your customers engaged. These updates may respond to customer feature requests and criticisms, fix bugs, or simply execute on your vision and roadmap for your app. In all cases, these updates will show that you are actively maintaining the app and are committed to improving it. Of course, you’ll need to identify what goes into an update, test and get feedback on an update, and subsequently submit the update to Apple. Much of that will flow from what you’ve done to this point in the development of your app, but I’ll outline some update-specific information now.
There are many different ways to approach how you release updates for your app. Some developers release updates weekly while others may take months. There’s no right or wrong way to do it necessarily. What’s more important is to be clear about what you are working on and be consistent on when you indicate you are going to release your updates.
A good way to approach setting the scope of your updates is to add to and reprioritize your app’s backlog features from your roadmap with the qualitative and quantitative feedback you have for your app (see the section Creating your initial roadmap in Chapter 5). If “feature X” is the most requested item from customers but it’s currently ranked low on the backlog, its importance should be reassessed. Similarly, if your analytics indicate that customers are not using a particular feature that you were planning to expand, you might consider spending your energies elsewhere.
You’re going to need to constantly balance working on more significant features with resolving critical issues or getting easy wins in your app. If your app is currently crashing under certain common conditions, you’ll need to focus all your attention on getting that update submitted immediately. Similarly, if a large amount of customer feedback concerns complaints about the size of a button, you can easily resolve that and thereby reduce noise for you while making customers happy. As discussed previously, you can categorize these types of updates with either bug fix or minor version number changes (e.g., 1.0.1 or 1.1) when you submit the update to Apple.
As I wrote before, readjusting your roadmap based on feedback is something you’ll do frequently. It matches the same paradigm you used to initially build your app; you’ll continue to start with your own assumptions and then validate them against customer input and the data you have at your disposal.
It’s a good practice to test your updates the same way you did leading up to the initial release of your app. In fact, you may have learned a thing or two after launching your app, so be sure to incorporate those lessons as you begin testing your update internally and with customers.
As with the pre-App Store version of your app, you’ll need to test your update with customers who have provided their UDIDs. If you still have some of the 100 device spaces left in the iOS Provisioning Portal, you may want to add some new customers. In either case, you’ll still need to follow the ad hoc distribution process to put your update into your customers’ hands (see the section UDID in Chapter 6) for them to test it outside the App Store.
You should only send your app update to customers who previously agreed to continue testing your app. When you send it to them, as you did during the beta testing, let them know what is new, updated, fixed, or outstanding. These release notes will also be used when you submit your update to Apple.
Getting an update for your app submitted to Apple is relatively straightforward. To submit your update, you’ll need the following information:
Try to adhere to the major version.minor version.bug fix paradigm (see the Release Numbering sidebar in Chapter 5). This number should match what your developer specified inside your updated app’s binary.
You are allowed to change the application name when submitting a new binary. There’s a good chance there’s no reason to, but you may want to experiment with a more descriptive name. For example, I tested “Tweeb - Twitter analytics” versus “Tweeb” and saw varying impacts on downloads.
Keywords are another element that is editable when you submit a new binary. As with your application name, you should experiment as needed.
These are your release notes. They will appear to those who have already installed your app in the Updates area of the App Store. If you have a Universal app, group this information by application version (i.e., iPhone and iPad). Also, use categories to help identify new features versus bug fixes. I recommend using “New,” “Updated,” and “Fixed.” Some developers include the release notes from the past several updates, which is especially useful if updates are being produced regularly. You may also consider including this information in the app itself (see Figure 9-8 and Figure 9-9).
This represents the binary for your app update. Ensure that your developer uses the same credentials that created the initial app (technically, the same distribution provisioning profile) when building the binary update. Again, the version number in the binary should also match what you are submitting in the Version Number section in iTunes Connect.
Once you have this information available, you will again select Manage Your Applications from the home page of iTunes Connect and choose the desired app. From there, click the Add Version button under the Versions section of that particular app’s App Summary screen. The next screen will only request the Version Number and What’s New in this Version information. If you also want to edit the Name or Keywords, you’ll need to revisit the newly created entry (click the View Details button for this version—New Version—of your application on the App Summary screen) and edit either the Version Information section for the application name or the Metadata section for the keywords. Submit the updated binary through the Application Uploader, as you did when first submitting the app (see the App Summary and binary upload section in Chapter 7).
Upon your update being approved, you will receive a fresh set of 50 promo codes (awesome!) and a reset of your ratings for the current version of the app (not so awesome!). The ratings reset can temporarily impact your download and sales numbers, but if your update is seen as valuable to customers, they should rebound within a week or so. This cycle means you should largely focus your updates on critical bug fixes or major feature releases. For another perspective, check out Apple’s guidance on how frequently to submit app updates (https://developer.apple.com/ios/appstore/managing.html#submit).
It is important to share what you are working on with your app in all of the usual channels. This includes not only editing your App Store description, as mentioned earlier, but also sharing this progress on Twitter, your blog, your website, your email newsletter, and similar outlets.
If you haven’t figured it out yet, the same strategies you’ve used throughout the marketing and development process will continue to be useful. This can include teaser previews of new screens or features, reaching out to review sites when you are about to launch a major update, or distributing promo codes.
Considering the two extremes of either engaging with customers too much or being completely absent, you are better off with the first over the second. Apps that go months without any updates and no communication from developers are usually considered abandoned. Existing customers will let prospective customers know of that perception and scare off downloads by discussing your lack of interaction and updates in their reviews. Don’t let that happen.
When you first began this journey, I asked you to do your best to quantify your app by thinking about your app’s goals and potential (its addressable market). By the time you’ve done a couple of updates and your app has been in the store for three to four weeks, you should start to have enough data to consider how your app is doing relative to those initial goals and estimates.
It’s possible that you might be shocked—in a good or a bad way—when you take a step back and compare your initial analysis with the reality of the data you now have. Depending on this comparison over time, you may soon be at a crossroads where you need to determine whether your app is a worthwhile investment or a lost cause. Regardless of what becomes apparent, do not be discouraged; even the top apps in the App Store don’t stay on top forever.
Determining the health of an app can vary drastically from app to app, but there are some broader warning signals that indicate your app is on a path to its demise. Although this list is not exhaustive, it should help you to recognize patterns that indicate your app is headed for trouble within its first two weeks of launching.
Yes, it’s a “duh” signal, but worth mentioning. If your app has been out for several weeks and has no or very few downloads or sales, that’s a problem. Although I am tempted to ask that you keep trying for press and media attention, it’s likely that there’s a more systematic problem with your app. Reach out to customers and advocates and find out if there are any issues with your app. Ask why they did or did not download your app.
If you have no App Store reviews, it’s a sign that your customers aren’t very engaged with your application. That’s especially true if you specifically requested reviews. It’s possible that your customers are busy, but it’s also possible that they just don’t find your application interesting or useful enough to take the time to review it. Find out if that’s the case and ask how you can change that.
Although not common, some apps receive hundreds or thousands of downloads when they are first released, but then receive an excessive number of negative reviews. Typically, this occurs because customers feel deceived about what the app is about or the app has major bugs and performance issues. A developer who doesn’t recognize the problems and fails to quickly address them directly (e.g., through the App Store listing) is destined for failure.
Your analytics will tell you how often your customers are using your application. The general trend on the App Store is that many apps will be used less and less over the first 30 days. But if your app’s frequency of use seems to be dropping at an alarming rate, it may be perceived as a gimmick (of course, that’s OK if you have a “gimmick” or “seasonal” app) or as something that lacks long-term value.
Remember, there’s a difference between new users and active users. If your app is being downloaded consistently but its analytics show that most customers using your app are new users, your app is clearly not delivering on the feature set or experience you’ve described in the App Store.
If your business model is to entice customers to buy features, credits, or virtual goods, you’ll want to see a good conversion rate of free to In App Purchase. A low number could mean you have not implemented In App Purchases in an intuitive manner or that you did not compellingly break down the free and paid features of your app.
If you are receiving a very low number of customer inquiries through Twitter, email, and other channels, it’s unlikely that this is happening because your app is perfect. Instead, customers probably aren’t using your app frequently or simply don’t care enough to send you any ideas to improve or fix it.
You will be able to track how many customers update your application. If you’ve shipped two or three updates to Apple and you’ve noticed that there’s a low number of updates compared to the total number of users for your application, customers may be not using your app or are not finding your updates worth installing.
I’m a little hesitant to suggest that no media reviews is problematic, because it is hard to get a review today. Still, if you followed my previous advice, you should be getting some kind of attention, even if from smaller outlets such as a customer’s blog. Receiving no reviews can indicate that people consider your app boring or uninteresting.
As you look through my recommendations about early warning signals, keep in mind that one of these indicators alone doesn’t mean it’s time to shut down your app. In fact, catching these problems early enough may allow you to quickly recover or even discover an improved or new vision for your app.
If your app has been out for a couple of months or more, however, and you’ve tried some of the post-launch promotional techniques in Chapter 8 (see the Additional Promotion section in that chapter), yet you feel like the early warning signals are now permanent attributes of your app, you are going to need to take a closer look at what you are doing. You know the opportunity cost for continuing to maintain this app. So, if you find that your app has no hints of life, is not achieving any of your goals, and is costing you considerably more time, money, and effort than it’s worth, you should consider severing ties with it or at least putting it on the back burner while you explore other opportunities.
This advice shouldn’t come as a surprise. In Chapter 1, I made it clear that pursuing an app is risky, especially under the wrong motivations, and that even following all of the principles I outlined for you wouldn’t guarantee a favorable outcome on the App Store, but would only improve your chances for that to occur.
You also should recall that being successful on the App Store is often about a portfolio of apps and not a single app. One particular app may be what you become known for, but that’s often not the first or even second app. Ultimately even a “failed” app is part of a larger mobile strategy because it will provide you with intangible experience, as well as tangible creative and code assets. By making a hard but prudent decision to stop subsequent development of an app that shows no life earlier in its existence, you’ll be positioning yourself to more quickly find the right opportunity. Only this time, you’ll be much more experienced and prepared for the challenges of the App Store.
Even if your app is doing well or is a critical part of a longer-term strategy (e.g., it’s a companion to an existing product or service), it will likely experience some of these warning signals throughout its existence. All apps have ebbs and flows, often resulting from updates you release, reviews you receive, changes in the App Store, new operating systems and devices released by Apple, and many other factors that will likely be out of your control. That’s why it is so important to stay disciplined and follow through on what is under your control—discovering ways to innovate in the App Store, working with customers to validate ideas, rigorously testing your app and its updates before they go into the App Store, and continuing to marry your marketing and development cycles together.
Essentially, you should make sure that each app update follows the principles described in this book on a smaller scale. By being methodical and staying customer-focused, you will constantly be increasing your chances of being competitive in Apple’s always-growing and ever-changing App Store.
Position: VP, marketing
Background: At Flurry, a leading mobile application analytics provider for Apple’s iOS and Google’s Android platforms, Peter is in charge of corporate and product marketing. In the past, Peter led product marketing at Electronic Arts, where he managed The Sims franchise, the #1 PC game of all time.
Ken: What are the biggest misperceptions developers have about analytics? In general, do they understand the value of them or just see installing them into their apps as a chore?
Peter: Analytics is something our developers choose to add to their applications, so we believe they see value in them. We think they understand the value of learning how consumers interact with their applications. Beyond this, we believe developers can also learn things like where to best place ads, how effective cross-selling is working, or understand click-through conversion rates on offers placed within the application.
Ken: The apps in the App Store range quite a bit, from games to utilities. At a more fundamental level, though, what types of metrics (analytics or otherwise) are important for all developers to pay attention to and track when an app goes into the App Store?
Peter: Engagement and loyalty metrics are important to understand beyond simply the number of times an application is downloaded. These include metrics like frequency of use, length of use session, and retention of users over time. Working to increase these metrics, depending on the application, typically means that developers are focused on increasing customers’ satisfaction. Also of interest is the geographic distribution of users, what operating system and device version they are using, and whether they are connecting through WiFi or carrier networks.
Ken: Are there any baselines for assessing the health of an app? For example, if an app is opened three times per week, is that good or bad? How can developers best compare their apps’ analytics to similar or popular apps?
Peter: This primarily depends on the category of application (e.g., games versus utilities). Flurry has considered but not yet released the ability for a developer to benchmark his application performance within relevant categories. Flurry released some data on this at http://blog.flurry.com/bid/26376/Mobile-Apps-Models-Money-and-Loyalty.
Ken: Those who are not familiar with analytics probably have never heard the word “event” before. What are events and why do developers create them? How does tracking events influence the evolution of an app?
Peter: Events (called “goals” in Google Analytics) are created to count the number of times a consumer completes a specific action or task within an application. For example, a developer who makes a game may want to see which game mode users play most often, which power-ups are selected most frequently, or what percent of users completes the entire game. For books, perhaps the developer would like to know how many sessions it takes to read a book, or which chapter the user is currently reading.
Ken: How can developers use analytics to decide if an app is no longer worth investing in? What sort of changes in metrics might indicate that the app has stabilized or previously reached its peak? Are there early warning signals that can help prevent that from happening?
Peter: It depends on the app, but for apps that seek to hold the attention of a large audience (e.g., news) the developer can look at “active users,” which shows the total number of users that have downloaded an application versus how many have used it recently. If this number continues to decline, indicating churn even after making a few updates, that can indicate a problem. Or perhaps the application operates on a free-to-paid micro-transaction model (e.g., In App Purchases). In this case, the developer would want to track both the active users as well as the percent of those who purchase goods. If this number is declining, then it might be time to either refresh the current app or build another one.
Position: Director of Mobile Products
Background: Romain David is a mobile professional with more than 10 years of experience. He currently serves as Director of Mobile Products at Lumos Labs, Inc., the creator of Lumosity.com, a leader in online cognitive training.
Ken: The Lumosity product has been around for several years now. What were the initial plans to port that experience to a mobile platform, and specifically to the iPhone?
Romain: Less than three months after the iPhone platform was launched, the number of devices, monetization capabilities, and incredible user experience made it obvious that the iPhone would become our initial targeted mobile platform. We first collected input from our users visiting our site on their iPhone and iPod touch. This gave us a sense of what our users expected to see on the device, and what cognitive area they were most excited to train on the go.
We decided to start by porting one existing game available on Lumosity.com based on different criteria including user experience, session length, and popularity. We introduced Speed Brain in November 2008 as a paid application. iPhone users were able to play this game and improve their speed processing. Due to encouraging early results, we decided to invest more resources on the platform and developed more standalone brain games, before launching Brain Trainer, a complete portable brain training program.
Ken: Because you had an existing product, what were the biggest challenges you faced in this process? Where did you make compromises? What aspects of the iPhone, if any, helped improve your product?
Romain: It is very challenging for companies to be successful on more than one platform. You usually see winners on the Web not doing so well on mobile, and vice versa. Being successful on one platform requires a different skill set and a different culture. We understood that mobile was going to be a key component of our business moving forward, and the challenge was to overcome these limitations while offering a consistent experience to our users, whether they want to train their brain on their computer or on their mobile device.
It is very tempting to port all your assets from one platform to another. Our approach, however, is to develop products that take the most advantage of the platform’s unique capabilities, interface, and monetization opportunities. One of the compromises we had to make was to not port very successful games on Lumosity.com, since they were not going to provide a good enough experience on the iPhone.
Ken: Once you launched into the App Store, describe your approach for improving existing apps and launching new ones. What part does analytics play in influencing your decisions? What other factors inform the development process and updates that get pushed to Apple? How do you determine what does or does not go into an update?
Romain: Many of our decisions come from what we learn from our users. The iPhone is no exception, and analytics has played a key role in our decision-making process. In our iPhone apps, we survey our users, so we can prioritize our features accordingly. For example, many of our iPhone users have told us they wanted more scientific information and an explanation about the Brain Performance Index (BPI) we use to measure their cognitive performance and progress. We took this feedback into account and provided a lot more information in our latest app update.
Ken: Without sharing anything proprietary, what are some of the ways that you measure the success of your iPhone apps? Are there other ways to monitor them besides looking at the number of downloads or revenue generated?
Romain: When Brain Trainer became a Top 25 app, we demonstrated that our brain training program could be appealing to a wide range of iPhone and iPod touch users. Beyond the number of downloads and premium users, the number of daily active users combined with the session length gives us a good idea of how engaging our application is. Engagement is a very important measure, since brain training is most valuable if practiced on a daily basis.
Ken: As a customer of your products, I know that you launched many individual paid apps over a period of time and that recently you launched a new free app that supports In App Purchases. Was this approach part of your original plan or something that evolved based on customer feedback and changes in App Store policies?
Romain: Even before we launched Speed Brain—our first application—we knew that at some point we were going to launch an app that will provide a complete brain training experience, similar to what we offer on Lumosity.com. When Apple introduced In App Purchase and made it available for free applications, it became obvious that we should adopt this model. We were finally able to provide a similar approach to our website. In addition, our iPhone and iPod touch users have always mentioned they wanted more games, so adopting this approach was the best way to meet their demand.
Background: Ariel Michael is the co-founder of appFigures, a product of Fileitup Media. appFigures is a reporting platform for iPhone and iPad developers that brings together App Store sales data, worldwide reviews, and hourly rank updates into a single, intuitive, and informative reporting solution.
Ken: Most developers launch their apps to a global audience because that’s the default setting. Is that a good approach? How does that complicate the reporting process in iTunes Connect?
Ariel: While iTunes Connect reports are not pretty to the naked eye, they do in fact contain data that’s easy to interpret programmatically. Although the U.S. is by far the largest market for apps, it’s extremely beneficial for developers to release worldwide.
Ken: What are the biggest misperceptions and frustrations developers have about reporting? How does appFigures address some of those issues?
Ariel: Most developers expect Apple to provide reports directly. The reality of the situation is that they don’t provide reports at all; just tab-separated text files that get purged after seven days.
That’s exactly why appFigures was developed! appFigures was born out of the need to have meaningful reports that can easily be viewed and used to enable us as developers to maker better decisions instead of spending time doing spreadsheet analysis.
Today, appFigures helps developers by automating the entire process of downloading and interpreting sales reports, turning them into meaningful charts and tables. We also extend these reports by tracking ranks and reviews from all App Stores.
Ken: The apps in the App Store range quite a bit, from games to utilities. At a more fundamental level, though, what are the types of metrics (downloads, sales, or otherwise) that are important for all developers to pay attention to and track when an app goes into the App Store?
Ariel: There are several key places developers can look at to better understand their place in the App Store:
This is an extremely helpful area developers most often neglect. Reading reviews gives developers direct insight into the minds of their users. This information can then be used to expand the app and even fix flaws, and at the end show your users you care about them by listening.
This is the most obvious one, as it is the bottom line. Developers should, however, keep a close watch, not only on the actual number but also on how external events such as marketing campaigns, PR work, getting reviewed, etc. affect downloads.
Most developers are unaware of the fact that apps can be returned. It’s especially important to track the number of returns and try to keep those as low as possible. All developers see some returns here and there; it is important, however, to ensure they are not consistent.
Although developers have no direct control over the rank of their app, watching rank trends can give developers a real-time indication of their app’s performance, which is not available when just using sales reports. By keeping a close watch on rank trends, developers can react fast. A good example would be reacting to an increase in rank by lowering price.
Ken: Can you provide a simple description of the way Apple pays out revenue? Assume, for example, that an app launched globally today and made $5,000 across all App Stores in its first month. When would the developer see the first check? How long could it take to see some of those checks?
Ariel: Getting paid by Apple is not as simple as that. There are actually a few things about getting paid that many new developers are unaware of:
Apple operates on a fiscal calendar that’s different from the normal calendar.
Payments are distributed separately by region. The seven payment regions include United States, United Kingdom, Australia, Japan, Canada, Europe, and “Rest of World.”
You’ll only get paid if your profit in a region exceeds $150. If it doesn’t, it will roll over to the next month, or until you reach $150 in that region.
Payments are usually sent out three to four weeks after the end of the fiscal month. This was not the case before, but Apple has gotten much better at making payments on time over the past few months.
Ken: Are there any baselines for assessing the health of an app? For example, if an app is making $10 per day, is that good or bad? How can developers best compare their apps’ download and sales numbers to similar or popular apps?
Ariel: Because apps vary ever so much on the App Store, it’s hard to compare one app to the other. At a very basic level, developers should set goals for their apps and use trend analysis to see if those goals can be achieved with current capabilities. If not, the developer should make a decision whether to stop development or invest more resources.
Making $10 a day is certainly not enough to keep a developer, indie or studio, alive. At such a point, the developer should examine why the app is selling so few copies and whether to end development and move on to bigger and better apps, or to invest more in advertising and PR. This depends on the quality and scope of the app.
Because financial data is kept privately by most developers, there is no way to compare an app’s financial performance. Many developers, however, use ranks as an indication of performance when comparing their app to a competitor’s.
Ken: What guidance would you provide to developers about pricing and the “race to the bottom” of the App Store? How can they find the “sweet spot” for their app to maximize returns, that is, the price that yields the most revenue and not necessarily the most downloads?
Ariel: The “race to the bottom” is very tempting, but should not be the first choice for a new app. If there is one thing to learn about the App Store it is that one price does not fit all. That’s even more so on the iPad App Store.
Finding the sweet spot will depend on the app and the competition. The best approach is educated trial and error. Try different price points and see how the App Store reacts. The best time for a price change is with the release of an update.
The freemium model has become a great sweet spot for many developers, ever since it was made possible by Apple in mid-2009. The freemium model has great potential in my opinion because it sucks in users who would otherwise not be interested in paying and increases the potential to get those users to pay via In App Purchases. The model does have its cons, and so developers should not consider it for all apps.
With the recent release of the iPad, many developers have enjoyed the ability to charge a much higher price for the same app when on the iPad. This is a trend I believe will continue because of the iPad’s increased capabilities and larger screen. These capabilities will allow developers to target larger industries such as retail, hospitality, and entertainment, which would open up the market to a wider audience that’s used to spending large amounts for applications.
Ken: How can developers use reporting to decide if an app is no longer worth investing in? What sort of changes in metrics might indicate that the app has stabilized or previously reached its peak? Are there early warning signals that can help prevent that from happening?
Ariel: When looking at reports, developers should always look for trends and try to analyze them. Trend analysis will give developers an indication of whether the app is still in motion or if new efforts are needed to bring an app to life, and also allow developers to react fast.
There are many trends to watch for, but most would depend on the type of app, market conditions, and the competition. Here are some more common trends that are easy to spot:
This is the most common trend to spot, and is a clear indicator that more needs to be done. Limited-time price drops are one way to change the trend; another is by releasing an update or promoting the app.
This is common for niche apps or apps with very little/no promotion. One way to capitalize on the zigzag is to increase the price of the app. To turn the zigzag into an upward trend a developer should consider releasing an update or promoting the app.
This is the most desired trend and usually means the app got featured. When an app gets featured its sales will skyrocket for about a week. Reacting fast (by changing the price, releasing a press release, mass mailing, asking for reviews, etc.) can make the difference between remaining on top and disappearing completely after the featured week is over.
Developers should also read reviews. I’ve mentioned it before, but stress its importance once again. Reviews can tell you if your app is healthy. Not having reviews means it probably isn’t.
Here’s what you learned in this chapter:
Once your app is in the App Store, you’ll immediately begin monitoring feedback about it. In general, you can think about feedback as being qualitative (e.g., App Store reviews) and quantitative (e.g., analytics).
Apple’s reporting features are somewhat limited and confusing. Third-party tools such as appFigures can help you quickly make sense of your app’s download and financial data.
Listening to customer feedback does not stop once an app is in the App Store. Continuing to gather customer insights and offering obsessive customer support will keep customers engaged and happy with your app, even when it has shortcomings.
Application updates should follow from your app’s initial roadmap and the feedback collected about your app. Updates should be balanced between short- and long-term needs and should always be tested before being submitted to the App Store.
Deciding to stop development on an app should not be considered a failure. Apps have various life spans and will experience ups and downs throughout their existence.