App Pricing Optimization Guide

Editor’s note: This is a guest post from Jakub Chour. Jakub is co-founder of Digicamp.cz and currently works as a freelance mobile growth and subscription optimization consultant.

App Stores suck. At least when you want to know how to monetize better. Ever wondered how much could you make if your subscription price was $17 instead of $13/month? Or just wanted to test how people in Japan will purchase a 7-day trial period with yearly subscription?

Subscription pricing optimization is hard because it does not give immediate results. Changing your price will change your LTV and subscription-churn and results might be visible after one billing period, but usually much longer. And it’s not only in games where you can offer different things like a super-killer-mega-sword X and just after it, loot box with an even finer double-bladed axe. With a subscription, you usually have one or max. two offerings.

Mind in-app purchase set-up

Have you tried to just lower the price at Google Play? Not only do you need to change all prices manually one-by-one, but you also need the user to agree with every price change, higher (here I get it) or lower (here not so much). If the user doesn’t agree, he/she is unsubscribed at the end of the current billing period. This could cause significant user churn so try to avoid it as much as possible. 

TIP #1: Changing the in-app subscription price will change your LTV for a particular product. Always create a new SKU, this will help keep your cohorts clean and users from churning less.

Surprisingly, the App Store is more friendly for price optimization tests. It’s somehow easier to set different prices for a certain country and price change could only affect your new users if you want. On the other hand, users can freely switch between subscriptions inside the App Store itself, so you need to take it into an account when you name your new SKUs. Changing Subscription groups also affects your app store proceeds.

TIP #2: Do not mess with Subscription groups in App Store, unless you are offering multiple subscriptions tiers inside the app. Changing subscription group resets 365 days period after which Apple reduces their cut to 15%, down from 30%.

Measure right

You are probably measuring purchases in the app, right? Firebase, AppsFlyer, your own system… But that’s not enough, unfortunately. At least for auto-renewable payments. You need to know when:

1. When users cancel the subscription. This can be done outside of the app and they don’t start the app, you can’t know that the user canceled by checking their premium status. This needs to come from your back-end. Missing this event may radically change your LTV (for better in charts, but for worse in reality).
2. Users ask for a refund (and boy, they do). The shorter the trial period you have (7 or even 3-days trial period), the harsher users are about asking for a refund after they realize they have been charged.
   
   Another “classic” refund case is when users see their bank statement and realize their yearly payment was charged as a one off and not on a monthly basis. It almost doesn’t matter how you phrase the subscription screen, some will want a refund nevertheless.

Revenues based on how you track in-app events

Everything also needs to be measured per product and ideally per country too. Blended churn through different cohorts, unfortunately, doesn’t work for different subscription lengths – like a traditional month and a 3-months subscription. You can see it on this graph of the sleep tracker app that I worked with. A sudden decrease of retained users in the 3rd month is caused by quartal subscription users who just realized they don’t want to renew.

You can do all the tracking mentioned above on your end, but this sucks. Especially processing receipts from iTunes. Both app stores offer real-time developer notifications when the subscription state is changed, but for example, Google Play has 13 different subscription statuses and you need to react to each of them accordingly.

Our initial estimate was 14 working days to do only bare-bone app store recipe checking (at ONE store) and another 14 to send tracking data to Mixpanel. Even though it was a bit less, there is also maintenance approx. 2–3 days a month. You need to take actionable steps on subscription changes (like sending a special offer to fresh unsubscribers) without constantly tinkering with something in the backend. So my advice is:

TIP #3 When possible, track all subscriptions through tools like RevenueCat or Qonversion.io. Development and maintenance costs are usually much higher than average purchase tracking platforms.

Don’t test just randomly

So you got all of your data ducks in a row. What should you test?

You can try a common-sense approach like testing your competitors’ prices. But chances are your competitors also never tested it and after all, you are not your competitors. You can also just reduce your prices by, say, 20% to see if lower price brings more customers, but you can end up with exactly what you asked for and get 20% lower revenues.

TIP #4: Don’t test without any hypotheses about what the new price should be. It usually ends =with mediocre results at best. But if you really need to move fast and break things™, test bigger price differences (20% at least) and have at least 200 in-app purchases per country and SKU per month.

To test properly, you need a sufficient user sample and some hypotheses. How do you get it?

Find valid pricing points

There are a few pricing testing frameworks, but none suited for in-app purchases. We found that Westendorp’s Price Sensitivity Meter is one of the better among them and the questions it asks are going in the right direction. We adjusted it to apps’ reality where every user unnecessary input is weighted against retention or just one more ad-impression which brings (some) money instantly. Also, the graph looks a bit different to answer basic questions better.

Three questions to ask:

1. At what price would you consider a subscription to the app to be too expensive?
2. At what price would you consider the app to be priced so low that you wouldn’t trust it?
3. At what price would you consider the app to be a bargain?

What will you get?

If you play a bit with the results and order them by response frequencies, you can get something like this. Red (too low) and blue (too high price) will determine the price range suitable for testing and yellow will divide that zone into two. Since people always underestimate the bargain value (they say a bit less than they are willing to pay), the green is a zone where you should start price testing. White “sales” represent the zone below what is described as a great deal and if you want to hold a flash sale, you can start looking into that.

From what you can see is that this app is currently on the verge of what it can bill to most of the users for the monthly subscription. But also, there is a chance to bill $20 USD to approx. 10% of users under the right circumstances.

You can also see that for 50% of the respondents, $7 USD is a bargain price. Too high is $11 USD, so you can start testing subscription price between $7–$10 USD.

Will 50% of users buy for that price? Of course not. Will that price raise conversion rate? Probably. For how much? You never know, but A/B testing will tell with certainty.

Should you offer your subscription cheaper to all your users? No! As you already know, some users are willing to pay more, so keep your current subscription as it is. Test at a small scale to see conversion rate into a subscription, and if really your prices go overboard, you will find out soon.

If some of your users are willing to pay more, offer a different tier of subscription. Call it Platinum, Pro, Red or whatever. Build it and they will come.

Work it out with your devs

You will probably need to integrate some survey SDK or DYI screen to ask your users since from our experience, emailing won’t make it. Response-rate is low and therefore, gathering answers is dead slow. But there are other departments your devs can speed-up testing:

Use Firebase Remote Config (or your own)

Remote config allows you to change variables inside the app without updating it. Like if you want to show on-boarding A or B. Or what product SKU you want to show in purchase screen. You can think you can easily use (Firebase) A/B testing for that, but for when you use multiple variables to define what and how you are going to show it, Remote Config is a handy option.

Change your App Store subscription products with a script

Matheus Albuquerque from STRV created a script that allows you to make news SKUs with different prices without tedious edits of the price for each country. I recommend you checking it out if you change prices in the App Store frequently.

Start with quick-wins

Shorter subscriptions are usually the best selling.  Ask your users about weekly or monthly subscription prices first. Also, the majority of app subscriptions (not games) occur during the first 24 hours. Anything purchased outside of this period might be your advantage if you offer something tempting. This is the opportunity to offer a 30%+ sale or a trial if you don’t offer it at the beginning. You can also try to wait to see if more users buy at full-price, but the 40–20–10 retention rule is merciless.

You don’t need to reinvent the wheel when offering a promotion like this. Just offer it to everyone when the majority stops purchasing, like at the 90th percentile of the time period.

Last, but not least — don’t forget that subscription improves retention, so if you are depending on user-generated content (social networks, dating, online gaming), every user counts even if you sell with the lowest possible margin.

Summary and statistics

Pricing is not easy, especially in apps. Please be sure that you are measuring 100% right things like subscription revenues and purchases. Default metrics are tricky and do not reflect reality.

Optimize for things you know you users might buy (so, ask them or better talk to them) and test at scale to get insights as soon as possible. If you do your homework, you shouldn’t get into any trouble (or you know soon at least).

Since I only have experience with the pricing of a few apps, I asked Michael Stysin from Qonversion for some statistics to confirm. Here are some interesting facts. Of course, it all depends on what your app offers, category, etc., but I think it can provide some insights:

1. The shorter subscription, the higher the revenues. The majority of purchases are monthly subscriptions
2. compared to 3, 6 or 12 months. Unless there is a weekly subscription, which can get as much as 70% of purchases. It makes sense — a weekly payment has the lowest risk of paying something you are not using anymore.
3. The usual trial conversion rate varies from 15–25%, meaning only that portion of users will transform into paying users. Android tends to be slightly better from my experience.
4. Trial users LTV ≠blended user LTV as users from trial tend to retain less, say at approx 80% of regular users.
5. Although we are hearing introductory pricing might be revenue-effective (security & self-improvement apps from my experience), Qonversion says they only see 10% of the apps using it. The concept itself might be a little less known to regular users, as a sale on the whole subscription time is more common. Count with higher product refunds and cancelations.