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 aplicación de Play.

Para vender productos en tu app mediante el sistema de facturación de Google Play, necesitas lo siguiente: para configurar un catálogo con todos los productos que quieras que estén disponibles compra por parte de los usuarios. Esto se puede hacer desde Play Console automatizar la administración de catálogos con la API de Google Play Developer. La automatización puede ayudan a garantizar que tu catálogo esté siempre actualizado y se adapta a catálogos grandes donde la coordinación manual es poco práctico. En esta guía, aprenderás a usar la API de Play Developer para crear y administrar un catálogo de productos para tu app de Play. Consulta la guía Preparación para obtener instrucciones sobre cómo configurar la API de Google Play Developer para la integración de backend.

APIs de Catalog Management

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

• Productos únicos
• Productos de suscripción

Productos únicos

El extremo inappproducts te permite administrar una sola vez productos de tu backend. Esto incluye crear, actualizar y borrar y administrar los precios y la disponibilidad. Según cómo manejes las compras de productos únicos, modelarás productos de consumo (se pueden comprar las veces que se desee) o productos permanentes derechos (el mismo usuario no puede hacerlo dos veces). Puedes decidir qué Los productos únicos deben ser consumibles o no.

Productos de suscripción

El extremo monetization.subscriptions te ayuda a administrar las suscripciones productos de tu backend de 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 administrarlos respectivamente suscripciones planes básicos y ofertas.

Métodos por lotes

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

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

Actualiza la latencia de propagación en comparación con la capacidad de procesamiento

Después de que se completa una solicitud de creación o modificación de un producto, es posible que no se realicen cambios visible de inmediato para los usuarios finales en sus dispositivos demoras en el procesamiento. De forma predeterminada, todas las solicitudes de modificación de productos son sensibles a la latencia. Esto significa se optimizan para una propagación rápida a través de sistemas de backend, por lo general, en los dispositivos del usuario final en cuestión de minutos. Sin embargo, hay un límite por hora sobre la cantidad de esas solicitudes de modificación. Para los casos en los que necesitas crear o actualizar muchos productos (por ejemplo, durante creación inicial de un gran catálogo), puedes usar métodos por lotes con el El campo latencyTolerance se estableció en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT Esto aumentará significativamente la capacidad de procesamiento de las actualizaciones. Actualizaciones tolerantes a la latencia demorará hasta 24 horas en propagarse a los dispositivos del usuario final.

Configuración de la cuota

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

1. Las APIs de Google Play Developer tienen un límite predeterminado de 200,000 consultas por día. Este límite de cuota se aplica a la agregación de uso en todos los endpoints, incluidas las APIs de administración de catálogos.
2. Los endpoints de modificación de producto también aplican un límite de 7.200 consultas por hora. Este es un límite único para las suscripciones y los productos únicos y en todas las solicitudes de modificación, incluidas las de creación, actualización, activación, borrar. Las llamadas a métodos de modificación por lotes cuentan como una consulta para esta cuota, sin importar la cantidad de solicitudes individuales incluidas o su latencia. sensibilidad.
3. Las modificaciones sensibles a la latencia también tienen un límite de 7,200. por hora. Para los métodos por lotes, cada solicitud de modificación anidada cuenta por separado a efectos de esta cuota. Esta cuota tiene requisitos prácticos implicaciones solo para los usuarios de APIs por lotes que realizan tareas sensibles a la latencia actualizaciones, como en otros casos, la cuota 2 se agotará antes o al mismo tiempo tiempo que esta cuota.

Aquí hay 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 no se permiten tokens de cuota 2 y 3 (ya que se refieren únicamente a los extremos de modificación).
• Una solicitud get por lotes para recuperar hasta 100 artículos también consumirá 1 token de la cuota 1 y ningún token de la cuota 2 ni 3.
• Una sola solicitud modification para un artículo consumirá 1 token de la cuota 1 , 1 token de cuota 2. Si la solicitud es sensible a la latencia, también consumir 1 token de la cuota 3. Como la cuota C tiene el mismo límite que la cuota 2, no tiene consecuencias prácticas para los usuarios que usan una sola modificación .
• Una solicitud modification por lotes de 100 elementos tolerantes a la latencia consumirá 1 token de la cuota 1, 1 token de la cuota 2. Esta configuración de cuota debería permitir una amplia para mantener tu catálogo actualizado, pero si tu algoritmo no está al tanto esta cuota y va más allá de esta tasa. Es posible que recibas un error por cada llamada adicional.
• Una solicitud modification por lotes de 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, optimizas tus interacciones con la API, lo que garantiza una experiencia de administración de catálogos sin problemas.

Supervisa el uso

Debes tener en cuenta los procesos de uso intensivo. Por ejemplo, al principio de tu integración. Es más probable que los extremos de administración de catálogos consuman más cuota para crear tu catálogo inicial completo, lo que podría afectar de producción de otros endpoints, como la API de estado de compra, si se cerca del límite de uso general. Debes supervisar el consumo de la cuota para asegurarte de que no superando las cuotas de las APIs. Hay varias formas de supervisar el uso. Por ejemplo: puedes usar el panel de cuotas de las APIs de Google Cloud o cualquier otro de supervisión de APIs de terceros que elijas.

Optimiza el uso de la cuota de la API

Optimizar el consumo de frecuencia es muy recomendable para minimizar la probabilidad de Errores de API. Para implementar esto de manera eficaz, te recomendamos lo siguiente:

• Elige la estrategia de administración de catálogos adecuada. Una vez que entiendas la API de almacenamiento, debes elegir la estrategia adecuada para que tu aplicación logre tus objetivos de administración de catálogos de manera eficiente.
• Solo realice la cantidad mínima de llamadas que necesite para reflejar los cambios.
• No envíes llamadas de modificación redundantes o innecesarias a las APIs. Esta puede requerir que mantengas un registro de cambios en tu catálogo de backend.
• No superes el límite por hora de modificación de productos de 7,200 consultas. Puedes y desean crear procesos de sincronización que requieran realizar grandes cantidades de modificaciones en un período breve (por ejemplo, un catálogo inicial creación). Si esperas que estos procesos superen el límite por hora implementar esperas según sea necesario para ralentizar el uso a un nivel seguro. Considera usar métodos por lotes con actualizaciones tolerantes a la latencia para lograr una mayor capacidad de procesamiento.
• Prepárate de forma proactiva para escalar. A medida que tu aplicación crezca, quizás debas o escalar verticalmente el uso de la API y los diversos extremos. Lee el Documentación sobre las cuotas de la API de Play Developer puedes aumentar la cuota cuando estés cerca de alcanzar el máximo uso.
• Programa procesos pesados estratégicamente. Trata de programar tu gran catálogo procesos en torno a los picos de uso críticos, por ejemplo, puedes evitar ejecutar un la sincronización completa del catálogo durante los momentos de mayor cantidad de ventas de la semana.

Agrega lógica de manejo de errores de cuota

No importa qué tan eficientemente compiles tu lógica de administración de catálogos, debes serán resistentes a límites de cuota inesperados, ya que la cuota diaria compartidas por los extremos que se usan en módulos independientes de tu integración. Asegúrate de que incluirás errores de limitación de cuota en tu manejo de errores e implementarás la las esperas adecuadas. Cada llamada realizada a las APIs de Google Play Developer generará una respuesta. En la de fallo en una llamada, recibirás una respuesta de error que incluye una 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 se produzca un error similar a lo 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 de catálogos

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

• Podrás consultar la lista completa de ofertas disponibles y administrar etiquetas de oferta y plan básico para influir en tu propia elegibilidad y mostrar las ofertas lógica.
• Puedes consultar los diferentes precios y detalles del producto que los usuarios en todas las plataformas y asegúrate de que sean coherentes.
• Tendrás los detalles del producto a mano en tu backend cuando proceses datos nuevos. sin la necesidad de aumentar la latencia ni el riesgo de falla, ya que llamadas adicionales a la API de Google Play Developer durante los flujos críticos para el 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 sabes cómo quieres estructurar tu catálogo, es momento decidir tu estrategia de sincronización.

Estrategias de sincronización de catálogos

Los extremos de publicación de la API de Google Play Developer te permiten actualizar tu catálogo a medida que ocurren cambios. En ocasiones, es posible que debas realizar una revisión periódica de actualizaciones, en el que envías una batería de cambios en el mismo proceso. Cada requiere diferentes opciones de diseño. Cada estrategia de sincronización se adaptan mejor a algunos casos de uso que otros, y es posible que tengas un conjunto de necesidades que a ambos, según la situación. A veces, puede que quieras hacer de un producto en el momento en que eres consciente de un cambio nuevo, por ejemplo, a procesar una actualización urgente del producto (p.ej., un precio incorrecto debe corregirse como lo antes posible). Otras veces, puedes usar una sincronización periódica en segundo plano para garantizar tu backend y tus catálogos de Play sean siempre coherentes. Lee algunos de los usos comunes casos en los que se recomienda implementar estos diferentes tipos de administración estrategias.

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

Idealmente, las actualizaciones deberían realizarse en cuanto haya algún cambio en la configuración en el catálogo de productos para minimizar las discrepancias.

Este tipo de actualizaciones es una buena opción en las siguientes situaciones:

• 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 en venta.

Este enfoque es más sencillo de implementar y te permite mantener tu catálogo sincronizado. con la ventana de cantidad mínima de discrepancia.

Cuándo usar 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 cuando:

• No es necesario que te asegures de que tus productos se actualicen con un breve aviso.
• Debes planificar actualizaciones masivas o procesos de conciliación.
• Ya tienes un sistema de administración de contenido o catálogos para gestionar tus productos digitales, y que actualiza tu catálogo constantemente

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

Crea tu catálogo de productos

Si tienes un catálogo extenso para subir a Google Play, se recomienda automatizar la carga inicial. Este tipo de proceso pesado funciona mejor si se usa una estrategia periódica y se combinan con métodos por lotes tolerantes a la latencia.

Cómo crear productos únicos

Para la creación inicial de un gran catálogo de productos únicos, recomendamos usar Método inappproducts.batchUpdate con el campo allowMissing configurado como true y el campo latencyTolerance establecidos en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT Esto minimizará el tiempo que lleva crear el catálogo dentro de los límites de cuota.

Para catálogos más pequeños, puedes usar el método inapp_products.insert. También puedes usar el método inappproducts.update con la allowMissing, como se describe en la sección Actualizaciones de productos. Este enfoque tiene el beneficio de eliminar la necesidad con estado y que se pueda reiniciar desde cero en caso de que algo salga mal.

Crea productos de suscripción

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

Para catálogos de suscripción más pequeños, la API de Play Developer proporciona la monetization.subscriptions.create. También puedes crear suscripciones con monetization.subscriptions.update con el elemento allowMissing, como se describe en la sección Actualizaciones de productos.

Todos los métodos anteriores crean suscripciones junto con sus planes básicos (proporcionadas en el objeto de suscripción). Inicialmente, estos planes básicos inactivo. Para administrar planes básicos actual, puedes usar el monetization.subscriptions.basePlans, incluida la activación de un para que esté disponible para la compra. Además, el extremo monetization.subscriptions.basePlans.offers te permite crear y administrar ofertas.

Actualizaciones de productos

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

Cómo actualizar productos únicos

Hay tres métodos disponibles para ayudarte a actualizar los productos únicos existentes.

• inappproducts.patch : El extremo de parche se usa para actualizar un recurso de forma parcial. Esto significa que puede actualizar los campos específicos que especifiques en el cuerpo de la solicitud. El parche extremo se usa cuando solo necesitas actualizar algunos campos de una recurso.
• inappproducts.update : El extremo de actualización se usa para actualizar un recurso en su totalidad. Esto significa que deberás enviar todo el objeto del recurso en el cuerpo de la solicitud. El update endpoint se usa generalmente cuando necesitas actualizar todos los campos en un recurso. Cuando el parámetro allowMissing se establece en true y se proporciona el ID del producto aún no existe, el extremo insertará el producto en lugar de fallar.
• inappproducts.batchUpdate : Esta es una versión por lotes del extremo de actualización, que te permite modificar varios productos con una sola búsqueda. Úsala junto con el Se estableció el campo latencyTolerance en PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT para lograr una mayor capacidad de procesamiento.

Actualiza los productos de suscripción

Para actualizar suscripciones existentes, puedes usar la 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 único del producto de la suscripción.
• regionsVersion: Es la versión de configuración de la región.

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

Por ejemplo, si solo quieres 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. Úsala junto con el campo latencyTolerance configurado como PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT para obtener de procesamiento.

Para activar, desactivar o borrar planes básicos, o migrar suscriptores a la Las versiones más recientes de precios del plan básico usan el extremo monetization.subscriptions.basePlans.

Además, puedes actualizar las contraseñas de los planes básicos ofrece el monetization.subscriptions.basePlans.offers.patch .

Conciliación de catálogos

Si eliges actualizar tu catálogo de Google Play cada vez que cambios en el catálogo o de manera periódica, si tienes un sistema de administración de catálogos o un fuera del catálogo de Google Play, podría haber situaciones no se sincroniza 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, a una interrupción en tu sistema de administración de catálogos o si perdiste los datos más recientes.

Puedes crear un proceso de conciliación del catálogo para evitar una discrepancia prolongada en la ventana modal.

Consideración del sistema de diferencias

Recomendamos crear un sistema de diferencias para detectar incoherencias y conciliar el entre dos sistemas. Aquí hay algunos aspectos que debes considerar cuando crees un sistema de diferencias para ayudar a mantener catálogos sincronizados:

• Comprende los modelos de datos: El primer paso es comprender los datos. del CMS para desarrolladores y la API de Google Play Developer. Esto incluye los diferentes tipos de datos que se almacenan en cada sistema y cómo los diferentes elementos de datos se asignan entre sí.
• Define las reglas de diferencia: Una vez que comprendas los modelos de datos, deberás hacer lo siguiente: definir las reglas de diferencias. Estas reglas determinarán cómo los datos se comparan los diferentes sistemas. Por ejemplo, quizás quieras hacer coincidir los IDs de los productos y comparar los atributos clave de la suscripción y sus planes básicos asociados, y para todas las plataformas de Google.
• Implementar un algoritmo de diferencia: Una vez que hayas definido las reglas de diferencias, necesitas implementar el algoritmo de diferencia. Este algoritmo tomará los datos de entre los dos sistemas y compararlos según las reglas que definiste. Para obtener de los datos del catálogo de Google Play, puedes usar el inappproducts.list: inappproducts.batchGet, monetization.subscriptions.list y monetization.subscriptions.batchGet.
• Genera informes de diferencias: El algoritmo de diferencias generará un informe de diferencias. En este informe, se mostrarán las diferencias entre ambos sistemas.
• Conciliar diferencias: Una vez que hayas generado el informe de diferencias, necesitas para resolver las diferencias. Esto puede implicar actualizar los datos en tu CMS es posible que implique actualizar los datos en Google Play con la API para desarrolladores de administración de catálogos, según cómo sueles actualizar en tu catálogo de productos. Para conciliar productos no sincronizados, utiliza los extremos de actualización como se describe en la sección Actualizaciones de productos.

Baja del producto

La API de Google Play Developer ofrece varios métodos para ayudar a los desarrolladores a dar de baja sus productos: inappproducts.delete y inappproducts.batchDelete para productos únicos y monetization.subscriptions.delete para suscripciones. Puede ser necesario dar de baja un producto en diversos casos. , por ejemplo:

• Se creó por error.
• Descontinuación de una función o un servicio

Recomendamos incorporar la baja de productos en la administración de catálogos de administración de amenazas.

Baja de productos únicos

Para borrar productos únicos con la API de Google Play Developer, debes usar el inappproducts.delete o inappproducts.batchDelete .

Baja de productos de suscripción

Puedes borrar suscripciones con el monetization.subscriptions.delete . No se puede quitar una suscripción una vez que se posee al menos un plan básico activado.