AppStore In-App Purchase: разбор полетов эконом-классом

О реализации механизмов монетизации iOS-приложений (In-App Purchase) написано много, но каждый раз, собираясь применить теорию на практике, сталкиваешься с неожиданными сложностями. Поэтому сегодня я хотел бы поделиться именно практическим опытом: как мы создавали, тестировали и выкладывали на AppStore приложение с возобновляемой подпиской. Название приложения не может быть предано огласке по условиям соглашения с клиентом, поэтому буду называть его электронной энциклопедией «Азбука».

Бизнес-модели iOS-приложений

Перед тем как перейти к техническим деталям проекта, я бы хотел рассмотреть ряд общих моментов, касающихся разработки iOS-приложений. Начну с существующих бизнес-моделей приложений. Первая классическая схема — платные приложения: утром деньги — вечером стулья.

1. Платные приложения

Пользователь совершает единовременный платеж, покупает приложение-стул и начинает им пользоваться. Деньги его уходят компании Apple, которая, отрезав свою долю в 30%, передает оставшуюся часть разработчику.

2. Бесплатные приложения с рекламой

Вторая модель не требует от пользователя оплаты, приложение достается ему бесплатно. Пользователь получает приложение-стул, но с замечательной рекламной ножкой. Доход от рекламы поступает Apple, -30% и дальше — на счет разработчика.

3. Бесплатные приложения с In-App Purchase

И, наконец, третья модель: пользователь опять ничего не платит и получает приложение-стул о трех ногах. Если он вдруг решает, что ему и четвертая ножка не помешает, то он может заплатить и получить еще более замечательное приложение-стул — с четырьмя ногами. Выручка -30% уходит разработчику.

Именно третья модель напрямую связана с темой статьи — Freemium = In-App Purchase. В этой модели пользователь получает базовый функционал бесплатно, а дополнительные возможности или «товары» приобретает отдельно.

Обращаю внимание читателя на то, что деньги в каждой из моделей имеют разный размер. Это неспроста.

Согласно проведенным исследованиям, доля дохода от In-App Purchase в общем доходе разработчиков выросла с 28% в 2010 году до 72% в 2011: т. е. была менее 1/3, а стала больше 2/3. In-App Purchase = ДЕНЬГИ. К слову, стоимость товаров или услуг для In-App Purchase, также как и стоимость приложения, не определяется произвольно, а должна быть выбрана из списка возможных вариантов, предлагаемых Apple. Самая низкая стоимость установлена в $0.99, самая большая — в $999.99.

Какие существуют типы In-Purchase?

Всего существует пять типов товаров/услуг, продаваемых через In-App Purchase. Их можно разделить на три группы.

1. Consumable — потребляемые или расходуемые. Самый простой пример — это ресурсы в какой-нибудь игре: золото, дерево, еда. То что приобретается и тут же тратится игроком, исчезая навсегда. В случае необходимости приобретается еще и еще, радуя разработчиков и компанию Apple.

2. Non-Consumable — товары/услуги, которые приобретаются каждым пользователем только один раз и в дальнейшем должны быть доступны всегда и на всех зарегистрированных/авторизованных устройствах. В качестве примера приведу покупку Могучего орла в AngryBirds. Также есть множество примеров, когда бесплатно распространяется базовая версия приложения, а доступ к продвинутым функциям приобретается отдельно, но всего лишь один раз.

3. Subscription — подписка. Включает в себя три вида подписок: возобновляемые, невозобновляемые и бесплатные.

• Возобновляемая подписка — очень привлекательный вариант с точки зрения бизнеса, т.к. после первой успешной оплаты, дальнейшее продление подписки происходит автоматически, при условии, что карта валидна и на ней есть деньги, и что пользователь вручную не отменил подписку. Это фактически золотая жила.
• Невозобновляемая подписка инициируется пользователем, длится выбранный разработчиком период времени и затем прекращается. Чтобы она вновь началась, от пользователя  требуется снова инициировать ее вручную, а от разработчика, соответственно, напомнить об этом пользователю. Далее мы более подробно поговорим об особенностях этого типа In-App Purchase.
• Бесплатная подписка была добавлена после появления в iOS Newsstand — специальной папки-«киоска», которая содержит все СМИ-приложения. Бесплатная подписка может быть использована СМИ-приложениями, если они предоставляют свои выпуски безвозмездно.

Итак, мы рассмотрели все типы In-App Purchase. Вопрос: может ли разработчик или компания выбрать и использовать какой-то тип произвольно, на свое усмотрение? Ответ — нет. У Apple есть свое видение и требования для каждого типа.

Требования Apple к использованию типов In-App Purchase

1. Общее правило. Через In-App Purchase можно продавать только электронные товары/услуги, а не материальные предметы.

2. Категория «СМИ». Важное ограничение: возобновляемая подписка может использоваться только для приложений, подпадающих в категорию «СМИ» или «Медиа». Например, подписка на электронные версии газет и журналов или стриминговое ТВ. А, например, услуга по сканированию и распознаванию визитных карточек может быть приобретена только на условиях невозобновляемой подписки.

Эти же ограничения действуют и для бесплатной подписки. Так, бесплатная рассылка не может использоваться для распространения демоверсий в целях продажи подписки на полные версии. В случае, если приложение было разработано без учета ограничений и рекомендаций по использованию In-App Purchase, его публикация в AppStore будет невозможна.

Возвращаясь к нашему приложению «Азбуке» скажу, что заказчика интересовал вариант реализации именно возобновляемой подписки. При этом изначально пользователю была бы доступна только незначительная часть содержания «Азбуки», а полный доступ он мог получить, только купив подписку. Т.к. суть приложения не в полной мере соответствовала критериям оценки Apple, мы со своей стороны предупредили заказчика о возможных проблемах с публикацией приложения в AppStore. Заказчик принял решение все равно реализовать именно такой вариант подписки, приняв возможные риски на себя.

Модели реализации In-App Purchase

После того как мы определились с типом In-App Purchase, необходимо было определиться с выбором модели реализации. Всего существует две модели:

• используется только пользовательское устройство и инфраструктура на стороне Apple, которая для простоты обозначена на иллюстрации как AppStore;
• к устройству и инфраструктуре Apple добавляется третье звено — сервер, свой или предоставляемый в рамках специализированной услуги третьей компании.

Плюсы второй модели

1. Гибкость. Модель дает нам большую гибкость в поддержании списка «товаров» в актуальном состоянии. Мы можем менять его, не изменяя приложение, опубликованное в AppStore.

2. Валидация транзакций. Важную функцию валидации транзакций, рекомендуют выполнять на сервере. Но при этом, естественно, возрастают расходы на разработку и текущие расходы на поддержание всей инфраструктуры приложения.

В случае с нашим приложением заказчик настоял на реализации первой модели, т.к. не хотел нести дополнительные расходы. Соответственно перед нами встал вопрос: возможно ли использовать модель без сервера для возобновляемой подписки. На следующей иллюстрации приведены типы In-App Purchase и соответствующие рекомендации по реализации той или иной модели. Попросту говоря, можно ли их реализовать без использования сервера.

Итак, сервер однозначно можно не использовать, если был выбран тип In-App Purchase Consumable. Рекомендуется использовать сервер, если используются типы: Non-Consumable, Auto-Renewing Subscriptions, Free Subscriptions. Обязательно использовать сервер, если используется Non-Renewing Subscription. Так как в этом случае Apple не предоставляет возможность восстановления сделанных покупок, и это целиком ответственность разработчика. Таким образом, для выбранного заказчиком типа In-App Purchase, использование сервера не являлось обязательным и и мы начали разработку.

Этапы реализации In-App Purchase

Этап 1. Реализация покупки товара/услуги

Пользователь приобретает подписку. Приложение отправляет запрос на проведение транзакции на сервере AppStore. В случае успешного совершения платежа в ответ присылается информация о транзакции. Если платеж был совершен успешно, мы сохраняем квитанцию (специальным образом подготовленный блок данных) и дату окончания подписки. Если же платеж не был совершен, сохраняется ограниченный доступ.

Этап 2. Реализация проверки действия подписки

Приложению необходимо проверить действие текущей подписки. Тут возможны два варианта:

• есть Интернет-соединение — ура!
• Интернет-соединения нет — так тоже бывает

В первом варианте мы по имеющимся данным квитанции о покупке, формируем запрос на сервер Apple — именно эта часть в идеале должна была быть реализована на отдельном сервере. В ответ сервер Apple присылает результат проверки. Если результат положительный — все ок, подписка действует. Если отрицательный — подписка больше не действует.

Для ситуации, когда подключение к интернету невозможно, нами была реализована следующая схема: если действие подписки еще не окончилось, а дату ее окончания мы знаем, то пользователю будет сохранен полный доступ; если же текущая дата на устройстве вышла за пределы даты окончания подписки, мы добавляем дополнительную проверку на попадание ее в так называемый «льготный период» — 10 дней. В случае, если подписка находится в данном периоде, по-прежнему оставляем полный доступ.

Такая схема была реализована для того, чтобы избежать ситуаций, когда пользователь по какой-то причине оказался вне доступа к интернету, подписка была продлена, но мы об этом ничего не знаем. Таким образом, мы сохраняем доступ к материалу и надеемся, что в течение 10 дней пользователь получит доступ к сети и мы сможем проверить реальный статус подписки. Конечно, в этом случае защиту можно обойти — отключив доступ в Интернет и переведя часы на устройстве назад, но заказчик был уверен, что среди пользователей приложения будет мало желающих обмануть защиту.

Этап 3. Реализация восстановления подписки

Если пользователь переустановил приложение или установил его на другое устройство, при этом у него есть действующая подписка, нам необходимо предоставить ему полный доступ. Для этого приложение отправляет на сервер Apple специальный запрос, в ответ на который присылаются все сделанные на текущий момент транзакции In-App Purchase конкретного пользователя для конкретного приложения. Полученные транзакции также проверяются на валидность и, в зависимости от результатов проверки, пользователь получает либо полный, либо ограниченный доступ.

Тестирование

Неотъемлемой частью любого проекта является тестирование. В тестировании In-App Purchase есть свои нюансы.

1. Sandbox. Существуют две среды, в которых работает приложение: тестовая — Sandbox — до момента, когда приложение будет опубликовано в AppStore и Production — с момента, когда приложение, наконец-то попало в AppStore, и план по захвату мира начал действовать.

Применительно к нашему приложению и любому приложению, проводящему валидацию транзакций, важно иметь в виду, что у Sandbox и Production разные ссылки на валидатор. Во время тестирования необходимо использовать ссылку на Sandbox, а после публикации приложения — на Production.

Какая ссылка должна быть задана в приложении в момент, когда оно находится на рассмотрении Apple? Ссылка на Production. В противном случае, если мы используем модель без сервера реализации  In-App Purchase валидация транзакций не будет работать. Также можно реализовать следующий алгоритм: всегда отправлять запрос на валидацию на Production-сервер и, если в ответе статус транзакции будет равен 21007 — что означает, что приложение работает в тестовой среде и ссылка неправильная — запрос отправить повторно уже на валидатор Sandbox.

2. «Машина времени». Как я уже говорил, возможные периоды подписки составляют от недели до одного года. Было бы затруднительно тестировать приложение, если бы и в песочнице подписка продлевалась в течение таких же временных отрезков. Поэтому тестовая среда — это своеобразная «машина времени», в ней неделя равняется 3 минутам, а год — часу. Более комфортные условия, не так ли?

3. Состояния подписки. Какие состояния могут быть у подписки? Куплена/действует, продлена, отменена пользователем или по причине невалидности платежной карты. В тестовой среде невозможно отменить подписку вручную, также нельзя сымитировать неправильные данные карты. Каким образом тогда можно протестировать эти ситуации? Решение заключается в том, что в тестовой среде подписка прошляется только шесть раз, после чего автоматически прекращается. Более того, даже если подписаться снова, она не будет продлеваться автоматически.

4. Использование нового тестового аккаунта пользователя. Чтобы избежать ограничение тестовой среды, необходимо использовать новый тестовый аккаунт пользователя. Что это такое? Это специальный аккаунт с Apple ID, который создается в админке iTunes Connect — там же, где происходит управление приложениями, просмотр статистики по продажам и пр. Как и у настоящего Apple ID логином тестового аккаунта служит адрес электронной почты. Он может быть произвольным и несуществующим, что существенно облегчает процедуру добавления новых пользователей для тестирования. И еще важный момент: для тестового аккаунта пользователя задается страна для AppStore, соответственно, и на устройстве, где происходит тестирование, страна должна быть такой же.

Публикация в AppStore

Когда разработка приложения завершена и тестирование окончено, наступает самый важный момент: отправка дистрибутива приложения на рассмотрение в Apple.

Напомню, изначально у нас были большие опасения, что нашу «Азбуку» «зарубят» на стадии рассмотрения по причине несоответствия выбранного типа In-App Purchase сути приложения. Так оно и случилось. Решение Apple было категоричным: тип возобновляемой подписки не подходит, используйте возобновляемую подписку. А это означало, что нам будет необходимо не просто добавить сервер, а обеспечить полную функциональность возобновляемой подписки собственным силами.

Все хорошо, что хорошо кончается

За последние полгода я знаю несколько случаев, когда через апелляцию удавалось сменить отрицательное решение на положительное или внести изменения в данные учетной записи разработчика. Поэтому, если вы уверены, что принятое решение неверно, смело подавайте апелляцию и добивайтесь пересмотра — это реально возможно.

Так было и в случае с нашим приложением. Все подробности мне неизвестны, но могу предположить, что свою роль могла сыграть категория «Энциклопедия», а также то, что период подписки в окончательном варианте был определен длительностью в год с гарантией заказчика, что он, как минимум один раз в течение этого периода, будет выпускать обновление материала.

Закончить статью я хотел бы еще одним важным моментом. Публикуя первую версию приложения в AppStore, даже если вы считаете ваш проект находится на бета-стадии, нельзя упоминать об этом ни в описании, ни в названии приложения. Пусть это будет просто первая версия с каким-то ограниченным функционалом. Опубликуйте на сайте поддержки приложения ваши планы на будущее и выпускайте новые версии, приближаясь к задуманному идеалу.