Новая модель подписки и обзор Google Play Billing Library 5.0

Во время ежегодной конференции I/O компания Google представила новую основную версию библиотеки Google Play Billing Library. Помимо классических изменений и удалений методов, была также представлена обширная информация о новой архитектуре подписок, которая призвана упростить способ создания, управления и продажи покупок in-app. В этой статье я рассмотрю обновления Google Play Billing Library 5.0 и углублюсь в самые интересные из них.

Новая модель подписки

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

В Google Play Billing Library 5.0. Google представил новую архитектуру подписки, которая добавляет такие сущности, как базовые планы и предложения. Давайте посмотрим.

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

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

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

Новая сущность подписки включает в себя:

  • идентификатор
  • название
  • описание
  • информация о налогах

Остальная информация настраивается через базовые планы и предложения.

Базовый план содержит:

  • его идентификатор
  • тип продления (автопродление или предоплата)
  • продолжительность
  • льготный период
  • цены и доступность для разных регионов
  • и некоторые менее важные параметры.

Весь список деталей вы можете найти в официальной документации.

Предложение содержит:

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

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

Приобретение новых подписок

Говоря о коде, в Google Play Billing Library 5.0 класс SkuDetails устарел, как и все остальные сущности или методы, содержащие Sku в своем имени. Теперь вам следует рассмотреть возможность использования ProductDetails для этих целей. Детали продукта содержат информацию о подписке, включая ее базовые планы и предложения.

Раньше вы запрашивали сведения о подписке, как показано ниже:

val params = SkuDetailsParams.newBuilder()
    .setType(BillingClient.SkuType.SUBS)
    .setSkusList(listOf("premium"))
    .build()

billingClient.querySkuDetailsAsync(params) { 
        billingResult, skuDetailsList -> // Process the result
}
Войти в полноэкранный режим Выйти из полноэкранного режима

Теперь вы должны сделать следующее:

val productList = listOf(
    QueryProductDetailsParams.Product.newBuilder()
        .setProductType(BillingClient.SkuType.SUBS)
        .setProductId("premium")
        .build()
)

val params = QueryProductDetailsParams.newBuilder()
    .setProductList(productList)
    .build()

billingClient.queryProductDetailsAsync(params) {
    billingResult, productDetailsList -> // Process the result
}
Войти в полноэкранный режим Выйти из полноэкранного режима

А для запуска потока покупок вы использовали следующие конструкции:

val billingFlowParams = BillingFlowParams.newBuilder()
    .setSkuDetails(skuDetails)
    .build()

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)
Войти в полноэкранный режим Выйти из полноэкранного режима

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

// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription.
val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return

val productDetailsParamsList = listOf(
    BillingFlowParams.ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setOfferToken(offerToken)
        .build()
)

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(productDetailsParamsList)

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) 
Войти в полноэкранный режим Выход из полноэкранного режима

Вы также можете посмотреть примеры миграции в официальных шагах миграции Google. Обратите внимание, что в их примерах есть несколько опечаток, которые исправлены здесь.

Давайте рассмотрим изменения.

Как я уже упоминал, теперь вы должны использовать ProductDetails для запроса деталей подписки и потока покупок. Кроме того, вы должны предоставлять offerToken в параметрах потока биллинга, поскольку каждый ProductDetails может содержать несколько предложений. Обратите внимание, что массив деталей предложения (productDetails.subscriptionOfferDetails) всегда содержит детали базового плана (если существует какой-либо базовый план), поэтому даже если ваша подписка содержит только базовый план без предложений, она все равно будет иметь offerToken для покупки.

Вы могли заметить, что новый поток покупки принимает несколько ProductDetails, а не один SkuDetails, как в предыдущей версии. Но если вы предоставите более одного ProductDetails, поток будет завершен с ошибкой. В официальном руководстве по интеграции приводится неправильный пример использования методов setProductDetails и setOfferToken прямо на классе BillingFlowParams.Builder, но для этих целей доступен только метод setProductDetailsParamsList. Похоже, что Google решил перейти от единичных сведений о продукте к множественным совсем недавно, имея в виду будущее, когда биллинг будет поддерживать сразу несколько различных покупок по подписке.

Остальной поток — а именно обработка покупки — остается таким же, как и в библиотеке Google Play Биллинг 4.0.

Обратная совместимость подписок

Пока все звучит хорошо, но что если вы не хотите переходить на новую версию прямо сейчас? Google позаботился об этом.

Несмотря на то, что Google Play Console уже работает только с новой моделью подписки, все старые подписки конвертируются в новый формат автоматически, сохраняя их обратную совместимость. Это означает, что вы видите свои подписки в новом формате в Google Console, но можете работать с ними, как и раньше, в своем приложении.

Вы также заметите, что после миграции все старые подписки становятся доступными только для чтения. Google предупреждает, что редактирование отключит поддержку API InAppProducts для этой подписки.


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

HTTP code - 422
Non-existent in-app product: com.qonversion.sample/ProductId{productId=article_test_trial}
Вход в полноэкранный режим Выход из полноэкранного режима

Итак, если вы используете API InAppProducts, подумайте о его обновлении перед созданием новых подписок или редактированием старых.

При просмотре пользовательского интерфейса новых подписок в Google Play Консоли вы найдете метки «Обратная совместимость» рядом с базовыми планами и предложениями подписок. Это означает, что если вы покупаете эти подписки с помощью устаревшего SkuDetails (как это делается в Google Play Billing Library 4.0), вы купите именно те совместимые базовые планы/предложения. Если есть только совместимый базовый план без совместимого предложения, то будет куплен именно этот базовый план. Если есть совместимые базовый план и предложение, то если предложение подходит текущему пользователю, то будет куплен базовый план, в противном случае — базовый план. При желании вы можете выбрать другой базовый план/предложение в качестве обратно совместимого.


Примечание — эта обратная совместимость относится к библиотеке Google Play Billing Library, но не к InAppProducts API. Как уже упоминалось, если вы начнете использовать новые возможности, например, несколько базовых планов или предложений для одной подписки или просто переведете ее из режима «только для чтения» в режим редактирования, эта подписка все еще может быть обратно совместимой для приложения, но не для API.

Другие обновления

В библиотеке Google Play Billing Library 5.0 было несколько незначительных обновлений, о которых стоит кратко упомянуть.

  • Удален метод queryPurchases, устаревший в Google Play Billing Library 4.0 — больше никаких синхронизированных запросов, только queryPurchasesAsync.
  • Добавлен метод setIsOfferPersonalized для указания персонализированной цены для клиентов из ЕС в соответствии с Директивой о правах потребителей. Этот параметр добавляет строку в нижнюю часть экрана покупки Google Биллинга, отмечая, что цена является персонализированной.

Новая модель подписки и Qonversion

Пока мы работаем над поддержкой Google Play Billing Library 5.0, вы все еще можете использовать Qonversion SDK для покупок внутри приложения. Сейчас мы используем Google Play Billing Library 4.0, что означает, что мы можем управлять только подписками с обратно совместимыми базовыми планами и предложениями. Вы по-прежнему можете редактировать свойства, которые были доступны в предыдущей модели подписки, такие как цена, льготный период, продолжительность пробной версии и так далее, а также создавать новые подписки. Просто убедитесь, что после этого у вас остался хотя бы один обратно совместимый базовый план и, при необходимости, обратно совместимое предложение. Кроме того, для настройки продуктов в Product Center нам по-прежнему требуется идентификатор подписки целиком, а не идентификаторы базового плана или предложения.

Если у вас возникнут вопросы, пожалуйста, сообщите нам. Мы будем рады помочь вам.

Полезные ссылки

  • Примечания к выпуску Google Play Биллинг Библиотека 5.0
  • Руководство по миграции Google Play Биллинг-библиотеки с 4 на 5
  • Руководство по изменениям подписки на май 2022 года
  • Последние изменения в подписках в Play Консоли
  • Понимание подписок

Оцените статью
Procodings.ru
Добавить комментарий