Gerenciar seu catálogo de produtos

Este guia explica como usar a API Google Play Developer para criar e gerenciar um catálogo de produtos para seu app do Google Play.

Para vender produtos no app usando o sistema de faturamento do Google Play, você precisa do seguinte: para configurar um catálogo com todos os produtos que serão disponibilizados compra pelos usuários. Isso pode ser feito pelo Play Console ou você pode automatizar o gerenciamento do catálogo usando a API Google Play Developer. A automação pode ajudam a garantir que seu catálogo esteja sempre atualizado e escalone para catálogos grandes em que coordenação manual é impraticável. Neste guia, você vai aprender a usar a API Play Developer para criar e gerenciar um catálogo de produtos para seu app do Google Play. Consulte nosso guia Como se preparar para ver instruções sobre como configurar a API Google Play Developer para sua integração de back-end.

APIs de gerenciamento de catálogo

Para ler sobre os diferentes tipos de produto que você pode vender com a sistema de faturamento, ler Entenda os tipos de produtos no app e as considerações de catálogo. O Google oferece dois conjuntos principais de APIs para o gerenciamento de catálogos no Google Play: correspondentes às duas principais categorias de produtos:

  • Produtos de aquisição única
  • Produtos por assinatura

Produtos de aquisição única

O endpoint inappproducts permite gerenciar uma vez produtos do seu back-end. Isso inclui criar, atualizar e excluir produtos e gerenciar preços e disponibilidade. Dependendo de como você lida com compras de produtos únicos, você vai modelar produtos de consumo (podem ser comprados quantas vezes quiser) ou permanentes direitos (não pode ser feito duas vezes pelo mesmo usuário). Você pode decidir qual produtos de aquisição única devem ser consumíveis ou não.

Produtos por assinatura

O endpoint monetization.subscriptions ajuda você a gerenciar a assinatura produtos do back-end do desenvolvedor. Você pode realizar tarefas como criar, atualizar excluir assinaturas ou controlar a disponibilidade e os preços regionais. Além do endpoint monetization.subscriptions, também fornecemos monetization.subscriptions.basePlans e monetization.subscriptions.basePlans.offers para gerenciar, respectivamente, assinaturas planos básicos e ofertas.

Métodos em lote

inappproducts e monetization.subscriptions endpoints fornecem vários métodos em lote que permitem recuperar ou gerenciar a 100 entidades no mesmo app ao mesmo tempo.

Métodos em lote, quando usados com tolerância de latência ativada, oferecem suporte a e são especialmente úteis para desenvolvedores de grandes catálogos criação ou reconciliação de catálogos.

Atualize a latência de propagação em comparação com a capacidade de processamento

Depois que uma solicitação de criação ou modificação de produto for concluída, as alterações não poderão ser visível imediatamente para os usuários finais nos dispositivos devido à rede ou ao back-end. atrasos no processamento. Por padrão, todas as solicitações de modificação de produtos são sensíveis à latência. Isso significa que eles são otimizados para propagação rápida por meio de sistemas de back-end, normalmente nos dispositivos dos usuários finais em questão de minutos. No entanto, há um limite por hora e o número dessas solicitações de modificação. Nos casos em que é preciso criar ou atualizar muitos produtos (por exemplo, durante criação inicial de um catálogo grande), é possível usar métodos em lote com as Campo latencyTolerance definido como PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Isso vai aumentar significativamente a capacidade de processamento das atualizações. Atualizações tolerantes à latência levará até 24 horas para ser propagado para os dispositivos dos usuários finais.

Configuração de cota

Há vários limites de cota que você precisa conhecer ao usar o Google Play Developer. API para gerenciar seu catálogo de produtos:

  1. As APIs Google Play Developer têm um limite padrão de 200.000 consultas por dia. Esse limite de cota se aplica à agregação de uso em todos os endpoints, incluindo APIs de gerenciamento de catálogo.
  2. Os endpoints de modificação do produto também impõem um limite de 7.200 consultas por por hora. Esse é um limite único para produtos únicos e assinaturas e em todas as solicitações de modificação, incluindo criação, atualização, ativação, excluir. Chamadas de métodos de modificação em lote contam como uma consulta para esta cota, independentemente do número de solicitações individuais incluídas ou da latência sensibilidade.
  3. Modificações sensíveis à latência também têm um limite de 7.200 modificações por hora. Para métodos em lote, cada solicitação de modificação aninhada conta separadamente para essa cota. Essa cota tem recursos implicações apenas para os usuários de APIs em lote que executam dados sensíveis à latência atualizações, já que em outros casos a cota 2 será esgotada antes ou ao mesmo tempo vez que essa cota.

Confira alguns exemplos ilustrativos para entender o uso da cota de solicitações diferentes:

  • Uma única solicitação get para buscar um item consumirá um token da cota 1 e nenhum token das cotas 2 e 3 (porque dizem respeito apenas a pontos de extremidade de modificação).
  • Uma solicitação get em lote para buscar até 100 itens também vai consumir 1 token de cota 1 e nenhum token das cotas 2 e 3.
  • Uma única solicitação modification para um item vai consumir 1 token da cota 1 , 1 token da cota 2. Se a solicitação for sensível à latência, ela também consome 1 token da cota 3. Como a cota C tem o mesmo limite que a cota 2, ela não tem implicações práticas para usuários que usam apenas uma modificação métodos.
  • Uma solicitação modification em lote para 100 itens tolerantes à latência vai consumir 1 token da cota 1, um token da cota 2. Essa configuração de cota deve permitir amplos para manter o catálogo atualizado, mas se o algoritmo não souber essa cota e exceder essa taxa, você poderá receber um erro a cada chamada adicional.
  • Uma solicitação modification em lote com 100 itens sensíveis à latência vai consumir 1 token da cota 1, 1 token da cota 2 e 100 tokens da cota 3.

Recomendações de uso da API Catalog Management

Ao seguir essas diretrizes, você otimiza suas interações com a API, garantindo uma experiência tranquila e eficiente de gerenciamento de catálogo.

Monitore seu uso

Você deve estar ciente dos processos de uso intenso. Por exemplo, no início Sua integração é mais provável que os endpoints de gerenciamento do catálogo consumam mais cota para criar seu catálogo inicial completo e isso pode afetar uso de produção de outros pontos de extremidade, como a API de status de compra, se estiver perto do limite de uso geral. Você precisa monitorar seu consumo de cota para ter certeza de que não está excedendo as cotas da API. Há várias maneiras de monitorar o uso. Por exemplo: use o painel de cotas das APIs do Google Cloud ou qualquer outro de terceiros de sua escolha.

Otimizar o uso da cota da API

É altamente recomendável otimizar o consumo de taxas para minimizar a probabilidade de Erros de API. Para implementar isso de forma eficaz, recomendamos que você:

  • Escolher a estratégia certa de gerenciamento de catálogo. Depois de entender a API a cota, você precisa escolher a estratégia certa para o aplicativo alcançar suas metas de gerenciamento de catálogo com eficiência.
  • Faça apenas a quantidade mínima de chamadas necessária para refletir suas alterações.
  • Não envie chamadas de modificação redundantes ou desnecessárias às APIs. Isso pode exigir que você mantenha um log de mudanças no catálogo de back-end.
  • Mantenha-se abaixo do limite por hora de modificação do produto de 7.200 consultas. Você pode e querem criar processos de sincronização que exijam a criação de um grande número de modificações em um curto período de tempo (por exemplo, um catálogo inicial criação). Se você espera que esses processos excedam o limite de horas, implementar espera conforme necessário para reduzir a velocidade do uso a um nível seguro. Considere usar em lote com atualizações tolerantes à latência para alcançar uma capacidade maior.
  • Preparar-se de modo proativo para escalonar. Conforme seu aplicativo cresce, pode ser necessário ampliar o uso da API e dos vários endpoints. Leia o documentação de cotas da API Play Developer para detalhes sobre como aumente sua cota quando estiver perto do uso máximo.
  • Programe processos pesados de maneira estratégica. Tente programar seu catálogo pesado processos em torno de picos de uso críticos, por exemplo, é possível evitar a execução de um sincronização completa do catálogo durante os horários de pico de vendas da semana.

Adicionar lógica de tratamento de erros de cota

Não importa a eficiência com que você cria sua lógica de gerenciamento de catálogo, torná-la resiliente a limites de cota inesperados, uma vez que a cota diária é compartilhados por endpoints usados em módulos independentes da sua integração. Confirme se inclua erros de limitação de cota no tratamento de erros e implemente as esperas mais adequadas. Cada chamada feita para as APIs Google Play Developer vai gerar uma resposta. Na caso de falha na chamada, você receberá uma resposta de falha que inclui uma Código de status de resposta HTTP e um objeto errors, fornecendo mais detalhes sobre o domínio de erro e uma mensagem de depuração. Por exemplo, se você ultrapassar seu limite diário, poderá receber uma mensagem de erro semelhante a:

{
  "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"
  } ],
}

Implementação do gerenciamento do catálogo

Os desenvolvedores usam os endpoints de publicação de produtos da API Google Play Developer para manter o catálogo sincronizado entre o back-end e o Google Play. Fazer garantir que o catálogo do Google Play esteja sempre atualizado com o catálogo do back-end; informações mais recentes tem vantagens para criar uma melhor experiência do usuário. Exemplo:

  • Você poderá consultar a lista completa de ofertas disponíveis e gerenciar tags de oferta e de plano básico para influenciar sua qualificação e exibição de ofertas lógica.
  • Você pode verificar as diferentes faixas de preços e detalhes do produto que os usuários estão ver em todas as plataformas e garantir que sejam consistentes.
  • Você terá os detalhes do produto disponíveis no back-end ao processar novos sem precisar aumentar a latência e o risco de falha ao realizar chamadas adicionais para a API Google Play Developer durante fluxos críticos do usuário.

Há certos limites e considerações que você precisa ter em mente. em mente ao criar seu catálogo de produtos no Google Play. Depois de entender esses limites e sabe como quer estruturar seu catálogo, é hora de a decidir sobre sua estratégia de sincronização.

Estratégias de sincronização do catálogo

Os endpoints de publicação da API Google Play Developer permitem fazer atualizações no seu catálogo conforme as alterações ocorrem. De vez em quando, você pode precisar fazer um de atualização, em que você envia uma bateria de mudanças no mesmo processo. Cada abordagem requer diferentes escolhas de design. Cada estratégia de sincronização se adequam melhor a alguns casos de uso do que outros, e você pode ter um conjunto de necessidades que chama os dois, dependendo da situação. Às vezes, você pode querer fazer uma atualizar um produto assim que souber de uma nova mudança, por exemplo, processar uma atualização urgente de produto (ou seja, um preço errado precisa ser corrigido porque assim que possível). Outras vezes, é possível usar uma sincronização periódica em segundo plano para garantir seus catálogos de back-end e do Google Play sejam sempre consistentes. Leia alguns dados de uso comum casos em que convém implementar essas diferentes soluções de gerenciamento estratégias.

Quando enviar atualizações conforme o catálogo local muda

O ideal é que as atualizações aconteçam assim que houver qualquer mudança no back-end ou do catálogo de produtos, para reduzir as discrepâncias.

Esse tipo de atualização é uma boa opção quando:

  • Seus produtos precisam estar sempre atualizados.
  • Você precisa fazer algumas mudanças nos produtos todos os dias.
  • Você precisa atualizar os produtos que já estão em produção e sendo vendidos.

Essa abordagem é mais simples de implementar e permite manter seu catálogo sincronizado com a janela de menor discrepância.

Quando usar atualizações periódicas

As atualizações periódicas são executadas de maneira assíncrona na edição do produto no back-end. e são uma boa opção quando:

  • Você não precisa garantir que seus produtos sejam atualizados em pouco tempo.
  • Você precisa planejar atualizações em massa ou processos de conciliação.
  • Você já tem um Sistema de gerenciamento de conteúdo ou de catálogo para lidar com seus produtos digitais, e isso atualiza seu catálogo constantemente

No caso de catálogos grandes, considere o uso de métodos em lote com tolerância à latência e atualizações para atingir a capacidade máxima.

Criar seu catálogo de produtos

Se você tiver um catálogo grande para fazer upload no Google Play, automatize carga inicial. Esse tipo de processo pesado funciona melhor se uma estratégia periódica combinado com métodos de lote tolerantes à latência é seguido.

Criar produtos de aquisição única

Para a criação inicial de um grande catálogo de produtos únicos, recomendamos usar o Método inappproducts.batchUpdate com o campo allowMissing definido como true e o campo latencyTolerance definido como PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Isso minimizará o tempo necessário para criar o catálogo dentro dos limites da cota.

Para catálogos menores, use o método inapp_products.insert. Como alternativa, você pode usar o método inappproducts.update com o allowMissing, conforme descrito na seção "Atualizações de produtos". Com essa abordagem, você não precisa mais que seu script com estado e pode ser reiniciado do zero caso algo dê errado.

Criar produtos por assinatura

Para criar um catálogo grande de assinatura inicial, recomendamos o uso do Método monetization.subscriptions.batchUpdate com o campo allowMissing definido como true e o campo latencyTolerance definido para PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Isso minimizará o tempo necessário para criar o catálogo dentro dos limites da cota.

Para catálogos de assinaturas menores, a API Play Developer oferece as método monetization.subscriptions.create. Você também pode criar assinaturas usando método monetization.subscriptions.update com o allowMissing, conforme descrito na seção "Atualizações de produtos".

Todos os métodos anteriores criam assinaturas com os planos básicos. (fornecido no objeto Subscription). Inicialmente, esses planos básicos são inativo. Para gerenciar planos básicos você pode usar o endpoint do monetization.subscriptions.basePlans, incluindo a ativação de um plano básico para disponibilizá-lo para compra. Além disso, o endpoint monetization.subscriptions.basePlans.offers permite criar e gerenciar ofertas.

Atualizações do produto

Os métodos a seguir permitem modificar com eficiência os produtos atuais, garantindo que suas ofertas estejam alinhadas aos ajustes mais recentes.

Atualizar produtos únicos

Há três métodos disponíveis para ajudar a atualizar os produtos únicos.

  • inappproducts.patch : O endpoint do patch é usado para atualizar um recurso parcialmente. Isso significa que você pode atualizar campos específicos especificados no corpo da solicitação. O patch endpoint é normalmente usado quando você só precisa atualizar alguns campos de um recurso.
  • inappproducts.update : O endpoint de atualização é usado para atualizar um recurso inteiro. Isso significa que você precisará enviar todo o objeto de recurso no corpo da solicitação. A endpoint de atualização é normalmente usado quando você precisa atualizar todos os campos em uma recurso. Quando o parâmetro allowMissing é definido como true e o o ID do produto ainda não existir, o endpoint inserirá o produto em vez de falhar.
  • inappproducts.batchUpdate : Esta é uma versão em lote do endpoint de atualização, que permite modificar vários produtos com uma única consulta. Use-o com o O campo latencyTolerance foi definido como PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT para alcançar uma capacidade de processamento maior.

Atualizar produtos por assinatura

Para atualizar as assinaturas atuais, use o método monetization.subscriptions.patch. Esse método usa os seguintes parâmetros obrigatórios:

A menos que você esteja criando uma nova assinatura com o parâmetro allowMissing , você precisa fornecer o parâmetro updateMask. Esse parâmetro é um lista separada por vírgulas dos campos que você quer atualizar.

Por exemplo, se você só quiser atualizar a listagem de um produto por assinatura, especifique o campo listings ao parâmetro updateMask.

Você pode usar o monetization.subscriptions.batchUpdate para atualizar várias assinaturas ao mesmo tempo. Use com o campo latencyTolerance definido como PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT para conseguir e aumentar a capacidade de processamento.

Para ativar, desativar, excluir planos básicos ou migrar assinantes para o As versões mais recentes de preço do plano básico usam o endpoint monetization.subscriptions.basePlans.

Além disso, é possível atualizar com o monetization.subscriptions.basePlans.offers.patch .

Reconciliação de catálogo

Se você optar por atualizar seu catálogo do Google Play sempre que o back-end no catálogo ou periodicamente, se você tiver um sistema de gerenciamento de catálogo ou um fora do catálogo do Google Play, pode haver situações em que ele não esteja sincronizado com o catálogo na configuração dos seus apps no Google Play. Isso pode ocorrer devido a alterações manuais emergenciais no catálogo no console, uma interrupção do serviço no sistema de gerenciamento de catálogo ou se você perdeu os dados mais recentes.

É possível criar um processo de reconciliação de catálogo para evitar discrepâncias prolongadas janela.

Consideração do sistema diferente

Recomendamos a criação de um sistema de diferenças para detectar inconsistências e ajustar os dois sistemas. Aqui estão algumas coisas que você deve considerar ao criar um sistema de diferenças para ajudar a manter os catálogos sincronizados:

  • Entender os modelos de dados:a primeira etapa é entender os dados. modelos do CMS do desenvolvedor e da API Google Play Developer. Isso inclui conhecer os diferentes tipos de dados armazenados em cada sistema e como os diferentes elementos de dados são mapeados entre si.
  • Defina as regras de diferença:depois de entender os modelos de dados, você precisa e definir as regras de diferença. Essas regras determinarão como os dados nos dois e os sistemas são comparados. Por exemplo, talvez você queira corresponder IDs do produto e comparar os principais atributos da assinatura e dos planos básicos associados a ela de produtos Google.
  • Implemente um algoritmo de diferenças:depois de definir as regras, você pode precisa implementar o algoritmo de diferença. Esse algoritmo extrai os dados os dois sistemas e compará-los de acordo com as regras que você definiu. Para receber os dados de catálogo do Google Play, é possível usar o inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list e monetization.subscriptions.batchGet.
  • Gerar relatórios de diferenças:o algoritmo de diferenças gera um relatório de diferenças. Esse relatório mostra as diferenças entre os dois sistemas.
  • Reconciliar diferenças: depois de gerar o relatório de diferenças, você precisará para resolver as diferenças. Isso pode envolver a atualização dos dados em seu CMS ou isso pode envolver a atualização dos dados pelo Google Play usando a API Developer endpoints de gerenciamento de catálogo, dependendo de como você normalmente atualiza no seu catálogo. Para reconciliar produtos fora de sincronia, use os endpoints de atualização conforme descrito em na seção "Atualizações do produto".

Descontinuação do produto

A API Google Play Developer oferece vários métodos para ajudar os desenvolvedores a: descontinuar seus produtos: inappproducts.delete e inappproducts.batchDelete para produtos únicos e monetization.subscriptions.delete para assinaturas. A descontinuação de um produto pode ser necessária em vários cenários como:

  • Criação por engano.
  • Descontinuação de um recurso ou serviço.

Recomendamos incorporar a descontinuação do produto ao gerenciamento do seu catálogo estratégia.

Descontinuar produtos únicos

Para excluir produtos únicos com a API Google Play Developer, é necessário usar as inappproducts.delete ou inappproducts.batchDelete .

Suspender produtos por assinatura

Você pode excluir assinaturas usando o monetization.subscriptions.delete . Não é possível remover uma assinatura depois que pelo menos um plano básico é usado ativado.