Apphud – Integrate, analyze and improve subscriptions in your iOS app
Разработка

Руководство по Apple Subscriptions Notifications для iOS. Так ли они хороши?

Итак, у вас есть приложение с автоматическими возобновляемыми подписками. Оно прекрасно работает, пользователи безудержно оформляют премиум подписки и пишут хвалебные отзывы. Красота!

Вам, как руководителю проекта, жизненно необходимо быть в курсе ключевых метрик продукта. Одной из самых важных является Life time value (LTV) – средний доход с каждого пользователя за все время пользования приложением. Но как его вычислить в случае с авто-возобновляемыми подписками на iOS? Как отследить момент продления, отмены, возобновления подписки пользователем?

До недавних пор (а именно до 2017 года) единственным способом это сделать был так называемый Subscriptions Status Polling. В любой момент времени вы можете получить информацию о состоянии подписки, отправив нужный чек (receipt) на URL: https://buy.itunes.apple.com/verifyReceipt. Получив ее, вы можете просмотреть основные сведения о подписки, в том числе дату ее окончания. Правда ее стоимость вы никак не получите ?

Чтобы реализовать Status Polling вы должны:

  1. передавать и хранить на сервере все чеки обо всех подписках каждого пользователя,
  2. реализовать непростую серверную логику, по которой будет производиться регулярная проверка этих чеков.

Это сложно. Но в 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 Status Update Notifications

Заметьте, что Apple рекомендует использовать Subscriptions Notifications вкупе со Status Polling. Нехороший знак…

Готово! Теперь вы должны получать уведомления всякий раз, когда, например, происходит оформление, продление или отмена подписки.

Разновидности уведомлений

Apple отправляет 6 видов уведомлений, происходящих при различных событиях. Разберем каждый из них.

INITIAL_BUY

Apple отсылает это уведомление, когда пользователь впервые оформляет подписку в какой-то группе подписок.

Подробнее о группах подписок вы можете почитать в нашей статье.

Событие INITIAL_BUY
Событие INITIAL_BUY

CANCEL

Это событие отправляется в тот момент, когда пользователь пользователь отменяет подписку через поддержку Apple Care и возвращает деньги за покупку. Подчеркнем, здесь идет речь не об обычной отмене подписки через настройки iOS.

Событие CANCEL не отправляется при обычной отмене подписки через настройки iOS.

Событие CANCEL
Событие CANCEL

DID_CHANGE_RENEWAL_STATUS

Это событие было добавлено недавно. Оно отправляется, когда пользователь отключает или (заново) включает возобновление подписки через настройки iOS, приложение App Store или службу поддержки Apple:

Не путайте это событие с событием CANCEL, которое вызывается при отмене подписки и возврате средств через поддержку Apple Care.

Событие DID_CHANGE_RENEWAL_STATUS
Событие DID_CHANGE_RENEWAL_STATUS

RENEWAL

Первое, что приходит в голову, когда вы видите название этого события: Apple отправляет его при автоматическом продлении подписки. Как бы не так!

Событие RENEWAL приходит, если:

  1. подписка пользователя была отменена автоматически из-за проблем с банковской картой пользователя…
  2. и после этого пользователь вновь возобновил подписку. Именно в этот момент отправляется событиеRENEWAL.
Facepalm

Cобытие RENEWALне отправляется в случае обычного продления подписки. Вместо этого Apple предлагает проверять чек подписки через /VerifyReceipt перед и после ожидаемым продлением и анализировать полученное значение expiration_date

Событие RENEWAL
Событие RENEWAL

INTERACTIVE_RENEWAL

Это событие отправляется, если:

  1. Пользователь отменил подписку ичерез некоторое время после этого…
  2. пользователь вновь возобновил подписку. Именно в этот момент отправляется INTERACTIVE_RENEWAL.

Новая подписка (которая указана в пункте 2) может отличаться от подписки из пункта 1, но они обе должны принадлежать одной группе покупок. Например, пользователь может отменить подписку на тарифный план Bronze и через некоторое время возобновить подписку, выбрав план Gold. В этом случае Apple отправит на ваш сервер событие INTERACTIVE_RENEWAL (при условии, что подписки Bronze и Gold принадлежат одной группе покупок). Более подробно о группах подписок вы можете прочитать здесь.

Событие INTERACTIVE_RENEWAL
Событие INTERACTIVE_RENEWAL

DID_CHANGE_RENEWAL_PREF

Событие DID_CHANGE_RENEWAL_PREF вызывается, когда пользователь переходит с одной подписки на другую в пределах одной группы покупок:

Событие 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 крайне неочевидна и похожа на костыли.