So, you have an application with automatic renewable subscriptions. It works great, users unrestrainedly make out premium subscriptions and write laudatory reviews. Beauty!
Hello everyone, my name is Denis, I am the project manager for Apphud, an analytics service for auto-renewable subscriptions for iOS apps.
As a project manager, you need to be aware of key product metrics. One of the most important is Life time value (LTV) - the average income per user for the entire time of using the application. But how to calculate it in the case of auto-renewable subscriptions for iOS? How to track the time of the renewal, cancellation, renewal of the subscription by the user?
Until recently (namely, until 2017), the only way to do this was the so-called Subscriptions Status Polling. At any time you can get information about the status of a subscription by sending the desired receipt (receipt) to the URL: https://buy.itunes.apple.com/verifyReceipt . After receiving it, you can view basic information about the subscription, including the end date. True, its value, you still do not get it.
To implement Status Polling, you must:
It's complicated. But in 2017, Apple seemed to solve this problem. At WWDC, under the applause of the audience, they represent Apple Subscriptions Status Update Notifications.
Apple Subscriptions Status Update Notifications is a mechanism for sending webhook-s to your Apple server when events related to auto-renewable subscriptions occur. To enable them, you must first configure your server to accept them: the server must support the App Transport Security protocol (usually everything works by default). After that, you need to go to App Store Connect and in the “App Store” section of the settings of your application insert a link by which Apple will send a POST request every time an event occurs:
Note that Apple recommends using Subscriptions Notifications along with Status Polling. Bad sign ...
Done! Now you should receive notifications whenever, for example, you subscribe, renew, or cancel a subscription.
Apple sends 6 types of notifications occurring at various events. Let us examine each of them.
Apple sends this notification when a user first subscribes to a group of subscriptions .
You can read more about subscription groups in our article .
This event is dispatched when a user cancels a subscription through Apple Care support and returns money for the purchase. We emphasize that this is not about the usual cancellation of a subscription through iOS settings.
The CANCEL
event is not sent during a normal subscription cancellation via iOS settings.
This event has been added recently. It is sent when the user disconnects or (re-enables) the renewal of the subscription through the iOS settings, the App Store application or Apple support:
Do not confuse this event with the CANCEL
event, which is triggered when a subscription is canceled and funds are returned via Apple Care support.
The first thing that comes to mind when you see the name of this event: Apple sends it when the subscription automatically renews. No matter how wrong!
The RENEWAL
event RENEWAL
dispatched when:
the user's subscription was automatically canceled due to problems with the user's bank card ...
and after that the user renewed the subscription. This is RENEWAL
event is RENEWAL
.
The RENEWALRENEWAL
not dispatched in the case of a regular renewal of a subscription. Instead, Apple offers to check the subscription check via/VerifyReceipt
before and after the expected renewal and analyze the resulting value ofexpiration_date
This event is dispatched if:
The user canceled the subscription and some time after that ...
User renewed subscription. It is at this point that INTERACTIVE_RENEWAL
sent.
A new subscription (which is listed in clause 2) may differ from the subscription from clause 1, but they both must belong to the same shopping group. For example, a user may cancel a subscription to the Bronze tariff plan and after a while resume the subscription by selecting the Gold plan. In this case, Apple will send the INTERACTIVE_RENEWAL
event to your server (provided that the Bronze and Gold subscriptions belong to the same shopping group). You can read more about subscription groups here .
DID_CHANGE_RENEWAL_PREF
sent when a user goes from one subscription to another within the same shopping group:
Apple offers as many as 6 events, but none of them are sent when the subscription is automatically renewed normally. Why did they do that? It is not clear. Additionally, the names of these events are misleading.
The table below summarizes the events.
Due to the fact that the most important event that is needed for calculating LTV - subscription renewal in the normal mode - is not sent, you still have to use Status Polling. There is a possibility that Apple will add this event in the near future, but even if this happens, you will not be able to do without your own server. This server will act as an “interlayer” between Apple and another analytics system (for example, Amplitude, Flurry or Mixpanel). By receiving events and checking checks, you will send information about renewals, cancellations and returns.
Once we ran into this problem and decided to develop a service that would solve these problems. This is how the idea of ​​the service we are working on was born - the subscription analytics service for iOS, which fills the gap in sending events from Apple.
Apple Subscriptions Notifications are not as good as they seem, because it is not possible to solve the main task only 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.
Source: https://habr.com/ru/post/453770/
All Articles