Gestire il catalogo dei prodotti

Questa guida spiega come utilizzare l'API Google Play Developer per creare e gestire un catalogo di prodotti per la tua app Google Play.

Per vendere prodotti nella tua app tramite il sistema di fatturazione di Google Play, devi avere per configurare un catalogo con tutti i prodotti che vuoi rendere disponibili acquistare da parte degli utenti. Puoi farlo tramite Play Console oppure puoi automatizzare la gestione del catalogo usando l'API Google Play Developer. L'automazione può garantire che il catalogo sia sempre aggiornato e scalare su cataloghi di grandi dimensioni dove il coordinamento manuale è impraticabile. In questa guida scoprirai come utilizzare l'API Play Developer per creare e gestire un catalogo dei prodotti per la tua app Google Play. Consulta la nostra guida alla preparazione per istruzioni su come configurare l'API Google Play Developer per l'integrazione backend.

API di gestione del catalogo

Per informazioni sui diversi tipi di prodotti che puoi vendere con il sistema di fatturazione, leggere Comprendere i tipi di prodotti in-app e le considerazioni sul catalogo. Google offre due set principali di API per la gestione del catalogo su Google Play: corrispondenti alle due categorie di prodotto principali:

  • Prodotti a pagamento singolo
  • Prodotti in abbonamento

Prodotti a pagamento singolo

L'endpoint inappproducts ti consente di gestire dal tuo backend. Ciò include la creazione, l'aggiornamento e l'eliminazione prodotti e la gestione di prezzi e disponibilità. A seconda di come gestisci gli acquisti di prodotti una tantum, potrai prodotti di consumo (possono essere acquistati tutte le volte che si desidera) o permanenti diritti (non possono essere creati due volte dallo stesso utente). Puoi decidere quali i prodotti a pagamento singolo dovrebbero essere consumabili o meno.

Prodotti in abbonamento

L'endpoint monetization.subscriptions ti aiuta a gestire l'abbonamento dal backend dello sviluppatore. Ad esempio, puoi creare, aggiornare ed eliminare abbonamenti o controllarne la disponibilità e i prezzi a livello regionale. Oltre all'endpoint monetization.subscriptions, forniamo anche monetization.subscriptions.basePlans e monetization.subscriptions.basePlans.offers per gestire rispettivamente abbonamenti piani base e offerte.

Metodi batch

inappproducts e monetization.subscriptions forniscono una serie di metodi batch che consentono di recuperare a 100 entità nella stessa app contemporaneamente.

I metodi batch, se utilizzati con la tolleranza di latenza abilitata, supportano una maggiore velocità effettiva elevata e sono particolarmente utili per gli sviluppatori di cataloghi di grandi dimensioni per creazione di cataloghi o riconciliazione di cataloghi.

Aggiorna latenza di propagazione e velocità effettiva

Dopo che una richiesta di creazione o modifica di un prodotto viene completata, le modifiche potrebbero non essere immediatamente visibile agli utenti finali sui loro dispositivi a causa della rete o del backend ritardi nell'elaborazione. Per impostazione predefinita, tutte le richieste di modifica dei prodotti sono sensibili alla latenza. Ciò significa sono ottimizzati per una rapida propagazione attraverso sistemi di backend, che si riflette sui dispositivi degli utenti finali in pochi minuti. Esiste però un limite orario sul numero di queste richieste di modifica. Nei casi in cui devi creare o aggiornare molti prodotti (ad esempio, durante creazione iniziale di un catalogo di grandi dimensioni), puoi utilizzare metodi batch con Campo latencyTolerance impostato su PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT Ciò aumenterà notevolmente la velocità effettiva di aggiornamento. Aggiornamenti a tolleranza di latenza la propagazione ai dispositivi degli utenti finali può richiedere fino a 24 ore.

Configurazione della quota

Esistono diversi limiti di quota che devi conoscere quando utilizzi Play Developer API per gestire il catalogo dei prodotti:

  1. Le API Google Play Developer hanno un limite predefinito di 200.000 query per giorno. Questo limite quota si applica all'aggregazione dell'utilizzo in tutti gli endpoint, incluse le API di gestione dei cataloghi.
  2. Gli endpoint di modifica dei prodotti prevedono inoltre un limite di 7200 query per ora. Si tratta di un unico limite per i prodotti a pagamento singolo e per gli abbonamenti e in tutte le richieste di modifica, tra cui creazione, aggiornamento, attivazione, eliminare. Le chiamate al metodo di modifica in batch vengono conteggiate come una query per questa quota, a prescindere dal numero di singole richieste incluse o dalla loro latenza sensibilità.
  3. Anche le modifiche sensibili alla latenza hanno un limite di 7200 modifiche all'ora. Per i metodi batch, ogni richiesta di modifica nidificata viene conteggiata separatamente ai fini di questa quota. Questa quota ha pratiche Implicazioni solo per gli utenti di API batch che eseguono attività sensibili alla latenza come in altri casi, la quota 2 verrà esaurita prima o come questa quota.

Ecco alcuni esempi illustrativi per comprendere l'utilizzo della quota diverse richieste:

  • Una singola richiesta get per recuperare un elemento consumerà 1 token della quota 1 e nessun token delle quote 2 e 3 (in quanto riguardano solo gli endpoint di modifica).
  • Una richiesta batch get per recuperare fino a 100 elementi consumerà anche 1 token di quota 1 e nessun token di quota 2 e 3.
  • Una singola richiesta modification per un elemento consumerà 1 token della quota 1 , 1 token della quota 2. Se la richiesta è sensibile alla latenza, e consuma 1 token della quota 3. Poiché la quota C ha lo stesso limite della quota 2, non ha implicazioni pratiche per gli utenti che utilizzano una sola modifica di machine learning.
  • Una richiesta batch modification per 100 elementi con tolleranza di latenza consumerà 1 token della quota 1, 1 token della quota 2. La configurazione di questa quota deve consentire un'ampia per mantenere aggiornato il catalogo, ma se l'algoritmo non è a conoscenza questa quota e supera questo tasso, potresti ricevere un errore per ogni chiamata aggiuntiva.
  • Una richiesta batch modification per 100 elementi sensibili alla latenza consumerà 1 token della quota 1, 1 token della quota 2 e 100 token della quota 3.

Suggerimenti sull'utilizzo dell'API Catalog Management

Se accetti queste linee guida, ottimizzi le interazioni con l'API, garantendo un'esperienza di gestione del catalogo fluida ed efficiente.

Monitora l'utilizzo

È bene prestare attenzione ai processi di utilizzo intensivo. Ad esempio, all'inizio di e l'integrazione, è più probabile che gli endpoint di gestione del catalogo utilizzino quota aggiuntiva per creare il catalogo iniziale completo e ciò potrebbe influire all'utilizzo in produzione di altri endpoint come l'API purchase status, se vicino al limite di utilizzo complessivo. Devi monitorare il consumo della quota per assicurarti di non superando le quote dell'API. Esistono diversi modi per monitorare l'utilizzo. Ad esempio: puoi utilizzare la dashboard delle quote delle API Google Cloud oppure qualsiasi altra dashboard di monitoraggio delle API di terze parti a tua scelta.

Ottimizza l'utilizzo delle quote dell'API

Ti consigliamo vivamente di ottimizzare il consumo delle tariffe per ridurre al minimo la probabilità Errori relativi all'API. Per implementarlo in modo efficace, ti consigliamo di:

  • Scegli la giusta strategia di gestione del catalogo. Una volta compreso il funzionamento dell'API, di quota, devi scegliere la strategia che l'applicazione e gestire gli obiettivi di gestione del catalogo in modo efficiente.
  • Effettua solo il numero minimo di chiamate necessario per riflettere le modifiche.
  • Non inviare chiamate di modifica ridondanti o non necessarie alle API. Questo potrebbe richiedere la conservazione di un log delle modifiche nel catalogo di backend.
  • Rimani sotto il limite orario di 7200 query di modifica del prodotto. Puoi creare processi di sincronizzazione che richiedono una grande quantità di modifiche in un breve periodo di tempo (ad esempio, una creazione creazione. Se prevedi che questi processi superino il limite orario, implementare i tempi di attesa come necessario per rallentare l'utilizzo a un livello sicuro. Valuta l'uso metodi batch con aggiornamenti che tollerano la latenza per ottenere una velocità effettiva più elevata.
  • Preparati in modo proattivo alla scalabilità. Man mano che la tua applicazione cresce, potresti dover fare lo scale up dell’uso dell’API e dei vari endpoint. Leggi le informazioni Documentazione sulle quote dell'API Play Developer per maggiori dettagli su come aumenta la quota quando ti avvicini all'utilizzo massimo.
  • Pianifica in modo strategico processi intensivi. Prova a pianificare il tuo catalogo pesante di elaborazione in caso di picchi di utilizzo critici, ad esempio puoi evitare di eseguire la sincronizzazione dell'intero catalogo durante i periodi di picco delle vendite della settimana.

Aggiungi logica di gestione degli errori di quota

A prescindere da quanto sia efficiente la tua logica di gestione del catalogo, la rende resiliente a limiti di quota imprevisti, dato che la quota giornaliera è condivisi dagli endpoint utilizzati in moduli indipendenti dell'integrazione. Assicurati che includi errori di limitazione della quota nella gestione degli errori e implementi con le attese appropriate. Ogni chiamata effettuata alle API Google Play Developer genererà una risposta. Nella in caso di errore di una chiamata, riceverai una risposta di errore che include Codice di stato della risposta HTTP e un oggetto errors, con ulteriori dettagli sul dominio di errore e un messaggio di debug. Ad esempio, se superi il limite giornaliero, potresti riscontrare un errore simile al seguente:

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

Implementazione della gestione del catalogo

Gli sviluppatori utilizzano gli endpoint di pubblicazione dei prodotti API Google Play Developer per che mantengono sincronizzato il proprio catalogo tra il backend e Google Play. Creazione Assicurati che il catalogo di Google Play sia sempre aggiornato con quello del tuo backend le informazioni più recenti presentano vantaggi nel creare una migliore esperienza utente. Ad esempio:

  • Potrai consultare l'elenco completo delle offerte disponibili e gestire tag di offerte e piani base per influenzare la tua idoneità e la pubblicazione dell'offerta. logica.
  • Puoi controllare i diversi prezzi consigliati e dettagli dei prodotti a cui gli utenti vedere in più piattaforme e assicurarti che siano coerenti.
  • I dettagli del prodotto saranno a portata di mano nel backend durante l'elaborazione di nuovi acquisti, senza la necessità di aumentare la latenza e il rischio di fallimento effettuando chiamate aggiuntive all'API Google Play Developer durante i flussi critici dell'utente.

Ci sono determinati limiti e considerazioni che devi rispettare al momento di creare il catalogo dei prodotti su Google Play. Una volta compresi i requisiti limiti e sai come vuoi strutturare il catalogo, è il momento decidere la strategia di sincronizzazione.

Strategie di sincronizzazione del catalogo

Gli endpoint di pubblicazione dell'API Google Play Developer consentono di aggiornare al catalogo man mano che si verificano modifiche. A volte, può essere necessario eseguire periodicamente di aggiornamento, in cui invii una batteria di modifiche durante la stessa procedura. Ciascuna richiede diverse scelte di progettazione. Ogni strategia di sincronizzazione si adattano meglio ad alcuni casi d'uso e potresti avere una serie di esigenze per entrambe le operazioni, a seconda della situazione. A volte potresti voler creare a un prodotto nel momento in cui sei a conoscenza di una nuova modifica, ad esempio per elaborare un aggiornamento urgente del prodotto (ad esempio, è necessario correggere un prezzo errato il prima possibile). Altre volte, invece, puoi ricorrere a una sincronizzazione periodica in background per assicurarti il tuo backend e i cataloghi di Google Play siano sempre coerenti. Leggi alcuni usi comuni in cui potresti voler implementare queste diverse opzioni di gestione strategie.

Quando inviare aggiornamenti quando il catalogo locale cambia

Idealmente, gli aggiornamenti dovrebbero avvenire non appena vengono apportate modifiche catalogo dei prodotti per ridurre al minimo le discrepanze.

Questo tipo di aggiornamenti è una buona soluzione quando:

  • Devi assicurarti che i tuoi prodotti siano sempre aggiornati.
  • Ogni giorno devi apportare alcune modifiche ai tuoi prodotti.
  • Devi aggiornare i prodotti già in produzione e in vendita.

Questo approccio è più semplice da implementare e ti consente di mantenere sincronizzato il catalogo con la finestra di discrepanza dell'importo minimo.

Quando utilizzare gli aggiornamenti periodici

Gli aggiornamenti periodici vengono eseguiti in modo asincrono rispetto all'edizione del prodotto sul tuo backend. e sono una buona opzione quando:

  • Non devi assicurarti che i tuoi prodotti vengano aggiornati con un breve preavviso.
  • Devi pianificare aggiornamenti collettivi o processi di conciliazione.
  • Disponi già di un sistema di gestione dei contenuti o del catalogo per gestire prodotti digitali e che aggiorna il tuo catalogo costantemente

Nel caso di cataloghi di grandi dimensioni, valuta l'utilizzo di metodi batch con tolleranza di latenza per raggiungere la velocità effettiva massima.

Creare il catalogo dei prodotti

Se hai un ampio catalogo da caricare su Google Play, ti consigliamo di automatizzare al caricamento iniziale. Questo tipo di processo intensivo funziona meglio se si utilizza una strategia periodica in combinazione con metodi batch a tolleranza di latenza.

Creare prodotti a pagamento singolo

Per la creazione iniziale di un catalogo di prodotti di grandi dimensioni una tantum, ti consigliamo di utilizzare Metodo inappproducts.batchUpdate con il campo allowMissing impostato su true e il campo latencyTolerance impostati su PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT In questo modo ridurrai al minimo il tempo necessario per creare il catalogo entro i limiti di quota.

Per cataloghi più piccoli, puoi utilizzare il metodo inapp_products.insert. In alternativa, puoi utilizzare il metodo inappproducts.update con il metodo allowMissing come descritto nella sezione Aggiornamenti del prodotto. Questo approccio ha il vantaggio di eliminare la necessità che lo script stateful e può essere riavviato da zero, in caso di problemi.

Creare prodotti in abbonamento

Per la creazione iniziale di un catalogo di grandi dimensioni in abbonamento, ti consigliamo di utilizzare Metodo monetization.subscriptions.batchUpdate con il campo allowMissing impostato su true e il campo latencyTolerance impostato a PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. In questo modo ridurrai al minimo il tempo necessario per creare il catalogo entro i limiti di quota.

Per i cataloghi di abbonamenti più piccoli, l'API Play Developer fornisce la monetization.subscriptions.create. In alternativa, puoi creare abbonamenti utilizzando monetization.subscriptions.update con il metodo allowMissing come descritto nella sezione Aggiornamenti del prodotto.

Tutti i metodi precedenti creano abbonamenti insieme ai relativi piani base (fornito all'interno dell'oggetto Subscription). All'inizio, questi piani base non attivo. Per gestire i piani base puoi utilizzare lo stato Endpoint monetization.subscriptions.basePlans, inclusa l'attivazione di un un piano base per renderlo disponibile per l'acquisto. Inoltre, l'endpoint monetization.subscriptions.basePlans.offers ti consente di creare e gestire le offerte.

Aggiornamenti sul prodotto

I seguenti metodi consentono di modificare in modo efficiente i prodotti esistenti, assicurando che le offerte siano in linea con gli ultimi aggiustamenti.

Aggiorna i prodotti a pagamento singolo

Hai a disposizione tre metodi per aiutarti ad aggiornare i prodotti a pagamento singolo esistenti.

  • inappproducts.patch : l'endpoint patch viene utilizzato per aggiornare parzialmente una risorsa. Ciò significa che aggiornare campi specifici specificati nel corpo della richiesta. La patch in genere viene utilizzato quando è necessario aggiornare solo alcuni campi di un risorsa.
  • inappproducts.update : l'endpoint di aggiornamento viene utilizzato per aggiornare una risorsa nella sua interezza. Ciò significa devi inviare l'intero oggetto risorsa nel corpo della richiesta. La di aggiornamento dell'endpoint in genere viene utilizzato quando devi aggiornare tutti i campi in un risorsa. Quando il parametro allowMissing è impostato su true e il valore fornito l'ID prodotto non esiste già, l'endpoint inserirà il prodotto anziché fallire.
  • inappproducts.batchUpdate : si tratta di una versione batch dell'endpoint di aggiornamento, che consente di modificare più prodotti con una singola query. Usala insieme Campo latencyTolerance impostato su PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT per ottenere una velocità effettiva più elevata.

Aggiornare i prodotti in abbonamento

Per aggiornare gli abbonamenti esistenti, puoi usare monetization.subscriptions.patch. Questo metodo accetta i seguenti parametri obbligatori:

A meno che tu non stia creando una nuova sottoscrizione utilizzando il parametro allowMissing , devi fornire il parametro updateMask. Questo parametro è un parametro un elenco separato da virgole dei campi che vuoi aggiornare.

Ad esempio, se vuoi aggiornare solo la scheda di un prodotto in abbonamento, devi specificare il campo listings nel parametro updateMask.

Puoi utilizzare monetization.subscriptions.batchUpdate per aggiornare più abbonamenti contemporaneamente. Utilizzalo insieme al campo latencyTolerance impostato su PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT per raggiungere obiettivi più alti e la velocità effettiva effettiva.

Per attivare, disattivare, eliminare i piani base o eseguire la migrazione degli abbonati al le versioni più recenti dei prezzi dei piani base utilizzano l'endpoint monetization.subscriptions.basePlans.

Inoltre, puoi aggiornare i piani base con monetization.subscriptions.basePlans.offers.patch .

Riconciliazione del catalogo

Sia che tu scelga di aggiornare il catalogo di Google Play ogni volta al catalogo modifiche o periodicamente, se disponi di un sistema di gestione del catalogo al di fuori del catalogo di Google Play, potrebbero esserci situazioni in cui non è sincronizzato con il catalogo nella configurazione delle tue app su Play. Ciò potrebbe essere dovuto a modifiche manuali al catalogo di emergenza nella console, a un'interruzione del servizio sul tuo sistema di gestione del catalogo o forse in caso di perdita dei dati più recenti.

Puoi creare un processo di riconciliazione del catalogo per evitare discrepanze prolungate finestra.

Considerazione del sistema diff

Consigliamo di creare un sistema delle differenze per rilevare incoerenze e riconciliare due sistemi. Di seguito sono riportati alcuni aspetti da considerare quando crei un sistema di differenze per cataloghi sincronizzati:

  • Comprendere i modelli dei dati: il primo passo consiste nel comprendere i dati del CMS per sviluppatori e dell'API Google Play Developer. Sono inclusi conoscendo i diversi tipi di dati archiviati in ciascun sistema i diversi elementi dei dati sono mappati tra loro.
  • Definisci le regole delle differenze: dopo aver compreso i modelli dei dati, devi devi definire le regole delle differenze. Queste regole determineranno il modo in cui i dati nei due sistemi diversi. Ad esempio, potresti voler far corrispondere gli ID prodotto e confrontare gli attributi chiave dell'abbonamento e i piani base associati e offerte.
  • Implementare un algoritmo diff:una volta definite le regole diff, implementare l'algoritmo diff. Questo algoritmo prenderà i dati i due sistemi e confrontarli in base alle regole che avete definito. Per ottenere i dati del catalogo di Google Play, puoi utilizzare inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list e monetization.subscriptions.batchGet metodi.
  • Generare report delle differenze: l'algoritmo delle differenze genera un report sulle differenze. Questo report mostrerà le differenze tra i due sistemi.
  • Riconciliazione delle differenze: dopo aver generato il report delle differenze, è necessario per risolvere le differenze. Potresti dover aggiornare i dati nel tuo CMS. potrebbe comportare l'aggiornamento dei dati da parte di Google Play utilizzando l'API per sviluppatori di gestione del catalogo, a seconda di come aggiorni catalogo. Per riconciliare prodotti non sincronizzati, utilizzare gli endpoint di aggiornamento come descritto in sezione Aggiornamenti prodotto.

Ritiro del prodotto

L'API Google Play Developer offre diversi metodi per aiutare gli sviluppatori nel che ritira i loro prodotti: inappproducts.delete e inappproducts.batchDelete per i prodotti a pagamento singolo e monetization.subscriptions.delete per gli abbonamenti. Il ritiro di un prodotto può essere necessario in vari scenari , ad esempio:

  • Creazione per errore.
  • Interruzione di una funzionalità o un servizio.

Consigliamo di integrare il ritiro dei prodotti nella gestione del catalogo strategia.

Ritira i prodotti a pagamento singolo

Per eliminare i prodotti a pagamento singolo con l'API Google Play Developer, devi utilizzare il inappproducts.delete o inappproducts.batchDelete .

Ritira i prodotti in abbonamento

Puoi eliminare le sottoscrizioni utilizzando monetization.subscriptions.delete . Impossibile rimuovere un abbonamento dopo aver ricevuto almeno un piano base è stata attivata.