So, you have the app with auto-renewable subscriptions. It works perfectly, your users purchase premium subscriptions and write amazing reviews. So cool!
As a product owner it’s essential for you to know your app’s key metrics. One of the most important metrics is LifeTime value (LTV). This value shows how much money do you earn per user during his life cycle. But how could you calculate it in case of subscriptions? How to track when subscription renews, cancels or is being refunded?
The only way to know this until 2017 was Subscriptions Status Polling. You could receive a subscription’s info at any moment by sending its receipt to URL: https://buy.itunes.apple.com/verifyReceipt. Once you receive it, you could view some information, including expiration date. However, it’s impossible to get subscription’s price ?
To implement Status Polling you should:
- send and save all subscriptions receipts on your server and
- implement quite complicated server logic. According to it you will check these receipts on regular basis.
This’s difficult. But in 2017 Apple seemed to solve this problem. In WWDC it shows Apple Subscriptions Status Update Notifications.
What are Subscriptions Notifications?
Apple Subscriptions Status Update Notifications is a way to send webhooks on your server from Apple when something happens to your subscriptions. To enable them you should set up your server first: the server must conform to App Transport Security protocol (it usually conforms to it by default). After that you should go to App Store Connect and insert a special link at “App Store” section. Apple will send a POST request every time when subscription-based event happens:
Note, that Apple recommends to use Status Polling in addition to Subscriptions Notifications. Not a good sign…
All set! Now you will receive notifications every time when a subscription, for example, starts or cancels.
Notification types
There are 6 different notifications you could receive from Apple. Let’s look through each of them.
INITIAL_BUY
Apple sends this notification when a user purchases a subscription at a first time in some subscriptions group.
You can read about subscriptions groups in our another article.
CANCEL
Apple sends this notification, when user cancels subscriptions through Apple Care support and refunds his money. Please note: this is not about the normal cancellation of a subscription through iOS settings.
Cancelnotification is not being sent if user cancels a subscription through iOS settings.
DID_CHANGE_RENEWAL_STATUS
This notification was added recently. You will receive it when user cancels or re-enables a subscription through iOS settings, App Store app or Apple Support:
Do not confuse this event with the
CANCELevent, which is triggered when a subscription is canceled via Apple Care support.
RENEWAL
The first idea when you see a name of this event: Apple sends this notification when a subscription renews. No, Apple doesn’t think so.
RENEWAL notification is being sent if:
- a user’s subscription was canceled automatically due to billing issueand…
- was re-enabled again manually by a user.
In this case Apple sends RENEWAL notification.
RENEWALnotification is not being sent in case of usual subscription renewal. Instead of this Apple offers to check subscription’s receipt using/VerifyReceiptbefore and after expecting expiration date. And analyze itsexpiration_date.
INTERACTIVE_RENEWAL
This notification is being sent if a user canceled his subscription and after some time re-enabled it.
A new subscription (which a user re-enabled) may be different from initial subscription, but both of them must be in one products group. For example, a user may cancel a subscription to Bronze plan and after some time choose Gold plan and re-enabled subscription. In this case Apple will send
INTERACTIVE_RENEWALnotification to our server (Bronze and Gold must be in one subscriptions group). You can read more about subscriptions groups here.
DID_CHANGE_RENEWAL_PREF
DID_CHANGE_RENEWAL_PREF notification is being sent when a user switches from one subscription to another. Both subscriptions must be in our subscriptions group:
In a nutshell
Apple offers as many as 6 events, but none of them is being sent after usual renewal? Why did they do so? Don’t know. Additionally, the names of these events are misleading.
Here is the list of all notifications:
| Notification | When it is being sent |
| INITIAL_BUY | Initial subscription in some subscriptions group |
| CANCEL | Subscription cancellation and refund through Apple Care |
| DID_CHANGE_RENEWAL_STATUS | Subscription cancellation or re-activation by a user |
| RENEWAL | Subscription cancellation due to billing issue |
| INTERACTIVE_RENEWAL | Subscription re-activation after its manual cancellation |
| DID_CHANGE_RENEWAL_PREF | Switch from one subscription to another in one subscription group |
How to use Apple Subscriptions Notifications?
Because Apple doesn’t send you a real renewal event, you will have to implement Status Polling to calculate LTV. Apple may add this event in the future, but even if this happens you will still have to use own server. The server will be a “layer” between Apple and another analytics (like Amplitude, Flurry or Mixpanel). You will check receipts and will send notifications about renewals, cancellations and refunds to analytics.
Once we faced the same problem and decided to create a service which could solve this problem. This is how Apphud was born. Apphud is iOS subscriptions analytics tool. One of its main features is sending subscriptions-based notifications to your favorite analytics tool. Apphud fills the gap in sending events from Apple, practicing a hybrid approach: we use both Subscriptions Status Polling and Apple Subscriptions Notifications to collect the most accurate information. All you need if to integrate our lightweight SDK and setup integrations. Apphud will do the rest.
The project is currently in beta. So if you would like to participate in it, visit Apphud and leave your email. That’s it! So easy!
Conclusion
Apple Subscriptions Notifications are not as good as they seem, because it is not possible to solve the main task with the help of them: find out how much money one user brings to you. Perhaps Apple will make life easier for developers in the future, but one thing is for sure: the current implementation of Subscriptions Notifications is not very obvious and looks like crutches.