Administra tu catálogo de productos

En esta guía, se explica cómo usar la API de Google Play Developer para crear y administrar un catálogo de productos para tu app de Play.

Para vender productos en tu app a través del sistema de facturación de Google Play, debes configurar un catálogo con todos los productos que quieras poner a disposición de tus usuarios para que los compren. Esto se puede hacer a través de Play Console, o bien puedes automatizar la administración del catálogo con la API de Google Play Developer. La automatización puede ayudarte a garantizar que tu catálogo esté siempre actualizado y a escalar a catálogos grandes en los que la coordinación manual no es práctica. En esta guía, verás cómo usar la API de Play Developer para crear y administrar un catálogo de productos para tu app de Play. Consulta nuestra guía Preparativos para obtener instrucciones sobre cómo configurar la API de Google Play Developer para tu integración de backend.

APIs de Catalog Management

Para obtener información sobre los diferentes tipos de productos que puedes vender con el sistema de facturación de Google Play, consulta Información sobre los tipos de productos integrados en la aplicación y consideraciones sobre el catálogo. Google ofrece dos conjuntos principales de APIs para la administración del catálogo en Play, que corresponden a las dos categorías principales de productos:

  • Productos únicos
  • Productos de suscripción

Productos únicos

Los productos únicos (antes conocidos como productos integrados en la aplicación) usan el modelo de objetos de productos únicos, que te permite configurar múltiples opciones de compra y ofertas para tus productos únicos. El modelo de objetos de productos únicos te brinda mayor flexibilidad en la forma de vender productos y reduce la complejidad de administrarlos. Tus productos integrados en la aplicación existentes se migrarán al modelo de objetos de productos únicos. Para obtener más información, consulta Migración de productos integrados en la aplicación.

Los extremos monetization.onetimeproducts y inappproducts te permiten administrar productos únicos desde tu backend. Esto incluye la creación, actualización y eliminación de productos, y la administración de precios y disponibilidad. Según cómo manejes las compras de productos únicos, modelarás productos consumibles (se pueden comprar tantas veces como se desee) o derechos permanentes (el mismo usuario no los puede realizar dos veces). Puedes decidir qué productos únicos deben ser consumibles y cuáles no.

Productos de suscripción

El extremo monetization.subscriptions te ayuda a administrar los productos de suscripción desde el backend del desarrollador. Puedes crear, actualizar y borrar suscripciones, o controlar su disponibilidad y precios regionales. Además del extremo monetization.subscriptions, también proporcionamos monetization.subscriptions.basePlans y monetization.subscriptions.basePlans.offers para administrar, respectivamente, los planes básicos y las ofertas de las suscripciones.

Métodos por lotes

Los extremos onetimeproducts, inappproducts y monetization.subscriptions proporcionan varios métodos por lotes que permiten recuperar o administrar hasta 100 entidades en la misma app al mismo tiempo.

Los métodos por lotes, cuando se usan con la tolerancia a la latencia habilitada, admiten un mayor rendimiento y son especialmente útiles para los desarrolladores de catálogos grandes para la creación inicial del catálogo o la conciliación del catálogo.

Comparación entre la latencia de propagación de actualizaciones y la capacidad de procesamiento

Una vez que se completa una solicitud de creación o modificación de un producto, es posible que los cambios no sean visibles de inmediato para los usuarios finales en sus dispositivos debido a demoras en el procesamiento de la red o del backend. De forma predeterminada, todas las solicitudes de modificación de productos son sensibles a la latencia. Esto significa que están optimizados para propagarse rápidamente a través de los sistemas de backend y, por lo general, se reflejan en los dispositivos de los usuarios finales en cuestión de minutos. Sin embargo, hay un límite por hora en la cantidad de solicitudes de modificación de este tipo. En los casos en los que necesites crear o actualizar muchos productos (por ejemplo, durante la creación inicial de un catálogo grande), puedes usar métodos por lotes con el campo latencyTolerance establecido en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Esto aumentará significativamente la capacidad de procesamiento de las actualizaciones. Las actualizaciones tolerantes a la latencia tardarán hasta 24 horas en propagarse a los dispositivos de los usuarios finales.

Configuración de cuotas

Existen varios límites de cuota que debes tener en cuenta cuando usas la API de Play Developer para administrar tu catálogo de productos:

  1. Las APIs de Google Play Developer están organizadas en categorías llamadas buckets, y cada bucket tiene su propio límite de cuota por minuto. Para obtener más información, consulta Cuotas.
  2. Los extremos de modificación de productos también aplican un límite de 7,200 consultas por hora. Este es un límite único para los productos únicos y las suscripciones, y para todas las solicitudes de modificación, incluidas las de creación, actualización, activación y eliminación. Las llamadas a métodos de modificación por lotes se consideran una consulta para esta cuota, independientemente de la cantidad de solicitudes individuales incluidas o su sensibilidad a la latencia.
  3. Las modificaciones sensibles a la latencia también tienen un límite de 7,200 modificaciones por hora. En el caso de los métodos por lotes, cada solicitud de modificación anidada se considera por separado a los efectos de esta cuota. Esta cuota solo tiene implicaciones prácticas para los usuarios de la API por lotes que realizan actualizaciones sensibles a la latencia, ya que, en otros casos, la cuota 2 se agotará antes o al mismo tiempo que esta cuota.

A continuación, se incluyen varios ejemplos ilustrativos para comprender el uso de la cuota de diferentes solicitudes:

  • Una sola solicitud get para recuperar un elemento consumirá 1 token de la cuota 1 y ningún token de las cuotas 2 y 3 (ya que solo se relacionan con los extremos de modificación).
  • Una solicitud get por lotes para recuperar hasta 100 elementos también consumirá 1 token de la cuota 1 y ningún token de las cuotas 2 y 3.
  • Una sola solicitud de modification para un elemento consumirá 1 token de la cuota 1 y 1 token de la cuota 2. Si la solicitud es sensible a la latencia, también consumirá 1 token de la cuota 3. Dado que la cuota C tiene el mismo límite que la cuota 2, no tiene implicaciones prácticas para los usuarios que solo utilizan métodos de modificación únicos.
  • Una solicitud modification por lotes para 100 elementos tolerantes a la latencia consumirá 1 token de la cuota 1 y 1 token de la cuota 2. Esta configuración de cuota debería permitir un margen amplio para mantener actualizado tu catálogo, pero si tu algoritmo no tiene en cuenta esta cuota y supera esta tasa, es posible que recibas un error por cada llamada adicional.
  • Una solicitud modification por lotes para 100 elementos sensibles a la latencia consumirá 1 token de la cuota 1, 1 token de la cuota 2 y 100 tokens de la cuota 3.

Recomendaciones de uso de la API de Catalog Management

Si cumples con estos lineamientos, optimizarás tus interacciones con la API y garantizarás una experiencia de administración del catálogo fluida y eficiente.

Supervisa tu uso

Debes tener en cuenta los procesos de uso intensivo. Por ejemplo, al comienzo de la integración, es más probable que tus extremos de administración del catálogo consuman más cuota para crear tu catálogo inicial completo, lo que podría afectar el uso en producción de otros extremos, como la API de estado de compra, si te acercas al límite de uso general. Debes supervisar el consumo de tu cuota para asegurarte de no exceder las cuotas de la API. Existen varias formas de supervisar el uso. Por ejemplo, puedes usar el panel de cuotas de las APIs de Google Cloud o cualquier otra herramienta de supervisión de APIs interna o de terceros que elijas.

Optimiza el uso de la cuota de la API

Se recomienda optimizar el consumo de tarifas para minimizar la probabilidad de errores de la API. Para implementar esto de manera eficaz, te recomendamos que hagas lo siguiente:

  • Elige la estrategia de administración de catálogos adecuada. Una vez que comprendas la cuota de la API, deberás elegir la estrategia adecuada para que tu aplicación alcance tus objetivos de administración del catálogo de manera eficiente.
  • Solo realiza la cantidad mínima de llamadas que necesitas para reflejar tus cambios.
  • No envíes llamadas de modificación redundantes o innecesarias a las APIs. Esto podría requerir que mantengas un registro de cambios en tu catálogo de backend.
  • No superes el límite de 7,200 consultas por hora para las modificaciones de productos. Es posible que desees crear procesos de sincronización que requieran que realices una gran cantidad de modificaciones de productos en un período breve (por ejemplo, la creación de un catálogo inicial). Si esperas que estos procesos superen el límite por hora, implementa esperas según sea necesario para reducir el uso a un nivel seguro. Considera usar métodos por lotes con actualizaciones tolerantes a la latencia para lograr un mayor rendimiento.
  • Prepárate de forma proactiva para escalar. A medida que tu aplicación crezca, es posible que debas aumentar el uso de la API y los distintos extremos. Lee la documentación sobre las cuotas de la API de Google Play Developer para obtener detalles sobre cómo aumentar tu cuota cuando te acerques al uso máximo.
  • Programa de forma estratégica los procesos pesados. Intenta programar los procesos de catálogo pesados en torno a los picos de uso críticos. Por ejemplo, puedes evitar ejecutar una sincronización completa del catálogo durante los horarios de mayor venta de la semana.

Agrega lógica de control de errores de cuota

Sin importar la eficiencia con la que compiles tu lógica de administración del catálogo, debes hacerla resistente a los límites de cuota inesperados, ya que los extremos utilizados en los módulos independientes de tu integración comparten la cuota diaria. Asegúrate de incluir errores de limitación de cuota en tu control de errores y de implementar las esperas adecuadas. Cada llamada que se realice a las APIs de Google Play Developer generará una respuesta. En caso de que falle una llamada, recibirás una respuesta de error que incluye un código de estado de respuesta HTTP y un objeto errors, que proporciona más detalles sobre el dominio del error y un mensaje de depuración. Por ejemplo, si superas tu límite diario, es posible que veas un error similar al siguiente:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "usageLimits",
    "message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
  Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
  "reason" : "dailyLimitExceeded",
  "extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
  } ],
}

Implementación de la administración del catálogo

Los desarrolladores usan los extremos de publicación de productos de la API de Google Play Developer para mantener sincronizado su catálogo entre su backend y Google Play. Asegurarte de que tu catálogo de Google Play esté siempre actualizado con la información más reciente del catálogo de tu backend tiene ventajas para crear una mejor experiencia del usuario. Por ejemplo:

  • Podrás consultar la lista completa de ofertas disponibles y administrar las etiquetas de ofertas y planes básicos para influir en tu propia lógica de elegibilidad y presentación de ofertas.
  • Puedes verificar los diferentes precios y detalles de los productos que ven los usuarios en las distintas plataformas, y asegurarte de que sean coherentes.
  • Tendrás a mano los detalles del producto en tu backend cuando proceses compras nuevas, sin necesidad de aumentar la latencia ni el riesgo de fallas realizando llamadas adicionales a la API de Google Play Developer durante los flujos críticos del usuario.

Existen ciertos límites y consideraciones que debes tener en cuenta cuando crees tu catálogo de productos en Google Play. Una vez que comprendas estos límites y sepas cómo deseas estructurar tu catálogo, es hora de decidir tu estrategia de sincronización.

Estrategias de sincronización del catálogo

Los extremos de publicación de la API de Google Play Developer te permiten actualizar tu catálogo a medida que se producen cambios. En ocasiones, es posible que debas adoptar un enfoque de actualizaciones periódicas, en el que envíes una serie de cambios en el mismo proceso. Cada enfoque requiere diferentes opciones de diseño. Cada estrategia de sincronización se adaptará mejor a algunos casos de uso que a otros, y es posible que tengas un conjunto de necesidades que requieran ambas, según la situación. A veces, es posible que desees actualizar un producto en el momento en que te enteras de un cambio nuevo, por ejemplo, para procesar una actualización urgente del producto (es decir, se debe corregir un precio incorrecto lo antes posible). En otras ocasiones, puedes usar una sincronización periódica en segundo plano para garantizar que tus catálogos de backend y de Play sean siempre coherentes. Lee algunos casos de uso comunes en los que te convendría implementar estas diferentes estrategias de administración del catálogo.

Cuándo enviar actualizaciones a medida que cambia tu catálogo local

Lo ideal es que las actualizaciones se realicen en cuanto haya algún cambio en el catálogo de productos de tu backend para minimizar las discrepancias.

Este tipo de actualizaciones es una buena opción en los siguientes casos:

  • Debes asegurarte de que tus productos estén siempre actualizados.
  • Debes realizar algunos cambios en tus productos todos los días.
  • Debes actualizar los productos que ya están en producción y se venden.

Este enfoque es más sencillo de implementar y te permite mantener tu catálogo sincronizado con el período de discrepancia más pequeño.

Cuándo usar las actualizaciones periódicas

Las actualizaciones periódicas se ejecutan de forma asíncrona en la edición del producto en tu backend y son una buena opción en los siguientes casos:

  • No tienes que asegurarte de que tus productos se actualicen con poca antelación.
  • Debes planificar actualizaciones masivas o procesos de conciliación.
  • Ya tienes un sistema de administración de contenido o de catálogos para controlar tus productos digitales, y este actualiza tu catálogo constantemente.

En el caso de catálogos grandes, considera usar métodos por lotes con actualizaciones tolerantes a la latencia para lograr la máxima capacidad de procesamiento.

Crea tu catálogo de productos

Si tienes un catálogo grande para subir a Google Play, te recomendamos que automatices la carga inicial. Este tipo de proceso pesado funciona mejor si se sigue una estrategia periódica combinada con métodos por lotes tolerantes a la latencia.

Crea productos únicos

Para la creación inicial y única del catálogo de productos, te recomendamos que uses monetization.onetimeproducts.batchUpdate o el método inapp_products.insert con el campo allowMissing establecido en true y el campo latencyTolerance establecido en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Esto minimizará el tiempo que se tarda en crear el catálogo dentro de los límites de la cuota.

Crea productos de suscripción

Para la creación inicial de un catálogo grande de suscripciones, te recomendamos que uses el método monetization.subscriptions.batchUpdate con el campo allowMissing establecido en true y el campo latencyTolerance establecido en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Esto minimizará el tiempo que lleva crear el catálogo dentro de los límites de la cuota.

Para catálogos de suscripciones más pequeños, la API de Play Developer proporciona el método monetization.subscriptions.create. Como alternativa, puedes crear suscripciones con el método monetization.subscriptions.patch y el parámetro allowMissing, como se describe en la sección Actualizaciones de productos.

Todos los métodos anteriores crean suscripciones junto con sus planes básicos (que se proporcionan dentro del objeto Subscription). Inicialmente, estos planes básicos están inactivos. Para administrar el estado de los planes básicos, puedes usar el extremo monetization.subscriptions.basePlans, lo que incluye activar un plan básico para que esté disponible para la compra. Además, el extremo monetization.subscriptions.basePlans.offers te permite crear y administrar ofertas.

Actualizaciones del producto

Los siguientes métodos te permiten modificar de manera eficiente tus productos existentes, lo que garantiza que tus ofertas se alineen con los ajustes más recientes.

Actualiza productos únicos

Los siguientes métodos están disponibles para ayudarte a actualizar los productos únicos existentes.

  • monetization.onetimeproducts.batchUpdate
  • inappproducts.patch : El extremo de parche se usa para actualizar un recurso de forma parcial. Esto significa que puedes actualizar campos específicos que indiques en el cuerpo de la solicitud. Por lo general, el extremo de parche se usa cuando solo necesitas actualizar algunos campos de un recurso.
  • inappproducts.update : El extremo de actualización se usa para actualizar un recurso en su totalidad. Esto significa que deberás enviar el objeto de recurso completo en el cuerpo de la solicitud. Por lo general, el extremo de actualización se usa cuando necesitas actualizar todos los campos de un recurso. Cuando el parámetro allowMissing se establece en true y el ID de producto proporcionado aún no existe, el extremo insertará el producto en lugar de fallar.
  • inappproducts.batchUpdate : Es una versión por lotes del endpoint de actualización, que te permite modificar varios productos con una sola consulta. Úsalo junto con el campo latencyTolerance establecido en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT para lograr un mayor rendimiento.

Actualiza los productos de suscripción

Para actualizar las suscripciones existentes, puedes usar el método monetization.subscriptions.patch. Este método toma los siguientes parámetros obligatorios:

  • packageName: Es el nombre del paquete de la app a la que pertenece la suscripción.
    • productId: Es el ID de producto único de la suscripción.
  • regionsVersion: Es la versión de configuración de la región.

A menos que crees una suscripción nueva con el parámetro allowMissing, debes proporcionar el parámetro updateMask. Este parámetro es una lista separada por comas de los campos que deseas actualizar.

Por ejemplo, si solo deseas actualizar la ficha de un producto de suscripción, especificarías el campo listings en el parámetro updateMask.

Puedes usar monetization.subscriptions.batchUpdate para actualizar varias suscripciones al mismo tiempo. Úsalo junto con el campo latencyTolerance establecido en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT para lograr un mayor rendimiento.

Para activar, desactivar o borrar planes básicos, o bien migrar suscriptores a las versiones de precios de planes básicos más recientes, usa el extremo monetization.subscriptions.basePlans.

Además, puedes actualizar las ofertas de tus planes básicos con el método monetization.subscriptions.basePlans.offers.patch.

Conciliación del catálogo

Ya sea que elijas actualizar tu catálogo de Google Play cada vez que cambie el catálogo de tu backend o de forma periódica, si tienes un sistema de administración de catálogos o una base de datos fuera del catálogo de Google Play, podría haber situaciones en las que se desincronice con el catálogo de la configuración de tus apps en Play. Esto podría deberse a cambios manuales de emergencia en el catálogo de la consola, una interrupción en tu sistema de administración de catálogos o, tal vez, si perdiste tus datos más recientes.

Puedes crear un proceso de conciliación del catálogo para evitar un período prolongado de discrepancias.

Consideraciones del sistema de diferencias

Te recomendamos que crees un sistema de diferencias para detectar las incoherencias y conciliar los dos sistemas. Estos son algunos aspectos que debes tener en cuenta cuando crees un sistema de diferencias para mantener sincronizados tus catálogos:

  • Comprende los modelos de datos: El primer paso es comprender los modelos de datos del CMS para desarrolladores y la API de Google Play Developer. Esto incluye conocer los diferentes tipos de datos que se almacenan en cada sistema y cómo se relacionan los diferentes elementos de datos entre sí.
  • Define las reglas de diferencias: Una vez que comprendas los modelos de datos, deberás definir las reglas de diferencias. Estas reglas determinarán cómo se comparan los datos en los dos sistemas. Por ejemplo, es posible que desees hacer coincidir los IDs de productos y comparar los atributos clave de la suscripción y sus planes básicos y ofertas asociados.
  • Implementa un algoritmo de diferencias: Una vez que hayas definido las reglas de diferencias, deberás implementar el algoritmo de diferencias. Este algoritmo tomará los datos de los dos sistemas y los comparará según las reglas que definiste. Para obtener los datos del catálogo de Google Play, puedes usar los métodos monetization.onetimeproducts.list, monetization.onetimeproducts.batchGet, inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list y monetization.subscriptions.batchGet.
  • Generar informes de diferencias: El algoritmo de diferencias generará un informe de diferencias. En este informe, se mostrarán las diferencias entre ambos sistemas.
  • Concilia las diferencias: Una vez que generes el informe de diferencias, deberás resolverlas. Esto puede implicar actualizar los datos en tu CMS o en Google Play con los extremos de administración del catálogo de la API de Developer, según cómo suelas actualizar tu catálogo. Para conciliar los productos que no están sincronizados, usa los extremos de actualización como se describe en la sección Actualizaciones de productos.

Obsolescencia del producto

La API de Google Play Developer proporciona los siguientes métodos para ayudarte a desaprobar tus productos:

En el caso de los productos únicos, haz lo siguiente:

Para productos de suscripción:

Es posible que sea necesario descontinuar un producto en varias situaciones, como las siguientes:

  • Se creó por error.
  • Se suspenderá una función o un servicio.

Te recomendamos que incorpores la baja de productos en tu estrategia de administración del catálogo.