All articles Analytics Growth Infrastructure Product Updates

Resumen del nuevo modelo de suscripción y la Biblioteca de Facturación de Google Play 5.0

Kate

Durante la conferencia anual I/O, Google presentó su nueva versión principal de la Biblioteca de Facturación de Google Play. Además de las clásicas descontinuaciones y eliminaciones de métodos, también ofrecieron abundante información sobre la nueva arquitectura de las suscripciones. Esta última tiene como objetivo simplificar la forma de crear, gestionar y vender las compras dentro de la app. En este artículo, exploraré las actualizaciones de la Biblioteca de Facturación de Google Play 5.0 y profundizaré en las más interesantes.

El nuevo modelo de suscripción

El sistema de facturación de Google Play es la herramienta principal para ayudarte a monetizar tu aplicación con suscripciones. Si aún no conoces este servicio, puedes informarte en este artículo. Con la última versión de su Biblioteca, Google ha cambiado la estructura de cómo se definen los productos de suscripción, y esto ha provocado cambios en la forma de venderlos dentro de la app y de gestionarlos en su backend.

Con la Biblioteca de Facturación de Google Play 5.0., Google ha introducido una nueva arquitectura de suscripción que añade elementos como los planes básicos y las ofertas. Vamos a echarle un vistazo.

Supongamos que tu app tiene una suscripción prémium y ofreces a tus clientes suscripciones semanales, mensuales y anuales. Antes de estas actualizaciones, habrías tenido que crear tres suscripciones diferentes. Es decir, una por período. A continuación, imagínate que quieres ofrecer una prueba gratuita a los usuarios que hayan abandonado tu app para convencerlos de que vuelvan. En ese caso, también tendrías que crear una suscripción anual adicional que incluyese una prueba gratuita.

Y estas son tan solo dos de las situaciones más comunes por las que se creaban muchas suscripciones con el modelo de suscripción anterior, pero podría haber muchos más ejemplos.

Sin embargo, a partir de ahora, podrás gestionar todos estos supuestos con una sola suscripción. Google ha dividido el modelo de suscripción en tres entidades: la suscripción propiamente dicha, los planes básicos y las ofertas.

La nueva entidad de suscripción incluye:

un identificador
un título
una descripción
información sobre los impuestos

El resto de la información se configura mediante planes básicos y ofertas.

Un plan básico incluye:

identificador
tipo de renovación (renovación automática o prepago)
duración
periodo de gracia
precios y disponibilidad para las distintas regiones
algunos ajustes de menor importancia

Puedes conocer toda la lista de detalles en la documentación oficial.

Una oferta incluye:

identificador
criterios de elegibilidad: una opción que determina qué usuarios pueden acceder a la oferta (los que se suscriben por primera vez, los que se actualizan de una suscripción a otra o los que determina el desarrollador),
fases: incluyen las pruebas gratuitas y los pagos únicos o recurrentes (el uso de las fases se muestra en la captura de pantalla que hay a continuación),
un descuento en el precio: ya sea una cantidad fija, un porcentaje o un descuento absoluto en función del precio del plan básico.

Cada suscripción puede contener uno o más planes básicos y estos, a su vez, pueden contener varias ofertas (véase el esquema anterior). Por lo tanto, para el ejemplo anterior, puedes crear una suscripción prémium con tres planes básicos (uno por período) y una oferta con una prueba gratuita para el plan básico anual.

La compra de nuevas suscripciones

Y a propósito del código, en la Biblioteca de Facturación de Google Play 5.0, la clase SkuDetails ha quedado obsoleta, así como cualquier otra entidad o método que contenga Sku en su nombre. Ahora, hay que considerar el uso de ProductDetails para ese fin. Los detalles del producto incluyen información sobre una suscripción. Por ejemplo, sus planes básicos y sus ofertas.

Antes, solicitabas detalles de la suscripción como los que se muestran a continuación:

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

billingClient.querySkuDetailsAsync(params) { 
        billingResult, skuDetailsList -> // Process the result
}

Ahora, deberías hacer lo siguiente:

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
}

Y, para lanzar el flujo de compra, usabas las siguientes construcciones:

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

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

Mientras que, ahora, deberían parecerse a lo siguiente:

// 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)

También puedes echar un vistazo a los ejemplos de migración en la guía de migración oficial de Google. Eso sí, ten en cuenta que hay algunas erratas en sus ejemplos, pero se han corregido aquí.

Veamos los cambios.

Como he mencionado, ahora tienes que utilizar ProductDetails para solicitar los detalles de la suscripción y el flujo de compra. Además, deberás proporcionar un offerToken a los parámetros del flujo de facturación, ya que cada ProductDetails puede contener varias ofertas. Ten en cuenta que la selección de detalles de la oferta (productDetails.subscriptionOfferDetails) siempre incluye detalles del plan básico (si existe algún plan básico), por lo que incluso si tu suscripción contiene solo un plan básico sin ofertas, seguirá teniendo un offerToken para la compra.

Puedes observar que el nuevo flujo de compra acepta múltiples ProductDetails en vez de un SkuDetails como en la versión anterior. No obstante, si proporcionas más de un ProductDetails, el flujo terminará con un error. La guía oficial de migración da el ejemplo erróneo sobre el uso de los métodos setProductDetails y setOfferToken justo en la clase BillingFlowParams.Builder, pero solo está disponible el método setProductDetailsParamsList para estos fines. Parece como si, recientemente, Google hubiera decidido pasar de los detalles de producto únicos a los múltiples. Esto muestra una visión de futuro en la que la facturación admitirá varias compras de suscripción diferentes al mismo tiempo.

El resto del flujo (es decir, el procesamiento de la compra) sigue siendo el mismo que en la Biblioteca de Facturación de Google Play 4.0.

Compatibilidad retroactiva de las suscripciones

Bueno, hasta ahora, todo suena bien, pero ¿qué pasa si no quieres migrar ahora mismo? Google se ha encargado de ello.

A pesar de que Google Play Console ya funciona únicamente con el nuevo modelo de suscripción, todas las suscripciones antiguas se convierten al nuevo formato automáticamente. Por lo tanto, se conserva su retrocompatibilidad con versiones anteriores. Esto quiere decir que verás tus suscripciones en el nuevo formato en Google Console, pero podrás seguir trabajando con ellas de la misma forma en la que lo hacías antes en tu app.

De igual manera, también podrás observar que todas las suscripciones antiguas pasan a ser de solo lectura tras la migración. Por ello, Google te advierte de que la edición inhabilitará la compatibilidad con la API de InAppProducts de esa suscripción.

Es posible que utilices esta API en tu backend para obtener algunos detalles del producto, así que ten cuidado. Y es que, después de hacer editable la suscripción, surgirán errores (como se muestra a continuación) de esa API si intentas obtener información de la suscripción que se ha convertido. Lo mismo ocurrirá con todas las nuevas suscripciones creadas después del 11 de mayo.

HTTP code - 422
Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}

Así pues, si utilizas la API de InAppProducts, considera la posibilidad de actualizarla antes de crear nuevas suscripciones o editar las antiguas.

Mientras navegas por la nueva interfaz de suscripciones en Google Play Console, encontrarás etiquetas «retrocompatible» cerca de los planes básicos y las ofertas de las suscripciones. Esto implica que si compras esas suscripciones utilizando SkuDetails compatibles (como se hace en la Biblioteca de Facturación de Google Play 4.0), comprarás exactamente esos planes básicos u ofertas compatibles. Si solo hay un plan básico compatible, sin ninguna oferta que también lo sea, se comprará ese plan básico. Si hay tanto un plan básico como una oferta compatibles que estén disponibles, en ese caso, si la oferta se puede aplicar al usuario actual, se comprará. Si no, solo se comprará el plan básico. Si quieres, puedes elegir otro plan básico/oferta como retrocompatible con versiones anteriores.

Nota: esta retrocompatibilidad hace referencia a la Biblioteca de Facturación de Google Play, pero no a la API de InAppProducts. Como se ha mencionado anteriormente, si empiezas a utilizar las nuevas funciones (por ejemplo, varios planes básicos u ofertas para una suscripción) o, simplemente, la conviertes de solo lectura a editable, esa suscripción puede seguir siendo retrocompatible para una app, pero no para la API.

Otras actualizaciones

Ha habido varias actualizaciones menores en la Biblioteca de Facturación de Google Play 5.0 que vale la pena mencionar, aunque sea brevemente.

Se ha eliminado el método obsoleto queryPurchases de la Biblioteca de Facturación de Google Play 4.0.
Ya no hay solicitudes sincronizadas, solo queryPurchasesAsync.
launchPriceChangeFlow ha quedado obsoleto: el nuevo flujo de cambio de precios recomendado requiere la confirmación de los clientes a través de la página de suscripciones de Google Play, por lo que se deben utilizar enlaces profundos para navegar por allí en lugar de recurrir al método BillingClient.
Se ha añadido el método setIsOfferPersonalized para indicar un precio personalizado para los clientes de la Unión Europea siguiendo la Directiva de Derechos del Consumidor. Esta opción añade una línea en la parte inferior de la pantalla de compra de Facturación de Google en la que se indica que el precio se ha personalizado.

El nuevo modelo de suscripción y Qonversion

Mientras trabajamos en la asistencia de la Biblioteca de Facturación de Google Play 5.0, puedes seguir utilizando el SDK de Qonversion para tus compras dentro de la app. Ahora, utilizamos la Biblioteca de Facturación de Google Play 4.0, lo que significa que solo podemos gestionar aquellas suscripciones con planes básicos y ofertas retrocompatibles. Todavía es posible editar las propiedades que estaban disponibles en el modelo de suscripciones anterior, como el precio, el período de gracia, la duración de la prueba, etc., así como crear nuevas suscripciones. Solo hay que asegurarse de que, después, tengas al menos un plan básico retrocompatible y, si es necesario, una oferta retrocompatible. Además, sigue siendo necesario contar con un identificador de suscripción completo para configurar los productos en nuestro centro de productos, no identificadores de planes básicos u ofertas.

Si tienes cualquier consulta, no dudes en comunicárnosla. Estaremos encantados de ayudarte.