Итак, у вас есть приложение с автоматическими возобновляемыми подписками. Оно прекрасно работает, пользователи безудержно оформляют премиум подписки и пишут хвалебные отзывы. Красота!
Вам, как руководителю проекта, жизненно необходимо быть в курсе ключевых метрик продукта. Одной из самых важных является Life time value (LTV) – средний доход с каждого пользователя за все время пользования приложением. Но как его вычислить в случае с авто-возобновляемыми подписками на iOS? Как отследить момент продления, отмены, возобновления подписки пользователем?
До недавних пор (а именно до 2017 года) единственным способом это сделать был так называемый Subscriptions Status Polling. В любой момент времени вы можете получить информацию о состоянии подписки, отправив нужный чек (receipt) на URL: https://buy.itunes.apple.com/verifyReceipt. Получив ее, вы можете просмотреть основные сведения о подписки, в том числе дату ее окончания. Правда ее стоимость вы никак не получите ?
Чтобы реализовать Status Polling вы должны:
- передавать и хранить на сервере все чеки обо всех подписках каждого пользователя,
- реализовать непростую серверную логику, по которой будет производиться регулярная проверка этих чеков.
Это сложно. Но в 2017 году Apple, казалось бы, решает эту проблему. На WWDC под овации аудитории они представляют Apple Subscriptions Status Update Notifications.
Что такое Subscriptions Notifications?
Apple Subscriptions Status Update Notifications это механизм отправки webhook-ов на ваш сервер от Apple, когда происходят события, относящиеся к авто-возобновляемым подпискам. Чтобы их включить, нужно предварительно настроить ваш сервер на их прием: сервер должен поддерживать протокол App Transport Security (обычно все работает по умолчанию). После этого нужно перейти в App Store Connect и в секции “App Store” настроек вашего приложения вставить ссылку, по которой Apple будет слать Post запрос всякий раз, когда будет происходить событие:
Заметьте, что Apple рекомендует использовать Subscriptions Notifications вкупе со Status Polling. Нехороший знак…
Готово! Теперь вы должны получать уведомления всякий раз, когда, например, происходит оформление, продление или отмена подписки.
Разновидности уведомлений
Apple отправляет 6 видов уведомлений, происходящих при различных событиях. Разберем каждый из них.
INITIAL_BUY
Apple отсылает это уведомление, когда пользователь впервые оформляет подписку в какой-то группе подписок.
Подробнее о группах подписок вы можете почитать в нашей статье.
CANCEL
Это событие отправляется в тот момент, когда пользователь пользователь отменяет подписку через поддержку Apple Care и возвращает деньги за покупку. Подчеркнем, здесь идет речь не об обычной отмене подписки через настройки iOS.
Событие
CANCELне отправляется при обычной отмене подписки через настройки iOS.
DID_CHANGE_RENEWAL_STATUS
Это событие было добавлено недавно. Оно отправляется, когда пользователь отключает или (заново) включает возобновление подписки через настройки iOS, приложение App Store или службу поддержки Apple:
Не путайте это событие с событием
CANCEL, которое вызывается при отмене подписки и возврате средств через поддержку Apple Care.
RENEWAL
Первое, что приходит в голову, когда вы видите название этого события: Apple отправляет его при автоматическом продлении подписки. Как бы не так!
Событие RENEWAL приходит, если:
- подписка пользователя была отменена автоматически из-за проблем с банковской картой пользователя…
- и после этого пользователь вновь возобновил подписку. Именно в этот момент отправляется событие
RENEWAL.
Cобытие
RENEWALне отправляется в случае обычного продления подписки. Вместо этого Apple предлагает проверять чек подписки через/VerifyReceiptперед и после ожидаемым продлением и анализировать полученное значениеexpiration_date
INTERACTIVE_RENEWAL
Это событие отправляется, если:
- Пользователь отменил подписку ичерез некоторое время после этого…
- пользователь вновь возобновил подписку. Именно в этот момент отправляется
INTERACTIVE_RENEWAL.
Новая подписка (которая указана в пункте 2) может отличаться от подписки из пункта 1, но они обе должны принадлежать одной группе покупок. Например, пользователь может отменить подписку на тарифный план Bronze и через некоторое время возобновить подписку, выбрав план Gold. В этом случае Apple отправит на ваш сервер событие
INTERACTIVE_RENEWAL(при условии, что подписки Bronze и Gold принадлежат одной группе покупок). Более подробно о группах подписок вы можете прочитать здесь.
DID_CHANGE_RENEWAL_PREF
Событие DID_CHANGE_RENEWAL_PREF вызывается, когда пользователь переходит с одной подписки на другую в пределах одной группы покупок:
Что в итоге?
Apple предлагает целых 6 событий, но ни одно из них отправляется при автоматическом продлении подписки в обычном режиме. Почему они так сделали? Неясно. Дополнительно вводят в заблуждение названия этих событий.
В таблице ниже приведена сводная информация о событиях.
| Наименование события | Когда отсылается |
| INITIAL_BUY | Первое оформление подписки в группе подписок |
| CANCEL | Возврат денег через Apple Care и отмена подписки |
| DID_CHANGE_RENEWAL_STATUS | Отмена или повторное включение автоматического возобновления подписки пользователем |
| RENEWAL | Возобновление подписки после ее отмены из-за проблем с банковской картой |
| INTERACTIVE_RENEWAL | Возобновление подписки после ее ручной отмены пользователем |
| DID_CHANGE_RENEWAL_PREF | Переход с одной подписки на другую в пределах одной группы подписок |
Как использовать Apple Subscriptions Notifications?
Из-за того, что самое важное событие, которое нужно для расчета LTV – продление подписки в обычном режиме, – не присылается, вам все-таки придется использовать Status Polling. Существует вероятность, что Apple добавит это событие в ближайшее время, но, даже если это и произойдет, без собственного сервера вам все равно не обойтись. Этот сервер выступит “прослойкой” между Apple и другой системой аналитики (например, Amplitude, Flurry или Mixpanel). Получая события и проверяя чеки, вы будете отсылать в нее данные о продлениях, отменах и возвратах.
Однажды мы столкнулись с этой проблемой и решили разработать сервис, который бы решил эти проблемы. Так родилась идея Apphud – сервиса аналитики подписок для iOS. Одной из его главных особенностей является отправка событий о подписках в вашу любимую систему аналитики. Apphud заполняет брешь в отправке событий со стороны Apple, практикуя гибридный подход: мы используем и Subscriptions Status Polling, и Apple Subscriptions Notifications, чтобы собирать максимально достоверную информацию. Все, что вам остается сделать – это интегрировать наш SDK и настроить интеграции с нужными системами аналитики. Остальное сделает Apphud.
Заключение
Apple Subscriptions Notifications не так хороши как кажется, потому что только с помощью них нельзя решить основную задачу: узнать, сколько денег вам приносит один пользователь. Возможно, Apple упростит жизнь разработчикам в будущем, но одно можно сказать наверняка: текущая реализация Subscriptions Notifications крайне неочевидна и похожа на костыли.