Gérer votre catalogue de produits

Ce guide explique comment utiliser l'API Google Play Developer pour créer et gérer un catalogue de produits pour votre application Play.

Pour vendre des produits dans votre application via le système de facturation de Google Play, vous avez besoin des éléments suivants : pour créer un catalogue contenant tous les produits pour lesquels vous voulez le rendre disponible des achats effectués par vos utilisateurs. Pour cela, vous pouvez utiliser la Play Console ou d'automatiser la gestion du catalogue à l'aide de l'API Google Play Developer. L'automatisation peut vous pouvez vous assurer que votre catalogue est toujours à jour et s'adapter aux vastes catalogues où la coordination manuelle est peu pratique. Dans ce guide, vous allez apprendre à utiliser l'API Play Developer afin de créer et de gérer un catalogue de produits pour votre application Play. Consultez notre guide Préparation pour savoir comment configurer l'API Google Play Developer pour l'intégration du backend.

API de gestion du catalogue

Pour en savoir plus sur les différents types de produits que vous pouvez vendre avec le programme système de facturation, lire Découvrez les types de produits intégrés et les considérations concernant le catalogue. Google propose deux ensembles principaux d'API pour la gestion des catalogues sur Play : correspondant aux deux principales catégories de produits:

  • Produits ponctuels
  • Produits sur abonnement

Produits ponctuels

Le point de terminaison inappproducts vous permet de gérer depuis votre backend. Cela inclut la création, la mise à jour et la suppression des produits, et gérer les prix et la disponibilité. Selon la façon dont vous gérez les achats de produits ponctuels, produits consommables (possibilité d'acheter autant de fois que vous le souhaitez) ou permanentes droits d'accès (un même utilisateur ne peut pas en créer deux fois) Vous pouvez décider les produits ponctuels doivent être consommables ou non.

Produits sur abonnement

Le point de terminaison monetization.subscriptions vous aide à gérer les abonnements depuis votre backend de développeur. Vous pouvez par exemple créer, mettre à jour, et supprimer des abonnements, ou contrôler leur disponibilité et leur tarification selon la région. En plus du point de terminaison monetization.subscriptions, nous fournissons monetization.subscriptions.basePlans et monetization.subscriptions.basePlans.offers pour gérer respectivement abonnements des offres et des forfaits de base.

Méthodes par lot

inappproducts et monetization.subscriptions les points de terminaison fournissent un certain nombre de méthodes par lot qui permettent à 100 entités sous la même application en même temps.

Lorsqu'elles sont utilisées avec une tolérance à la latence activée, les méthodes par lot acceptent et sont particulièrement utiles pour les développeurs de catalogues volumineux la création de catalogues ou le rapprochement.

Mettre à jour la latence de propagation par rapport au débit

Une fois qu'une demande de création ou de modification de produit a été traitée, il est possible que les modifications est immédiatement visible par les utilisateurs finaux sur leurs appareils en raison du réseau ou du backend. les retards de traitement. Par défaut, toutes les demandes de modification de produit sont sensibles à la latence. Cela signifie Ils sont optimisés pour une propagation rapide via des systèmes backend, généralement sur les appareils des utilisateurs finaux en quelques minutes. Toutefois, il existe une limite horaire sur le nombre de demandes de modification de ce type. Lorsque vous devez créer ou mettre à jour de nombreux produits (par exemple, la création initiale d'un grand catalogue), vous pouvez utiliser des méthodes de traitement par lot avec latencyTolerancechamp défini sur PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT Cela augmentera considérablement le débit des mises à jour. Mises à jour tolérantes à la latence peut prendre jusqu'à 24 heures pour se répercuter sur les appareils des utilisateurs finaux.

Configuration des quotas

Vous devez prendre en compte plusieurs limites de quota lorsque vous utilisez Play Developer. API pour gérer votre catalogue de produits:

  1. Les API Google Play Developer sont limitées à 200 000 requêtes par défaut jour. Cette limite de quota s'applique à l'agrégation de l'utilisation sur tous les points de terminaison, y compris des API de gestion des catalogues.
  2. Les points de terminaison de modification de produits appliquent également une limite de 7 200 requêtes par heure. Il s'agit d'une limite unique pour les produits ponctuels et les abonnements. et pour toutes les demandes de modification, y compris la création, la mise à jour, l'activation, supprimer. Les appels de méthode de modification par lot comptent comme une requête pour ce quota. quel que soit le nombre de requêtes individuelles incluses ou leur latence la sensibilité.
  3. Les modifications sensibles à la latence sont également limitées à 7 200 modifications par heure. Pour les méthodes par lot, chaque requête de modification imbriquée compte séparément pour les besoins de ce quota. Ce quota présente des avantages uniquement pour les utilisateurs de l'API par lot sensible à la latence car dans d'autres cas, le quota 2 sera épuisé avant ou pendant que ce quota.

Voici plusieurs exemples illustrant l'utilisation du quota différentes demandes:

  • Une seule requête get d'extraction d'un élément consommera un jeton du quota 1 et aucun jeton des quotas 2 et 3 (car ils ne concernent que les points de terminaison de modification).
  • Une requête get par lot visant à récupérer jusqu'à 100 éléments consommera également 1 jeton de quota 1, et aucun jeton des quotas 2 et 3.
  • Une seule requête modification pour 1 élément consommera un jeton du quota 1. , 1 jeton du quota 2. Si la requête est sensible à la latence, utilisent 1 jeton du quota 3. Comme le quota C a la même limite que le quota 2, n'a aucune incidence pratique pour les utilisateurs n'utilisant qu'une seule modification. méthodes.
  • Une requête modification par lot pour 100 éléments tolérants à la latence consommera un élément jeton du quota 1, un jeton du quota 2. Cette configuration de quota devrait permettre pour maintenir votre catalogue à jour, mais si votre algorithme ne prend pas en compte ce quota et que vous dépassez ce débit, vous risquez d'obtenir une erreur pour chaque appel supplémentaire.
  • Une requête modification par lot pour 100 éléments sensibles à la latence consommera Un jeton pour le quota 1, un jeton pour le quota 2 et 100 jetons pour le quota 3.

Recommandations d'utilisation de l'API Catalog Management

En respectant ces consignes, vous optimisez vos interactions avec l'API, pour garantir une expérience de gestion des catalogues fluide et efficace.

Surveiller votre utilisation

Vous devez être conscient des processus d'utilisation intensive. Par exemple, au début de votre intégration que vos points de terminaison de gestion des catalogues sont plus susceptibles d'utiliser pour créer votre catalogue initial complet. Cela peut avoir un impact l'utilisation en production d'autres points de terminaison, tels que l'API purchase status, vous approchez de la limite d'utilisation globale. Vous devez surveiller votre consommation de quotas pour vous assurer au-delà des quotas de l'API. Il existe plusieurs façons de surveiller l'utilisation. Par exemple : vous pouvez utiliser le tableau de bord des quotas des API Google Cloud ou tout autre outil de surveillance des API tiers de votre choix.

Optimiser l'utilisation des quotas d'API

Il est fortement recommandé d'optimiser la consommation Erreurs d'API. Pour une mise en œuvre efficace, nous vous recommandons de suivre ces recommandations:

  • Choisissez la bonne stratégie de gestion des catalogues. Une fois que vous avez compris l'API vous devez choisir la stratégie adaptée vos objectifs de gestion des catalogues de manière efficace.
  • Ne passez que le nombre d'appels minimal dont vous avez besoin pour refléter vos modifications.
  • N'envoyez pas d'appels de modification redondants ou inutiles aux API. Ce peut vous obliger à conserver un journal de modifications dans votre catalogue backend.
  • Respectez la limite horaire de modification de produit de 7 200 requêtes. Vous pouvez vous souhaitez créer des processus de synchronisation qui vous obligent à créer un grand nombre des modifications sur une courte période (par exemple, un catalogue initial création). Si vous pensez que ces processus dépassent la limite horaire, mettre en place des temps d'attente autant de fois que nécessaire pour ralentir l'utilisation jusqu'à un niveau sûr. Envisagez d'utiliser par lot avec des mises à jour tolérantes à la latence pour atteindre un débit plus élevé.
  • Préparez-vous à évoluer de manière proactive. Au fur et à mesure que votre application se développe, vous devrez peut-être à augmenter votre utilisation de l'API et des différents points de terminaison. Lisez le Google Documentation sur les quotas de l'API Play Developer pour savoir comment augmentez votre quota lorsque vous approchez de l'utilisation maximale.
  • Planifier de manière stratégique des processus lourds. Essayez de planifier votre catalogue volumineux processus autour des pics d'utilisation critiques, par exemple, vous pouvez éviter de lancer la synchronisation complète du catalogue pendant les pics de ventes de la semaine.

Ajouter une logique de gestion des erreurs de quota

Quelle que soit l'efficacité avec laquelle vous élaborez votre logique de gestion de catalogue, le rendre résilient aux limites de quota inattendues, étant donné que le quota quotidien est partagés par les points de terminaison utilisés dans des modules indépendants de votre intégration. Assurez-vous que vous incluez les erreurs de limitation de quota dans votre traitement des erreurs et vous mettez en œuvre les temps d’attente appropriés. Chaque appel effectué vers les API Google Play Developer génère une réponse. Dans d'échec d'un appel, vous recevez une réponse indiquant l'échec Code d'état de la réponse HTTP et objet errors fournissant des informations supplémentaires sur le domaine d'erreur et un message de débogage. Par exemple, si vous dépassez votre limite quotidienne, une erreur peut s'afficher semblable à ce qui suit:

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

Implémentation de la gestion des catalogues

Les développeurs utilisent les points de terminaison de publication de produits de l'API Google Play Developer pour : synchroniser leur catalogue entre leur backend et Google Play. Création... vous assurer que votre catalogue Google Play est toujours à jour avec le catalogue de votre backend les informations les plus récentes présentent des avantages pour créer une meilleure expérience utilisateur. Exemple :

  • Vous pourrez consulter la liste complète des offres disponibles et gérer des tags d'offre et de forfait de base pour influencer votre propre éligibilité et la diffusion de votre offre logique.
  • Vous pouvez vérifier les différents prix et informations détaillées sur les produits que les utilisateurs sur toutes les plateformes, et assurez-vous qu'ils sont cohérents.
  • Vous aurez accès aux informations détaillées sur vos produits dans votre backend lorsque vous traiterez des achats, sans augmenter la latence ni le risque d'échec d'appels supplémentaires vers l'API Google Play Developer lors des parcours utilisateur critiques.

Vous devez respecter certaines limites et considérations à l'esprit lorsque vous créez votre catalogue de produits sur Google Play. Une fois que vous avez compris et que vous savez comment structurer votre catalogue, décider de votre stratégie de synchronisation.

Stratégies de synchronisation du catalogue

Les points de terminaison de publication de l'API Google Play Developer vous permettent de mettre à jour votre catalogue au fur et à mesure que des modifications se produisent. Parfois, vous devrez peut-être faire une l'approche des mises à jour, qui consiste à envoyer un grand nombre de modifications tout au long du processus. Chaque nécessite des choix de conception différents. Chaque stratégie de synchronisation correspondent mieux à certains cas d'utilisation que d'autres, et il se peut que vous ayez un ensemble de besoins demande les deux, selon la situation. Parfois, vous voudrez peut-être faire d'effectuer une mise à jour d'un produit dès que vous êtes au courant d'un nouveau changement, par exemple pour traiter une mise à jour urgente d'un produit (par exemple, un prix incorrect doit être corrigé comme dès que possible). D'autres fois, vous pouvez utiliser une synchronisation périodique en arrière-plan pour vous assurer votre backend et vos catalogues Play sont toujours cohérents. Quelques exemples d'utilisation courante dans les cas où il peut être utile de mettre en œuvre ces différentes stratégies.

Quand envoyer des mises à jour lorsque votre catalogue en magasin évolue ?

Dans l'idéal, les mises à jour doivent avoir lieu dès que des modifications sont apportées au catalogue produits, afin de minimiser les divergences.

Ce type de mise à jour est particulièrement utile dans les cas suivants:

  • Vous devez vous assurer que vos produits sont toujours à jour.
  • Vous devez apporter quelques modifications à vos produits chaque jour.
  • Vous devez mettre à jour des produits qui sont déjà en production et en cours de vente.

Cette approche est plus simple à implémenter et vous permet de synchroniser votre catalogue avec la période d'écart la plus faible possible.

Quand utiliser les mises à jour périodiques ?

Les mises à jour périodiques sont exécutées de manière asynchrone avec l'édition du produit sur votre backend. Elles constituent une bonne option dans les cas suivants:

  • Vous n'avez pas besoin de vous assurer que vos produits sont mis à jour rapidement.
  • Vous devez planifier les mises à jour groupées ou les processus de rapprochement.
  • Vous disposez déjà d'un système de gestion de contenu ou de catalogue pour gérer vos qui met constamment à jour votre catalogue,

Pour les catalogues volumineux, envisagez d'utiliser des méthodes par lot tolérantes à la latence. pour atteindre un débit maximal.

Créer votre catalogue de produits

Si vous avez un vaste catalogue à importer sur Google Play, vous pouvez automatiser lors du chargement initial. Ce type de processus lourd est plus efficace si une stratégie périodique associées à des méthodes par lot tolérantes à la latence.

Créer des produits ponctuels

Pour la création unique d'un vaste catalogue de produits, nous vous recommandons d'utiliser inappproducts.batchUpdate avec le champ allowMissing défini sur true et le champ latencyTolerance défini sur PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT Cela réduira le temps nécessaire pour créer le catalogue dans les limites des quotas.

Pour les catalogues de petite taille, vous pouvez utiliser la méthode inapp_products.insert. Vous pouvez également utiliser la méthode inappproducts.update avec la allowMissing comme décrit dans la section "Mises à jour de produits". Cette approche a l’avantage de supprimer la nécessité pour votre script d’être avec état et qui peuvent être redémarrés à partir de zéro en cas de problème.

Créer des produits sur abonnement

Pour la création initiale d'un vaste catalogue d'abonnements, nous vous recommandons d'utiliser la méthode Méthode monetization.subscriptions.batchUpdate avec le champ allowMissing défini sur true et le champ latencyTolerance défini à PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. Cela réduira le temps nécessaire pour créer le catalogue dans les limites des quotas.

Pour les petits catalogues d'abonnements, l'API Play Developer fournit monetization.subscriptions.create. Vous pouvez également créer des abonnements avec monetization.subscriptions.update avec la allowMissing comme décrit dans la section "Mises à jour de produits".

Toutes les méthodes précédentes créent des abonnements avec leurs forfaits de base (fournies dans l'objet Subscription). Ces forfaits de base sont initialement inactif. Pour gérer les forfaits de base vous pouvez utiliser monetization.subscriptions.basePlans, y compris en activant un de base pour le proposer à l'achat. De plus, le point de terminaison monetization.subscriptions.basePlans.offers vous permet de créer et de gérer des offres.

Actualités du produit

Les méthodes suivantes vous permettent de modifier efficacement vos produits existants, pour vous assurer que vos offres s'alignent sur vos derniers ajustements.

Mettre à jour les produits ponctuels

Trois méthodes s'offrent à vous pour mettre à jour les produits ponctuels existants.

  • inappproducts.patch Le point de terminaison "patch" permet de mettre à jour partiellement une ressource. Cela signifie que vous peut mettre à jour des champs spécifiques que vous spécifiez dans le corps de la requête. Le correctif est généralement utilisé lorsque vous n'avez besoin de mettre à jour que quelques champs ressource.
  • inappproducts.update Le point de terminaison de mise à jour permet de mettre à jour une ressource dans son intégralité. Cela signifie vous devrez envoyer l'intégralité de l'objet de ressource dans le corps de la requête. La "update point de terminaison" est généralement utilisé lorsque vous devez mettre à jour tous les champs d'une ressource. Lorsque le paramètre allowMissing est défini sur true et que la valeur l'ID produit n'existe pas encore, le point de terminaison insère le produit au lieu d'échouer.
  • inappproducts.batchUpdate : version par lot du point de terminaison de mise à jour, qui vous permet de modifier plusieurs produits avec une seule requête. Utilisez-la en association avec Champ latencyTolerance défini sur PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT pour obtenir un débit plus élevé.

Mettre à jour les produits sur abonnement

Pour mettre à jour des abonnements existants, vous pouvez utiliser le monetization.subscriptions.patch. Cette méthode utilise les paramètres obligatoires suivants:

Sauf si vous créez un abonnement à l'aide du paramètre allowMissing , vous devez fournir le paramètre updateMask. Ce paramètre est une des champs à mettre à jour, séparés par une virgule.

Par exemple, si vous souhaitez seulement mettre à jour la fiche d'un produit sur abonnement, vous devez spécifier le champ listings pour le paramètre updateMask.

monetization.subscriptions.batchUpdate vous permet de mettre à jour plusieurs abonnements à la fois. Utilisez-le avec le champ latencyTolerance défini sur PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT pour atteindre débit.

Pour activer, désactiver, supprimer des forfaits de base ou faire migrer les abonnés vers le les dernières versions du forfait de base utilisent le point de terminaison monetization.subscriptions.basePlans.

Vous pouvez aussi modifier les paramètres avec le paramètre monetization.subscriptions.basePlans.offers.patch .

Rapprochement du catalogue

Vous pouvez choisir de mettre à jour votre catalogue Google Play les modifications du catalogue, ou à intervalles réguliers, si vous disposez d'un système de gestion de catalogues en dehors du catalogue Google Play, il peut y avoir n'est plus synchronisée avec le catalogue dans la configuration de vos applications sur Play. Cela peut être dû à des modifications manuelles urgentes du catalogue dans la console, à une panne sur votre système de gestion des catalogues ou si vous avez perdu vos données les plus récentes.

Vous pouvez créer un processus de rapprochement du catalogue pour éviter des écarts prolongés fenêtre.

Prise en compte des différences du système

Nous vous recommandons de créer un système de diff pour détecter les incohérences et rapprocher les deux systèmes. Voici quelques éléments à prendre en compte lors de la création d'un système de différences pour vous aider à garder votre de vos catalogues:

  • Comprendre les modèles de données:la première étape consiste à comprendre les données. du CMS pour les développeurs et de l'API Google Play Developer. Cela inclut connaître les différents types de données stockées dans chaque système et comment les différents éléments de données correspondent les uns aux autres.
  • Définir les règles de diff.:une fois que vous avez compris les modèles de données, vous devez définir les règles des différences. Ces règles détermineront comment les données des deux systèmes sont comparés. Par exemple, vous pouvez faire correspondre les ID produit et comparer les attributs clés de l'abonnement et des forfaits de base associés ; .
  • Implémenter un algorithme de différences:après avoir défini les règles de différences, vous devez implémenter l'algorithme "diff". Cet algorithme récupère les données des les deux systèmes et les comparer selon les règles que vous avez définies. Pour obtenir les données du catalogue de Google Play, vous pouvez utiliser inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list et monetization.subscriptions.batchGet.
  • Générer des rapports de différences:l'algorithme génère un rapport de différences. Ce rapport indiquera les différences entre les deux systèmes.
  • Rapprocher les différences : une fois le rapport généré, vous aurez besoin des éléments suivants : pour résoudre les différences. Cela peut impliquer de mettre à jour les données dans votre CMS, ou vous devrez peut-être mettre à jour les données de Google Play à l'aide de l'API Developer de la gestion des catalogues, selon la façon dont vous mettez à jour catalogue. Pour rapprocher des produits non synchronisés, utilisez les points de terminaison de mise à jour comme décrit dans dans la section "Mises à jour du produit".

Abandon de produits

L'API Google Play Developer propose plusieurs méthodes pour aider les développeurs à à l'abandon de leurs produits: inappproducts.delete et inappproducts.batchDelete pour les produits ponctuels monetization.subscriptions.delete pour les abonnements. Abandonner un produit peut être nécessaire dans divers scénarios , par exemple:

  • Il a été créé par erreur.
  • Arrêt d'une fonctionnalité ou d'un service

Nous vous recommandons d'intégrer l'abandon de produits dans votre gestion du catalogue. stratégie.

Abandonner les produits ponctuels

Pour supprimer des produits ponctuels avec l'API Google Play Developer, vous devez utiliser la inappproducts.delete ou inappproducts.batchDelete .

Abandon des produits sur abonnement

Vous pouvez supprimer des abonnements à l'aide du monetization.subscriptions.delete . Impossible de supprimer un abonnement une fois qu'au moins un forfait de base a été souscrit activée.