Automatic renewable subscriptions have already become the gold standard in making money on iOS applications. Why not? Users continuously receive the service they need, the programmer can predict their cash flow. And it’s no secret: in most cases, choosing a subscription model allows the developer to earn more.
This is the first article in the subscription cycle. In it, I tried to collect the most important information about auto-renewable subscriptions. My name is Denis and I am developing the Apphud service that allows you to transfer subscription events (for example, renewals, cancellations, etc.) to third-party analytics services (such as Flurry, Mixpanel and Amplitude).
Everything is as simple as possible here. You offer the user access to your content or functionality on a regular basis. The user regularly (for example, monthly or weekly) pays for this access: at the end of the subscription period, Apple writes off the cost of the subscription from his bank card.
Apple is trying to charge money from the user 24 hours before the expected subscription end time. If the withdrawal failed, Apple will attempt to debit the money for the next 60 days .
The length of the subscription period may vary: 1 week, 1 month, 2 months, 3 months, 6 months, 1 year. The developer himself determines this value.
Do not forget about the trial period (trial, free) period in which the user can try a subscription for free. At the end of the trial period, if the user has not canceled it, Apple will attempt to charge him for the full cost of the subscription for the next period.
Generally speaking, the trial period is a special case of the so-called introductory offers (Introductory offers). Apple distinguishes 3 types of introductory offers: trial, payment upon use (Pay as you go), prepayment (Pay up front). We’ll talk about introductory sentences below.
Each subscription is a separate product that you create in App Store Connect. As an example, consider the fictional application DropCloud - cloud photo storage for the iPhone. The application proposes to issue one of two tariff plans: Silver and Gold, each of which offers the user 50 or 100 GB of cloud storage, respectively. In addition, in the application, you can subscribe to the weekly paid newsletter with recommendations and useful tips from the world's best photographers. This subscription, for example, is called Inspiration. Then each of the following subscriptions will be a separate product:
Products are grouped into product groups. Each product can belong to only one group. In our case there will be two such groups. Let's call the first Cloud, and the second - News. Then the product structure will look like this:
At any time, a user can have only one active subscription in each group. In our case, the user can simultaneously subscribe to the Gold tariff and the Inspiration newsletter, but cannot have Gold and Silver active subscriptions at the same time.
Create more than one group of subscriptions only when you really can't do without it.
All products within one group are grouped into levels (Levels). Depending on the subscription level, the user is offered one or another list of available functions or, in our case, the amount of cloud storage. Levels should be sorted in descending order: from subscriptions with the highest level of service to the lowest.
Why do we need levels? It's not as simple as it seems. Apple uses levels when it comes to downgrades, upgrades and crossgrades subscriptions. This happens when a user within a group switches from one active subscription to another (for example, from Gold to Silver). In this case, Apple takes into account the levels to calculate the cost and duration of the new subscription. We will look at this topic in one of the following articles.
A developer may at one time offer its new users special offers for subscriptions. Apple calls them introductory (Introductory offers). They are of three types: trial, payment after use (Pay as you go), prepayment (Pay up front). The first of them - the trial - we have already reviewed. Look closely at the other two.
This payment model provides a one-time discount for one or more payment periods. At the end of these periods, the regular subscription cost will be charged to the user. For example, the user may be asked to subscribe to a service worth $ 3.99 per month. This price will be valid for 2 months, after which it will be able to continue using the service at the regular price of $ 9.99 per month.
The price of this offer on the fact of use must be lower than the regular price of the subscription. For example, you cannot offer the user to pay $ 19.99/month for the first two months, and after - $ 9.99 per month. This issue is partially resolved with the help of the “Pay up front” introductory offer.
In this model, you offer the user to pay immediately for several months (1, 2, 3, 6 or 12) in advance. At the end of this period, the user will pay a subscription on standard terms. For example, you can offer to pay a subscription for cloud storage immediately for 3 months in advance with a discount of $ 14.99. And in 3 months the user will pay $ 9.99 per month. There are 2 significant differences of this model from the Payment upon use:
The cost of the prepayment does not have to be less than the cost of the main subscription.
The number of validity periods is always 1. In other words, the offer is valid for only one period of 1, 2, 3, 6 or 12 months.
Promotional offers are a great way to get back users who have been active subscribers in the past. As well as introductory, promotional offers are subscriptions for special conditions that are valid for a limited time.
The main differences between promotional offers and introductory offers are:
Setting up promotional offers is a rather difficult task that requires setting up your own server. We will look at how to set up promotional offers in one of the following articles.
A user can cancel a subscription at any time. He can cancel it in one of the following ways:
Subscription will also be automatically canceled in the following cases:
A good practice is to try and get a lost customer back. For example, offer him to subscribe for a promotional offer, or at least find out his reasons for canceling the subscription.
... net of tax, if you can keep the user for a year. The standard Apple commission is 30%. However, if the user had an active subscription in your application throughout the year, then the amount of commission after this year will be reduced to 15%.
There is one assumption in this rule: during this year the subscription may cease to be active (for example, the user canceled it through the settings or there was a problem with the payment) for a period of not more than 60 days . This period is called the grace period. It starts exactly at the moment when the subscription stops. If it is activated again within the next 60 days, the countdown of the coveted year to a 15% commission is not reset.
Grace-period is also not reset when upgrading, downgrading and cross-grading subscriptions within one group of subscriptions.
You can raise or lower your subscription prices at any time. But when you change the price there are several nuances that we now consider.
Everything is simple: price cuts affect all users with this active subscription - both current and future. For the first, the reduced price will be applied in the next payment period. For the future, obviously, right away.
When raising prices, you can choose one of two options:
In the second version, current subscribers will receive push and email notifications from Apple asking if they agree with the price increase. If the user agrees, the increased price will be applied in the next payment period. Otherwise, the subscription will be canceled.
Think about it a few times before raising prices for current subscribers. This is fraught with the loss (possibly) of many active subscribers who did not agree with the new conditions. Apple recommends raising prices gradually and on cohorts: first of all, increase prices for those users who already pay the price closest to the new one. Then the increase will affect the next closest to new price cohort of users. And so on.
As we can see, the topic of automatic renewable subscriptions in iOS is quite extensive. There are many nuances that need to be considered when designing, analyzing and making decisions regarding subscriptions.
One of the important and difficult tasks is tracking subscriptions and sending information about major events (such as subscription renewal, cancellation or refund via Apple support) to an analytics system (like Firebase, Amplitude or Mixpanel). Why do you need it? Without this, it is impossible, for example:
And, for example, offer the user a discount, find out why he canceled the subscription, or ask for billing updates.
Unfortunately, Apple does not provide a convenient tool for this (App Store Connect analytics does not count: it does not allow analyzing subscriptions for a specific user).
We ourselves have long ago encountered this problem and decided to develop a tool that eliminates these shortcomings. So the idea of the project, which we are working on, was born.
In future articles, we will examine subscriptions in more detail, including the technical aspects of their creation, validation of checks, promotional offers, and so on.
Source text: 7 things to know about auto-renewable subscriptions