Today we announced Merch by Amazon, a new self-service program designed to help you increase revenue through the sale of branded t-shirts designed by you and produced, sold and shipped by Amazon. With the print on demand service, you sell only the t-shirts your customers want to buy. You never have to worry about inventory or out-of-pocket costs. For every t-shirt sold, you earn a royalty. The more t-shirts sold, the higher the royalty is.
To get started, simply set-up your Merch by Amazon account, upload the artwork for your t-shirt, and push submit - Amazon takes care of the rest. In a matter of hours, your custom t-shirt is available for sale worldwide on Amazon.com. Once you’ve created your custom t-shirts, you can also promote them in-game on the Android, Fire OS, or iOS versions of your game via Amazon Mobile Ads.
[Read More]
Amazon today introduced all-new Fire tablets, including a new 7” tablet that sets an entirely new standard for a tablet under $50. The new Fire tablets are designed from the ground up for entertainment with a 7”, 8” or 10” display, an incredibly thin and light design, quad-core processor, front- and rear-facing cameras, and up to 128GB of expandable storage. The all-new Fire tablets also introduce Fire OS 5 “Bellini”, which brings the best entertainment experience on any tablet, with an updated user interface, deep integration of Amazon-exclusive services, and hundreds of new and upgraded features and platform updates. Key upgrades and enhancements include:
[Read More]
You’ve built a great app, and you may have spent a lot of time implementing IAP in your app so you can make a bit of money for your efforts (or better still, make a lot of money from your efforts!). But perhaps like most developers, maybe 2-10% of your customers actually buy anything. It can get frustrating. Now, with Amazon Underground you have the option to monetize your app and get paid based on how much time users actually spend using your app. All your users.
If you are interested in trying out this new monetization model by submitting an existing IAP-based app, the following is a guide for you!
[Read More]
We recently updated the developer portal device targeting capabilities to include targeting for the most popular Android devices including the Nexus 5, 7, 10, HTC One, Shield Tablet, Galaxy Nexus, Sony Experia Z, and the Motorola Droid Razr HD to name just a few. Developers can now look at the list of supported, excluded and unsupported devices to quickly see which devices are compatible with their app, and if their app manifest settings have filtered out any devices.
To make sure your app or game is available on as many devices as possible, you need to optimize the targeting via the developer portal and your Android manifest. Android developers know that getting on as many devices as possible is key for a successful app launch. More devices = more downloads = more $$$. Consequently, most developers are aware that careful construction of an app’s manifest (i.e. the AndroidManifest.xml file in the .apk package) is essential for targeting compatible devices, while avoiding devices that would cause their app to perform poorly.
However, there are a few common mistakes developers make with manifests that can cause device targeting to be too restrictive or too permissive when determining an app’s compatibility. Here are 3 common mistakes that we see:
[Read More]
Learn how the top 50 game developers leverage in-app purchasing to monetize successfully, and get actionable data to help you increase the profitability of your games. I’ll review data Amazon has collected about how users engage with IAP in games, and go into detail about some of the best ways to increase customer conversion and revenue.
Tuesday, July 14th 10:00AM PDT, 1 hour
Starting today, developers have the opportunity to participate in a Developer Preview of Fire OS 5, the next generation Android-based operating system that powers Fire tablets, Amazon Fire TV and Fire TV Stick. And because Fire OS 5 is based on Android Lollipop, we can make this update while preserving even more compatibility with existing Android apps than ever before. This means that even more of your apps should work on Fire devices with no additional engineering effort. There are several ways you can participate in the Fire OS 5 Developer Preview.
To ensure your app is available to millions of customers on the next generation of Amazon devices, you can now participate in the Fire OS 5 Developer Preview. As an Amazon Developer, we’re offering you early access to Fire OS 5. You can now see your app running on a Fire HD 6 or Fire HD 7 tablet, and identify any app compatibility issues well in advance of our new Fire OS launch later this year.
To participate in the Fire OS 5 Developer Preview, click here.
Amazon Testing Service is a free tool that allows you to test your app for compatibility on Fire and Android devices. We’ve updated Amazon Testing Service to provide feedback on your apps compatibility with Fire OS 5 and Android Lollipop. To test your app, simply drag and drop your Android APK into the App Testing Service on the Amazon Developer Portal homepage page. In about 90 seconds, you will get compatibility results for Fire OS 5 and Android Lollipop.
Now is the time to get started. Check out the resources below to learn more about Fire OS5 and the Amazon Appstore
Register for a Free Amazon Developer account
Sign up for the Fire OS5 Developer Preview
Want Amazon Developer blogs delivered to your inbox? Stay in the loop on the latest industry best practices, Amazon promotions, and new launches by subscribing to our weekly blog summary here.
A post on what to implement from the 10 part-series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we wrapped up our study of what the top 50 apps do with IAP that the rest of us don’t. Over the last 10 weeks, we delivered a significant amount of data and suggestions, and it can be a bit daunting to figure out where to start. This week we’ll give you some ideas on where to get started by highlighting the top 3 practices that might make the biggest difference in your game.
Use your favorite analytics package and learn about how your customers play and buy within your app. It’s our experience that 80% of an average game’s downloads won’t be active after 7 days, and that 3% of downloads from the Amazon Appstore turn into paying customers. And it’s those customers who stay with you over one week that will drive 74% of your total game revenue. This exclusive group of customers is your loyal following. Treat them like gold!
What now?
Identify the players that:
If you’re showing your best 30 day + customers the same IAP catalog that you showed them on day 1, you’re likely leaving demand unfulfilled, and you’re probably not making the best use of IAP.
When creating new IAP items for your good customers, do NOT just add these items to the same IAP catalog you show your first day users! You want to keep the catalog clear and un-cluttered for beginners, as well as offer the enticement of a catalog that changes for your veteran players.
To fine tune what items work best in each IAP catalog, find an A|B Testing API that you can use to get real-world data on each IAP catalog.
What now?
If your IAP catalog doesn’t have a benefit (like BONUS % in this catalog), you may not be making the reason to buy clear enough for your customers.
If you’re selling a sword instead of coins, the customer will want to know how much more damage it will do, or what villains it will decimate as opposed to those enemies that their current sword won’t scratch. Make the benefit clear, and you’ll make more sales and have happier customers.
What now?
I hope you’ve enjoyed this series, and are starting to see improvement in your IAP monetization as a result. For more insights on how to keep users engaged and boost revenue check out our free eBook, “In-App Purchasing Lessons from the Top 50 Game Developers”.
In the mean time, I’d love to be working on the next subject you’d like to learn more about or see data about. Let me know, and ping me on Twitter @MikeFHines.
As the size of mobile apps get larger, and services and tools get more complex, they add more method references to our apps. Google Play Services alone adds 29,460 methods (reference). The result is that we are hitting the original design limitations of Android build architecture. Specifically, we hit the inability of a single Dalvik Executable file (dex file) to support more than 65K Method references. When that happens, your code will generate build errors and won’t run.
You can learn more about this issue here: https://developer.android.com/tools/building/multidex.html
When you compile your code and are short of the 65K limit, you may reasonably believe you don’t need to worry about this problem. That is, until you submit it to an Appstore. Most appstores, (the Amazon Appstore included), add additional method references as part of the ingestion process. If your code is ”too close” to the limit when submitted, your code may fail upon submitting to an Appstore after the additional references are added. This has always been the case. However, with the release of Android 5 (Lollipop) we have started seeing a lot more of these “too close” dex file problems. To help you avoid or work around this limitation, we have some suggestions below:
You’ll know when your app references more than 65,535 methods because you’ll see an error something like this:
Or
If you see these errors, you can certainly address them before submitting to an Appstore. But even if you’re close, you’ll want to try some of these practices to stay comfortably away from “too close”.
To find out how close you are to 65K method references, you can utilize a tool called dex-method-counts to get the method count and what is referencing them:
https://github.com/mihaip/dex-method-counts
What is “too close”?
“Too close” will be different for each Appstore and each device OS, so there is no single correct answer. But Google sets max methods to 60K if Multidex is used, so you can be pretty sure that 60K methods is a safe number for newer Android devices. (Devices running older Android OSs may need that limit closer to ~55K methods).
The first (and easiest) step is to remove as many unnecessary libs and methods as possible. To help in this task, you can use ProGuard (part of the Android SDK) with -dontoptimize –dontobfuscate in the configuration which will remove unused methods from the dex file during build time. (See this helpful blog post on using ProGuard by Crashlytics)
If removing unused libraries doesn’t work for you, you can try using the Multi-dex approach, which splits up classes.dex into multiple dex files.
The quickest and safest approach for using multi-dex is to use the Multidex library with Gradle Plugin: https://developer.android.com/tools/building/multidex.html.
There are few caveats to this approach however; the main one is the requirement to use Gradle. You may also find that it may not remove enough methods to go below the limit without performing a few extra steps which are outlined in the “Using the Multidex Library” section below. You can use the dex-method-counts tool referenced above to check the method count of your resulting classes.dex file.
Using the Multidex Library
With Android 5.0 Lollipop release, a new support library (android-support-multidex.jar) appeared in Android SDK ver 21.1.x and Android Support library 21.0.3. You can find it in:
\android-sdk\extras\android\support\multidex\library\libs. It contains two new classes: MultiDex
and MultiDexApplication
and simplifies the Multidex loading process. According to Multidex documentation (http://developer.android.com/tools/building/multidex.html) it does not provide additional functionality on Android 5.0, which already has built-in support for secondary dex files. Rather, on previous versions of Android, it allows additional .dex files from the APK archive to the classloader. The library allows the archive to become part of the primary DEX file of your app and manages access to the additional DEX files.
To implement multi-dex for Pre-Android 5.0 releases follow the steps below:
Step #1
Make sure you have updated your Android build Tools to the latest version – You will need at least 21.1.x, current version as of this writing is 21.1.2
Step #2
Add the android-support-multidex.jar
library into your project. You can find it in: \android-sdk\extras\android\support\multidex\library\libs
Step #3
Add multiDexEnabled true and Multidex dependency to your buildConfig in the build.gradle file. An example below:
Step #4
You can override the android.app.Application class, or declare MultiDexApplication class in AndroidManifest.xml file as shown below:
Step #5
If you have any additional libraries in your project, be sure that you disable pre-dexing on them. Unfortunately the --multi-dex option is not compatible with pre-dexed libs.
You can do this by adding the example below to your app/build.gradle file.
Step #6
You have to configure build instructions to endure that your Multidex app is optimized for the Amazon Appstore and our ingestion process. As of this writing you have three options:
Option #1 – Manually create the main-dex-list file.
In app/build.gradle file we have to add:
There are two params:
--multi-dex - enables splitting mechanism in build process
--main-dex-list - file with list of classes which have to be attached in main dex file (we will address this one in Step #5)
To ensure your Multidex app will ingest and publish properly in the Amazon Appstore you should use the --main-dex-list
param to put the following in the main .dex file:
Option #2 – Ignore the multi-dex and multi-dex-list parameters.
If you are using studio 0.9.0+ gradle 0.14.2 and use the dx.additionalParameters to manually set the max number of referenced methods in your main classes.dex file, then the main-dex-list will be auto-generated and you don’t have to set the multi-dex and multi-dex-list parameters. It will look similar to:
Option #3 - Ignore the multi-dex and multi-dex-list parameters if you are using studio 0.9.0+ gradle 0.14.2 and let the build tools automatically limit the dx.additionalParameters parameter to 60,000.
This should work for most applications, however if you have a very large number of classes in your app you may find that you will need to manually set your max number to something less than 60,000 to have your app ingest properly in the Amazon Appstore.
StackOverflow has some handy info.
The source code of how Gradle automatically generates a main dex list is here.
There is also a tool that can automatically generate this main-dex-list here.
This blog post has an example of a useful proguard-rules.txt file that accommodates the AWS SDK and some other popular tools.
The final article in the 10 part-series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we looked at how lowering barriers to new app sessions paves the way for more sessions, and more minutes in the app per day. We also looked at how tuning the difficulty for a game can make a significant impact in user engagement, retention, and IAP conversion. This week we’ll see how the top 50 see what to change, and how they implement change.
To address the right offers and messages to your customers, to know where you may have a retention issue, and to know other key metrics about your app, you need to be able to see inside, and see how your users interact with your app. App analytics packages are services put together by quite a variety of providers, and are a great way to get started with the basics, as well as progress up through full custom instrumentation. To help scope an analytics implementation project or provider decision, you should start with knowing what you need to know to make smarter decisions. (like how long has this user had the app? How many purchases has this user made? How long did it take this user to complete the last task/level/milestone?) If you’re not going to use a metric to influence your actions, think twice about how much you really need to implement that metric.
Seeing inside your apps is critical, but it doesn’t do anything. Being able to do something about what you see is how your app starts performing better. In order to optimize your apps, you’ll need to have a lot of levers in you app that you can manipulate to change the behavior of your app (like difficulty). These levers come in the form of A|B testing. A|B Testing lets you find out if you should make your game easier or harder, and how much more so to make it to meet your goals. A|B Testing tells you which items are the most popular or profitable for you to offer your day 1, day 7, or day 30 users. While I’m partial to the Amazon A|B Testing service because of it’s flexibility, ease of implementation, and price, you can get A|B Testing services from several vendors. Remember, the top 50 don’t guess. They know.
That’s it for the series What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t. For more insights on how to keep users engaged and boost revenue check out our free eBook, “In-App Purchasing Lessons from the Top 50 Game Developers”.
In the mean time, I’d love to be working on the next subject you’d like to learn more about or see data about. Let me know, and ping me on Twitter @MikeFHines.
Article 9 of 10 in the series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we saw how making it easier to buy resulted in a lot more sales; a conclusion that is not rocket science, but can be challenging to implement correctly. This week, we’ll take a look at some strategies that the top 50 have used to increase the number of minutes users spend in each session, and increase the number of sessions the users have per day.
Updating game content frequently keeps users engaged and coming back to see what’s new. While we didn’t see a demonstrable trend differentiating the top 50 from everyone else with regards to content updates, the developers we’ve interviewed are all fairly unanimous in this regard. Stale content kills long-term retention. And if you’re going to update your content, that might be a good time for a sale on IAP items.
If you can, time your sales and content releases together. Playtika plans IAP sales when aggregate hard currency balances are low. Playtika also plans new content releases to go live during sales to give the purchased hard currency somewhere to go.. If customers don’t have a place to use their newly acquired IAP items, customers will just keep them in inventory, and you will see a resulting post-sale slump in purchases.
The first thing to do is reduce barriers to entry of additional sessions. Flappy Birds is a great example of how easy it is to get started. You simply tap on start and start flying the bird. And when you crash, you tap start once more and you start flying again. Compare that to apps where we’ve got to go to a splash screen, welcome menu, and options screen before we can even start playing. That’s a lot of work, particularly if you’re standing in line at the grocery store.
Another barrier to entry is not starting where you left off. If you’ve gotten to level 14 of a game on your tablet at home, and then pull out your phone when you get to the grocery store, will you really be willing to start all over again at level 1? Or will you close the app and play a different game? That developer has just lost a re-entrant customer. They just lost a potential re-order. What you want to do is use one of the game engines that will synchronize your progress across devices. I’ve got a screen shot of Amazon GameCircle here which has an active sync API that synchronizes the customer’s progress so that when a customer gets to level 14 on their tablet, they pick up right on level 14 on their phone; no barrier to entry.
One way to increase session time is to tune game difficulty. Imagine if you’re the small guy here. You’re going to do this once, and you’re to give up. That would get un-fun really quickly. But it’s not fun if you’re the big guy either. After crushing the little guy a few times it just gets boring. The top 50 do A|B testing religiously to tune the difficulty and find the sweet spot that keeps users in the game and increases IAP purchases. So absolutely do A|B Testing on the difficulty assumptions or other assumptions you make in your app. It’s free, and it’s surprisingly easy.
In the next article in the series, we’ll look at what you can do to see what’s going on with your customers inside your app, and how the top 50 use that data. For more insights on how to keep users engaged and boost revenue check out our free eBook, “In-App Purchasing Lessons from the Top 50 Game Developers”.
Article 8 of 10 in the series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we saw how differentiating offers to users based on their time in game works well for the top 50. We also saw that doing your best to eliminate confusion is not only a good customer service tenet, but a profitable one as well. This week, we’ll look at other ways the top 50 make it easier to buy.
Above is an example of a good IAP purchase screen. Not too many items crowd the page, no items are off the screen (customers just don’t scroll to get to those…), there are a reasonable number of price points, but it’s a bit unclear what the value is.
Take a look at this IAP dialog:
I really like two things about this screen. One is that it doesn’t mix different kinds of things on the same page. The page has one thing; soft currency purchases. If I want to buy a different kind of thing, I can use a different tab/page. The second thing I like is that the value is clearly identified by the BONUS labels. The value is clear. I don’t have to do any math in my head to see why I’d want to buy $9.99 instead of $4.99.
Making ‘Easy to Buy’ part of the design requirements is very important. Adding IAP functionality after you have designed your game is a mistake. Take a look at this example of the Ninja Kiwi game Bloons Tower Defense 5, a game in which adorable monkeys toss darts at balloons trying to escape the maze. The game is challenging but not impossible, yet occasionally, as the balloons approach the exit, and you are at a loss to stop them, you can’t buy anything to help you! You can’t purchase anything that will pop all the balloons on the field or make one of your dart throwers a turbo-manic dart thrower for a few seconds. The fact that I can’t buy anything when I need it makes it really hard to give Kiwi Ninja my money.
Well they figured that out, and in their next tower defense game, SAS Zombie Assault TD, they got it right (below).
In this game, I can build towers with my soft currency using the menu items on the left. But if a horde of flesh-eating zombies is rushing towards the exit, I’ve got hard currency items on the right, so I can spend $0.99 to get 3 Nuclear Hand Grenades and vaporize that mass of zombies. Soft currency on the left, hard currency on the right, no confusion. Hard currency items are obvious and available for purchase when my need is greatest. Perfect. When the apps in our study made it easy to shop, ARPPU increased by 75%.
In the next article in the series, we’ll look at what the top 50 do to increase the time their customers spend in the app and how they maximize repeat sessions. For more insights on how to keep users engaged and boost revenue check out our free eBook, “In-App Purchasing Lessons from the Top 50 Game Developers”.
Article 7 of 10 in the series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we saw how teaching customers about your IAP items and how showing them how to use those items makes a big difference for the top 50. In this article, we’ll look at how the top 50 arrange their IAP offers to maximize customer satisfaction and revenue.
You need to give customers something to order. Certainly you need to give customers items that are appealing to them, but what we found was that as you add more items your catalog, you start making more money. For example, if you have 12 items in your catalog, chances are you’ll make about 45% more money than you would if you only had 6 to 10 items in your catalog. But it’s easy to get the wrong take-away from this data. I don’t want you to think “Holy cow, if I just put 10 more items in a catalog I’ll be in the top 50!” It doesn’t work like that. It’s true that the top 50 have larger catalogs, but they don’t show the entire catalog to the users all at once. They show the right offers to the right people at the right time. They show different items to people on day one than they show to people on day seven or day 30, and they are using their larger catalog to get that breath of offers. Again we see the top 50 differentiating offers to different groups of users.
Now while variety in terms of offers is great, variety in terms of price points is not so great.
Take a look at the data and you’ll find that the more price points you have the lower your revenue is going to be. This doesn’t happen because they aren’t good prices, this because they’re confusing. It is really hard to communicate the value difference of items between $.99 $1.99, $2.99 and $3.99. A confused customer doesn’t go out and buy the most expensive item. A confused customer doesn’t go out and buy the cheapest item. A confused customer doesn’t buy anything. If you have too many price points competing for a customer’s attention it can be hard to determine the value difference between the price points.
In the next article in the series, we’ll look at how the top 50 make it easy for customers to buy what they want. For more insights on how to keep users engaged and boost revenue check out our free eBook, “In-App Purchasing Lessons from the Top 50 Game Developers”.
Article 6 of 10 in the series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we saw some stats that help drive smart app design, including the importance of securing day 1 customer orders. This week we’ll look at some of the smart things the top 50 do to increase their order and reorder conversion rates.
One way the top 50 make buying on day one (or any day, for that matter) is through tutorials. The top 50 apps introduce hard and soft currency in their tutorials, and show customers how to make in-app purchases. Across the board, we found that apps that described in-app purchasing in their tutorials have about 2 1/2 times greater conversion rate than apps that don’t. And what do you do after someone buys something? Teach them how to use it!
Apps that have instructions on how to use an item that was just purchased have 65% more repeat orders than apps that don’t. We know that if a customer don’t know that an IAP item exists, they can’t decide to buy it. It makes sense that if a customer doesn’t know how to use what they just bought, why would they ever want to buy more? The top 50 are remarkably consistent in their inclusion of IAP in tutorials. Think about whether you want to do that in your app too.
In the next article in the series, we’ll look at how the top 50 make sure they have the right things to sell to the right people.
Article 5 of 10 in the series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we saw how important the 20% of customers who stick with us past 7 days can be. To maximize that number of users, and to make sure they are having good experiences, the top 50 app developers design their app experiences and marketing plans around some crucial stats.
We found the top 50 know the numbers. They have internalized the data on this graphic. They know that 64% of the revenues they get come from customers third or later order, and they market and target specials accordingly. They know they need to give the users a reason to keep coming back into the game, because they know that almost ¾ of their revenue will come from users after they have been in the app for 7 days, and just over half of their revenue will come from users in the app for 30 days and longer.
They also know that 40% of their repeat orders are going happen within one hour of a previous purchase. (Okay, I’ll bet that some of you remember the graphs showing you that the average session length was a little over seven minutes. It’s fair that you should ask how this data fits into that data.) They key take-away from this data point is that the repeat order comes from a completely different session! That’s why the top 50 make it a very low-friction experience to enter their game and start playing right away. How easy it is to start engaging in your app will make a big difference in whether or not you capture that repeat order. The top 50 also get that 37% of the customers who will every buy anything will spend money on day one. And to that end, the top 50 make buying on day one really easy. See how they do this in the next article!
In the next article in the series, we’ll look at some of the smart things that the top 50 do to increase their orders and repeat orders.
Article 4 of 10 in the series: What the Top 50 Games do with In App Purchasing that the Rest of Us Don’t
By Mike Hines (@MikeFHines)
In the previous article in this series, we finished looking at what being in the top 50 looks like from a raw data point of view. In this article, we start to look at how the top 50 got these results, beginning with why the top 50 care so much about the small number of users still with a game after 7 days.
If you were under the impression that day 7 was a big cutoff for customers and apps, you are partially correct. After 7 days, about 80% of the customers who installed your app will not launch it again. But the 20% of customers that remain can mean a great deal to you. The graph above is how purchases break down by hour.
The first day of sales is a pretty big spike! Obviously the first day is really important to you; you’ll get about 18% of your revenue from that first day. But what I want you to take away from this graph is the 82% of the revenue that’s left. This graph has a long tail, and while it doesn’t go out for 30 days, the pattern continues even well beyond 30 days. So let’s go ahead and take a look at seven days. Seven days is 168 hours, and it’s true that by seven days you may have lost about 80% of all of your active users. Buy you should know that after seven days, you still have 74% of your potential revenue on the table. After 30 days, there is still 54% of your potential revenue left on the table. That’s what a long tail means, so please a lot to pay attention to the users to stay with you after seven days, and stay with you after 30 days.
One of the reasons that taking care of the long tail is such a big deal is because the average price a customer is willing to pay for an in-app item goes up significantly over time. If you were wondering how the top 50 were able to increase the prices paid for their IAP items? They are offering a different array of items with more expensive selection to users who’ve been there longer. Once an average customer has been using an app for 30 days, they will typically purchase items that are 60% more expensive than they did when a day one customer. The top 50 app developers get this, and you would do well to take a closer look at this as well. If your apps are offering the same in app purchase items to your customers at day 30 that you did at day zero, you may be leaving some money on the table and leaving your best customers unsatisfied by not filling needs they have in your app.
In the next article in the series, we’ll look at some of the stats that the top 50 app developers know that help them make smart decisions when building and promoting their app and in-app purchase items.