Подписки in-app purchase

С каждым годом требования к in-app подпискам в мобильных приложениях в App Store и Google Play меняются, становится все сложнее учесть их с первого раза и не получить серию реджектов, тем самым откладывая релиз порой на несколько месяцев. Если про требования для App Store уже достаточно много публикаций (см. здесь или здесь), то с правилами in-app подписок для Google Play все еще иногда возникают вопросы.

Мы, команда из Центрального Маркетинга Mail.ru Group, решили разобраться в этом подробнее и поделиться рекомендациями по внедрению in-app подписок. По нашему наблюдению, нередко пользователи оставляют большое количество негативных отзывов (и, как следствие, у приложения снижается рейтинг), где уточняют будет ли списываться сумма за полную версию продукта ежемесячно или единоразово, как отменить подписку, в какой именно момент спишутся деньги, почему деньги продолжают списываться и другие подобные вопросы. А поддержка и вовсе иногда может не справляться с объемом запросов.

И вот, в апреле 2020 года Google обновил требования к платным in-app подпискам и обязал любые новые приложения или обновления приложений, опубликованные после 16 апреля 2020 года соответствовать требованиям последней версии Правил программы для разработчиков. Согласно данным правилам, приложениям, которые были опубликованы до 16 апреля 2020 года предоставляется 60 дней с этой даты, чтобы начать соответствовать новым требованиям, то есть до 16 июня 2020 года.

Мы уверены, что новые меры платных in-app подписок в Google Play помогут сделать условия получения услуг для пользователя более прозрачными, а также построить более доверительные отношения между пользователем и разработчиком. Мы подробно изучили данные требования, проанализировали более 100 случайных приложений и хотим поделиться своим опытом и рекомендациями с читателями.

Итак, приступим:

1. Старайтесь указывать, что оплата за платную in-app подписку будет списываться каждый расчетный период
   
   Иногда пользователи уточняют у разработчиков, будет ли списана сумма единоразово или же за каждый расчетный период. Если в вашем приложении есть обе модели: единоразовая оплата (т.е. навсегда) и платная in-app подписка, лучше указать, что в первом случае оплата происходит только один раз, а во втором за каждый расчетный период.
   
   Ниже мы привели пример реализации, где четко прописаны условия оплаты разных in-app покупок.
   
   
   
2. Не забудьте проверить отображение цены на экране in-app подписки
   
   Убедитесь, что вы указываете именно ту сумму, которая спишется со счета пользователя единоразово. Например, нарушением может считаться, если на годовой подписке, стоимостью $49 вы покажете только цену в $4 в месяц.
   
   Если полная стоимость подписки явно не выделена на экране, пользователь может не понять, что при оформлении подписки будет списано не $4, а $49.
   
   Ниже мы привели два примера реализации: слева указана цена за год, справа указана цена за 1 месяц в опции про 12, что команда ревьюеров может счесть за нарушение.
   
   
3. Добавьте информацию о предложении и условиях использования in-app подписки
   
   Она чаще всего указывается разработчиками в нижней части экрана. При этом, по нашему опыту, необязательно, чтобы текст был виден полностью (иногда это физически невозможно) и достаточно показать превью первых нескольких строк и остальную часть раскрывать ниже (или вовсе, открывать условия по ссылке). Например, в тексте могут быть указаны условия предоставления пробного периода и когда будут списаны средства со счета, информация об автоматическом продлении и сроках, правила отмены и управления in-app подпиской.
4. Не забудьте добавить опцию закрытия экрана предложения in-app подписки
   
   Может считаться нарушением, если на экране с предложением подписки отсутствует кнопка Закрыть. Несмотря на то, что на Android устройствах можно вернуться на предыдущий экран по нажатию на системную кнопку Назад, на экране с предложением об in-app стоит выделять данную опцию отдельно. Мы замечали, что некоторые разработчики отображают эту кнопку только спустя несколько секунд нахождения на экране, что также может ввести пользователя в заблуждение.
   
   Ниже приведен пример, где на экране отсутствует возможность закрыть окно, что может считаться нарушением.
   
   
   
   
   Кстати, несколько приложений при нажатии на кнопку Закрыть показывают особенное one-time предложение, что может повысить конверсию в покупку. Примеры реализации ниже:
   
   
5. Проверьте приложение на мислид с бесплатной пробной версией
   
   Известный маркетинговый трюк, который может быть посчитан как нарушение, ведь пользователь может быть введен в заблуждение. Пробную бесплатную версию, конечно же, можно предоставлять пользователям, но советуем четко указывать какой период она будет длиться.
   
   Ниже приведен пример, где за предложением Попробовать бесплатно отсутствуют какие-либо условия.
   
   
   
   
   Кстати, однажды на одном из наших UX-тестирований выяснилось, что для собственного спокойствия пользователи хотели бы видеть дополнительную информацию о конкретной дате, когда спишутся деньги. Например, такие фразы как Не переживайте! Средства будут списаны не ранее 01/08, или Вы можете отменить подписку в любое время внушают доверие пользователям и они охотнее оформляют пробную версию.
6. А если у вас вводная цена? Подумайте о том, как лучше рассказать о ее условиях
   
   Например, если обычная стоимость подписки $4,99 в месяц, но для большего привлечения новых пользователей вы предлагаете первые три месяца за $1, стоит заранее проинформировать об этом пользователя.
7. Расскажите о правилах отмены in-app подписки
   
   Советуем убедиться, что ваше предложение раскрывает информацию об отмене и управлении in-app подпиской. Согласно правилу Google Play, при отмене купленной в приложении in-app подписки возврат средств за текущий расчетный период не производится, но контент остается доступным на протяжении текущего расчетного периода. После in-app подписка будет отменена и повторных списаний не будет.
8. А также, не забываем про добавление возможности восстановить покупки
   
   Для улучшения пользовательского опыта рекомендуем добавить возможность восстановить покупки (опцию можно реализовать, например, в настройках приложения или на самом экране предложения). Так, поменяв телефон, пользователь сможет быстро восстановить расширенную версию приложения.
   
   Со своей стороны, Google также ввел новшества, чтобы напрямую предоставлять пользователям более полную информацию о платных in-app подписках. Например, теперь пользователи получают электронные письма до того, как закончится бесплатная пробная версия или ознакомительная цена, или когда будет автоматически продлена долгосрочная подписка на 3, 6 или 12 месяцев. Также придет напоминание, что удаление приложения не приведет к автоматической отмене подписки.
9. И, конечно же, важна локализация условий использования и предоставления предложения
   
   Если ваше приложение локализовано на различные языки, то мы рекомендуем позаботиться и о локализации правил и условий использования in-app подписки.
   
   Ниже мы привели такой пример из приложения. А по ссылке вы найдете локализацию условий одного из наших приложений на 12 языков.
   
   
   

Заключение

На первый взгляд может показаться, что обновленная политика и наши рекомендации могут сыграть не в пользу разработчика, но если посмотреть на это с другой стороны, то в долгосрочной перспективе данные меры могут помочь выстроить более доверительные отношения между разработчиком приложения и пользователями, так как понятно изложенная информация будет повышать осведомленность и способствовать снижению количества отмен in-app подписок. Более того, новые меры могут сократить количество плохих отзывов из-за непонимания механизма in-app покупок, и повысить репутацию приложения в глазах пользователей, что, на наш взгляд, может привести к более стабильным доходам.

Также у разработчиков появилось несколько новых точек оптимизации in-app подписок в приложении. Уже сейчас доступна возможность уменьшить процент отмены подписок благодаря опции преимущества. При намерении отменить оплату у пользователя появится экран с перечислением тех самых преимуществ, которые разработчик указал в специальном поле в настройках товара в Google Play Console. Кроме того, есть возможность генерировать кастомные промокоды на расширенную версию приложения. В отличие от текущих одноразовых промокодов, новые промокоды могут быть активированы сразу несколькими пользователями. Это позволит специалистам сферы маркетинга использовать кастомные промокоды в рекламных кампаниях для более эффективного привлечения пользователей.

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

Успехов в монетизации!

P.S.: Подписывайтесь на наш Телеграм-канал, где мы делимся полезной информацией про оптимизацию приложений в App Store и Google Play.

На сегодняшний день около 80% мобильных приложений работают по подписочной системе. Благодаря этому мы имеем сотни разных подходов к тому как и когда показать пользователю экран с предложением подписки, как мотивировать пользователя на покупку, чем лучше завлечь пользователя.

При встраивании подписок, иногда упускаются важные вопросы:

• как и где хранить id для предлагаемых продуктов?
• как часто планируется итерация по новым продуктам?
• на каком этапе работы приложения стоит запрашивать продукт? На запуске или перед показом экрана
• есть ли время на встраивание сложной системы для работы с продуктами или необходим быстрый запуск?

В отличие от огромного количества UX-подходов для работы с подписками, техническое решение имеет всего два пути развития:

1. Мы переносим всю работу на сервер
2. Вся логика работы с продуктами остается на клиенте

У каждого подхода есть плюсы и минусы, далее мы рассмотрим следующие вопросы:

1. Хранение id продуктов: клиент или сервер?
2. В какой момент работы приложения стоит запросить продукты?
3. Кэшировать или не кешировать продукты?
4. Аналитика покупок: и снова клиент или сервер?

Итак, погнали!

Хранение id продукта

Как только вы задумаетесь о встраивании подписки или иной любой внутренней покупки в приложение, на сцену выходит id продукта небольшая сущность, обычно в виде строки, которой вы будете оперировать на протяжении всего процесса работы с подписками.

И появляется головная боль, как и где хранить этот самый id: захардкодить на устройстве или получать с сервера.

При хранении на клиенте вам не нужно задумываться о контрактах работы с бекендом или поиском SaaS решения, если в вашем проекте отсутствует надобность в сервере. Вы просто сохраняете массив нужных вам id продуктов внутри приложения, запрашиваете их и показываете. В целом вы даже можете довольно быстро итерироваться по разным подпискам, просто обновляя приложение в store.

Но что если нам хочется чего-то большего? Что если нам хочется AB-тестов, что если мы хотим взять и при помощи парочки кнопок заменить во всем приложении старый продукт на новый? А, ну и, конечно, у нас при этом достаточно свободного времени. Тут на сцену и выходит сервер.

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

1. Как клиент будет понимать к какому виду продуктов относится данный id
2. Как различать на экране покупки какие продукты где показывать

Также стоит всегда иметь массив id продуктов на случай если сервер, вдруг, неожиданно "отвалится". Поскольку в ином случае есть шанс упустить пользователей, которые могут с удовольствием заплатить за ваш продукт, но просто не иметь такой возможности из-за технических неполадок.

Запрос продуктов и кэширование

Когда запрашивать продукты? Это второй вопрос, о котором всегда стоит задуматься перед началом встраивания подписок в наше приложение. Поскольку чем раньше мы загрузим продукты, тем раньше мы сможем предложить пользователю купить нашу подписку. И в случае с клиентским хранением все обычно однозначно: запросили, сохранили, показали.

То в случае, когда мы работаем с сервером появляется разветвление. Потому что мы можем иметь желание показать пользователю только самое актуальное предложение: менеджер мог обновить новые подписки в тот момент, когда пользователь зашел в приложение и в итоге увидит старое предложение. При таком подходе стоит отложить запрос до момента захода пользователя на экран или запрашивать продукты в фоне раз в n-времени, но если пользователь уже зашел на экран, то стоит показать то, что уже было закешировано, чтобы избежать ожидания пользователя.

Сконцентрируемся немного на процессе запроса id продуктов с сервера и самих продуктов уже от Apple.

На данной диаграмме изображен процесс получения id продуктов с учетом возможности, что сервер может отвалиться, в таком случае мы всегда имеем список запасных id продуктов для загрузки. Если сервер возвращает ошибку, то чтобы не запрашивать бесконечно id, мы можем выставить лимит на попытки и, при достижении лимита, запросить продукты из локального стора. Но можно пойти "хитрым путем" и, запросив запасные продукты, продолжить стучаться на сервер раз в n-времени, и если id все же будут получены, то в таком случае можно по ним запросить актуальные продукты и подменить их кэше во время работы с приложением.

Однако стоит учитывать, что при таком подходе появляется промежуточный результат, при котором любой A/B тест способен сломаться. Представим ситуацию: пользователь заходит на экран покупки и видит продукты, загруженные из запасного списка. Затем пользователь выходит с экрана и продолжает пользоваться приложением. За это время загружаются актуальные продукты и снова показываются пользователю, и в этот раз пользователь совершает покупку. В такой ситуации перед бизнесом появляется вопрос, на который есть множество ответов, среди которых придется долго искать истину:Что мотивировало купить пользователя совершить покупку в этот раз?

Данный вопрос можно разрешить следующим образом

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

Итог

Встраивание покупок само по себе несложное действие, но стоит задуматься о том, как в дальнейшем будет развиваться ваш проект и продукт. Задайте себе вопросы:

• Я планирую делать большой продукт или маленький пет-проект?
• Как в дальнейшем я планирую развивать подписки?
• У меня есть время на разработку сложного решения?

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