Платеж Google Play в приложении, предоставляющий товар бесплатно

У меня уже есть совершенно бесплатное приложение, опубликованное в магазине Google Play.

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

Итак, я подумал о следующем:

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

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

Ответ 1

Нет прямого способа сделать это из Google. У вас будет 2 тестовых случая: -

Существующий пользователь
Новый пользователь Вы должны хранить уникальный user-id на своем сервере, а когда вы внедряете приложение в приложении, отправьте этот идентификатор пользователя на ваш сервер.

Случай 1: - Ваш сервер будет соответствовать ему с существующей БД, если он соответствует идентификатору, возвращающему ваше успешное сообщение.

Случай 2: - Для новых пользователей вместе с этим идентификатором пользователя ваше приложение должно отправить маркер покупки на ваш сервер для проверки и после проверки покупки сервер должен отправить сообщение об успешном завершении.

Общая задача: - Когда приложение запускается, вы всегда должны вызвать функцию restoreTransaction(), после чего вы получите список из google, содержащий информацию о уже приобретенных элементах, и вы разблокируете это содержимое. Убедитесь, что у вас есть проверка сервера в приложении.

Ответ 2

Вот как вы могли бы частично выполнить то, что хотите, без использования сервера:

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

Это не идеально, но он может позволить, по крайней мере, большинству ваших настоящих пользователей продолжить доступ к функциям.

Я не знаю, нарушит ли это ваше соглашение с Google Play, и вам нужно будет самому проверить эту проблему. Тот факт, что вы представили приложение своим нынешним пользователям как бесплатное и теперь хотите взимать плату за некоторые его функции, можно рассматривать как искажение, если вы не дед у ваших существующих пользователей, и тот подход, который я только что изложил, не гарантирует, что всем существующим пользователям будет успешно предоставлен доступ.

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

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

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

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

Ответ 3

Несмотря на то, что для приложений со значительным количеством загрузок это не представляется возможным, по состоянию на январь 2016 года вы можете предоставить до 500 промокодов на каждое приложение за квартал.