Produktkatalog verwalten

In diesem Leitfaden wird beschrieben, wie Sie mit der Google Play Developer API einen Produktkatalog für Ihre Play-App erstellen und verwalten.

Wenn Sie Produkte in Ihrer App über das Abrechnungssystem von Google Play verkaufen möchten, müssen Sie einen Katalog mit allen Produkten einrichten, die Sie Ihren Nutzern zum Kauf anbieten möchten. Das ist über die Play Console möglich. Sie können die Katalogverwaltung auch mit der Google Play Developer API automatisieren. Mithilfe von Automatisierung können Sie dafür sorgen, dass Ihr Katalog immer auf dem neuesten Stand ist, und ihn auf große Kataloge skalieren, bei denen eine manuelle Koordination unpraktisch ist. In diesem Leitfaden erfahren Sie, wie Sie mit der Play Developer API einen Produktkatalog für Ihre Play-App erstellen und verwalten. In unserem Leitfaden Vorbereitung finden Sie eine Anleitung zum Einrichten der Google Play Developer API für Ihre Backend-Integration.

APIs für die Katalogverwaltung

Informationen zu den verschiedenen Produkttypen, die Sie mit dem Abrechnungssystem von Google Play verkaufen können, finden Sie im Hilfeartikel Überlegungen zu In‑App-Produkttypen und Katalogen. Google bietet zwei Hauptgruppen von APIs für die Katalogverwaltung bei Google Play an, die den beiden Hauptproduktkategorien entsprechen:

  • Einmalkaufprodukte
  • Aboprodukte

Einmalkaufprodukte

Über den Endpunkt inappproducts können Sie einmalige Produkte über Ihr Backend verwalten. Dazu gehört das Erstellen, Aktualisieren und Löschen von Produkten sowie das Verwalten von Preisen und Verfügbarkeit. Je nachdem, wie Sie Einmalkaufprodukte handhaben, modellieren Sie Verbrauchsprodukte (können beliebig oft gekauft werden) oder dauerhafte Berechtigungen (können vom selben Nutzer nicht zweimal erworben werden). Sie können festlegen, ob einmalige Produkte konsumierbar sein sollen oder nicht.

Aboprodukte

Mit dem Endpunkt monetization.subscriptions können Sie Aboprodukte über Ihr Entwickler-Backend verwalten. Sie können beispielsweise Abos erstellen, aktualisieren und löschen oder ihre regionale Verfügbarkeit und Preise steuern. Zusätzlich zum Endpunkt monetization.subscriptions bieten wir auch monetization.subscriptions.basePlans und monetization.subscriptions.basePlans.offers an, um die Basis-Abos und Angebote von Abos zu verwalten.

Batchmethoden

Die Endpunkte inappproducts und monetization.subscriptions bieten eine Reihe von Batchmethoden, mit denen bis zu 100 Entitäten in derselben App gleichzeitig abgerufen oder verwaltet werden können.

Batchmethoden mit aktivierter Latenztoleranz unterstützen einen höheren Durchsatz und sind besonders für Entwickler großer Kataloge beim Erstellen oder Abgleichen von Katalogen nützlich.

Aktualisieren Sie die Ausbreitungslatenz im Vergleich zum Durchsatz.

Nachdem ein Antrag auf Produkterstellung oder -änderung abgeschlossen wurde, sind die Änderungen aufgrund von Verzögerungen bei der Netzwerk- oder Backendverarbeitung möglicherweise nicht sofort auf den Geräten der Endnutzer sichtbar. Standardmäßig sind alle Anfragen zur Produktänderung latensempfindlich. Das bedeutet, dass sie für eine schnelle Weiterleitung über Backend-Systeme optimiert sind und in der Regel innerhalb weniger Minuten auf den Endnutzergeräten zu sehen sind. Die Anzahl solcher Änderungsanfragen ist jedoch stündlich begrenzt. Wenn Sie viele Produkte erstellen oder aktualisieren müssen (z. B. beim Erstellen eines großen Katalogs), können Sie Batchmethoden verwenden, bei denen das Feld latencyTolerance auf PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT festgelegt ist. Dadurch wird der Update-Durchsatz erheblich erhöht. Es kann bis zu 24 Stunden dauern, bis latenztolerante Updates auf den Geräten der Endnutzer übernommen werden.

Kontingentkonfiguration

Wenn Sie Ihren Produktkatalog mit der Play Developer API verwalten, sollten Sie sich über die folgenden Kontingentlimits im Klaren sein:

  1. Die Google Play Developer APIs haben ein Standardlimit von 200.000 Abfragen pro Tag. Dieses Kontingentlimit gilt für die Gesamtnutzung aller Endpunkte, einschließlich APIs zur Katalogverwaltung.
  2. Für Endpunkte für Produktänderungen gilt außerdem ein Limit von 7.200 Anfragen pro Stunde. Dieses Limit gilt sowohl für Einmalkaufprodukte als auch für Abos und für alle Änderungsanfragen, einschließlich Erstellung, Aktualisierung, Aktivierung und Löschen. Aufrufe von Methoden zur Batch-Änderung werden für dieses Kontingent als eine Abfrage gezählt, unabhängig von der Anzahl der enthaltenen einzelnen Anfragen oder ihrer Latenz.
  3. Bei latenzempfindlichen Änderungen gilt außerdem ein Limit von 7.200 Änderungen pro Stunde. Bei Batchmethoden wird jede verschachtelte Änderungsanfrage für dieses Kontingent separat gezählt. Dieses Kontingent hat nur praktische Auswirkungen auf die Nutzer der Batch API, die latenzempfindliche Updates ausführen, da in anderen Fällen Kontingent 2 vor oder gleichzeitig mit diesem Kontingent aufgebraucht wird.

Hier einige Beispiele, die die Kontingentnutzung verschiedener Anfragen veranschaulichen:

  • Eine einzelne get-Anfrage zum Abrufen eines Elements verbraucht ein Token von Kontingent 1 und keine Tokens von Kontingent 2 und 3, da sie sich nur auf Änderungsendpunkte beziehen.
  • Eine Batch-get-Anfrage zum Abrufen von bis zu 100 Elementen verbraucht ebenfalls ein Token für Kontingent 1 und keine Tokens für Kontingent 2 und 3.
  • Eine einzelne modification-Anfrage für einen Artikel verbraucht ein Token für Kontingent 1 und ein Token für Kontingent 2. Wenn die Anfrage latenzabhängig ist, wird auch ein Token des Kontingents 3 verbraucht. Da Kontingent C dasselbe Limit wie Kontingent 2 hat, hat es keine praktischen Auswirkungen für Nutzer, die nur einzelne Änderungsmethoden verwenden.
  • Eine Batch-modification-Anfrage für 100 latenztolerante Elemente verbraucht ein Token für Kontingent 1 und ein Token für Kontingent 2. Diese Kontingenteinstellung sollte ausreichend Spielraum bieten, um Ihren Katalog auf dem neuesten Stand zu halten. Wenn Ihr Algorithmus dieses Kontingent jedoch nicht berücksichtigt und diese Rate überschreitet, erhalten Sie möglicherweise bei jedem zusätzlichen Aufruf eine Fehlermeldung.
  • Eine Batch-modification-Anfrage für 100 latenzempfindliche Elemente verbraucht 1 Token für Kontingent 1, 1 Token für Kontingent 2 und 100 Token für Kontingent 3.

Empfehlungen für die Nutzung der Catalog Management API

Wenn Sie diese Richtlinien einhalten, optimieren Sie Ihre Interaktionen mit der API und sorgen für eine reibungslose und effiziente Katalogverwaltung.

Nutzung im Blick behalten

Sie sollten sich über Prozesse mit hoher Auslastung im Klaren sein. Am Anfang Ihrer Integration ist es beispielsweise wahrscheinlicher, dass die Endpunkte für die Katalogverwaltung mehr Kontingent verbrauchen, um den vollständigen ursprünglichen Katalog zu erstellen. Dies kann sich potenziell auf die Produktionsnutzung anderer Endpunkte wie der API für den Kaufstatus auswirken, wenn Sie sich dem Gesamtnutzungslimit nähern. Sie müssen Ihren Kontingentverbrauch im Blick behalten, damit Sie die API-Kontingente nicht überschreiten. Es gibt mehrere Möglichkeiten, die Nutzung zu überwachen. Sie können beispielsweise das Kontingentsdashboard für Google Cloud APIs oder ein anderes internes oder externes API-Monitoring-Tool verwenden.

API-Kontingentnutzung optimieren

Wir empfehlen dringend, die Ratennutzung zu optimieren, um die Wahrscheinlichkeit von API-Fehlern zu minimieren. Für eine effektive Implementierung empfehlen wir Folgendes:

  • Wählen Sie die richtige Strategie für die Katalogverwaltung aus. Nachdem Sie das API-Kontingent kennen, müssen Sie die richtige Strategie für Ihre Anwendung auswählen, um Ihre Zielvorhaben für die Katalogverwaltung effizient zu erreichen.
  • Führen Sie nur die Mindestanzahl von Aufrufen aus, die erforderlich sind, um Ihre Änderungen zu berücksichtigen.
  • Senden Sie keine redundanten oder unnötigen Änderungsanfragen an die APIs. Möglicherweise musst du dafür einen Änderungslog in deinem Back-End-Katalog führen.
  • Die stündliche Obergrenze von 7.200 Abfragen für Produktänderungen darf nicht überschritten werden. Möglicherweise möchten Sie Synchronisierungsprozesse erstellen, bei denen Sie in kurzer Zeit eine große Anzahl von Produktänderungen vornehmen müssen (z. B. bei der Ersterstellung eines Katalogs). Wenn Sie davon ausgehen, dass diese Prozesse das stündliche Limit überschreiten, implementieren Sie bei Bedarf Wartezeiten, um die Nutzung auf ein sicheres Niveau zu senken. Sie können Batchmethoden mit latenztoleranten Aktualisierungen verwenden, um einen höheren Durchsatz zu erzielen.
  • Proaktiv auf die Skalierung vorbereiten Wenn Ihre Anwendung wächst, müssen Sie möglicherweise die Nutzung der API und der verschiedenen Endpunkte skalieren. In der Dokumentation zu Kontingenten für die Google Play Developer API finden Sie Informationen dazu, wie Sie Ihr Kontingent erhöhen können, wenn Sie die maximale Nutzung erreichen.
  • Planen Sie ressourcenintensive Prozesse strategisch. Planen Sie Ihre umfangreichen Katalogprozesse außerhalb von Spitzenzeiten. Sie können beispielsweise vermeiden, eine vollständige Katalogsynchronisierung während der Spitzenverkäufe der Woche auszuführen.

Logik zur Fehlerbehandlung bei Kontingenten hinzufügen

Unabhängig davon, wie effizient Sie die Logik für die Katalogverwaltung erstellen, sollten Sie sie so gestalten, dass sie unerwartete Kontingentlimits abfedern kann. Das Tageskontingent wird nämlich von Endpunkten geteilt, die in unabhängigen Modulen Ihrer Integration verwendet werden. Achten Sie darauf, Fehler bei der Kontingentdrosselung in Ihre Fehlerbehandlung aufzunehmen und die entsprechenden Wartezeiten zu implementieren. Jeder Aufruf der Google Play-Entwickler-APIs generiert eine Antwort. Bei einem fehlgeschlagenen Aufruf erhalten Sie eine Fehlerantwort mit einem HTTP-Antwortstatuscode und einem errors-Objekt, das weitere Details zur Fehlerdomain und eine Debug-Nachricht enthält. Wenn Sie beispielsweise Ihr Tageslimit überschreiten, wird möglicherweise eine ähnliche Fehlermeldung wie die folgende angezeigt:

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

Implementierung der Katalogverwaltung

Entwickler verwenden die Endpunkte für die Produktveröffentlichung der Google Play Developer API, um ihren Katalog zwischen ihrem Backend und Google Play zu synchronisieren. Wenn Sie dafür sorgen, dass Ihr Google Play-Katalog immer mit den neuesten Informationen aus Ihrem Backend-Katalog übereinstimmt, können Sie die Nutzerfreundlichkeit verbessern. Beispiel:

  • Du kannst die vollständige Liste der verfügbaren Angebote aufrufen und Angebots- und Base Plan-Tags verwalten, um deine eigene Berechtigung und die Logik für die Präsentation von Angeboten zu beeinflussen.
  • Sie können die verschiedenen Preispunkte und Produktdetails prüfen, die Nutzern auf verschiedenen Plattformen angezeigt werden, und dafür sorgen, dass sie einheitlich sind.
  • Sie haben Produktdetails in Ihrem Backend zur Hand, wenn Sie neue Käufe verarbeiten, ohne dass die Latenz und das Risiko von Fehlern durch zusätzliche Aufrufe der Google Play Developer API während kritischer Nutzerabläufe erhöht werden.

Beim Erstellen Ihres Produktkatalogs bei Google Play sind bestimmte Einschränkungen und Aspekte zu beachten. Sobald du diese Limits kennst und weißt, wie du deinen Katalog strukturieren möchtest, kannst du dich für eine Synchronisierungsstrategie entscheiden.

Strategien für die Katalogsynchronisierung

Mit den Veröffentlichungsendpunkten der Google Play Developer API können Sie Ihren Katalog bei Bedarf aktualisieren. Gelegentlich müssen Sie möglicherweise regelmäßige Updates durchführen, bei denen Sie mehrere Änderungen im selben Prozess senden. Für jeden Ansatz sind unterschiedliche Designentscheidungen erforderlich. Jede Synchronisierungsstrategie eignet sich für manche Anwendungsfälle besser als für andere. Je nach Situation sind möglicherweise beide Strategien erforderlich. Manchmal möchten Sie ein Produkt aktualisieren, sobald Sie von einer neuen Änderung erfahren. Das ist beispielsweise der Fall, wenn ein dringendes Produktupdate erforderlich ist, also ein falscher Preis so schnell wie möglich korrigiert werden muss. In anderen Fällen können Sie eine regelmäßige Hintergrundsynchronisierung verwenden, um dafür zu sorgen, dass Ihr Backend und Ihre Play-Kataloge immer übereinstimmen. Lesen Sie einige häufige Anwendungsfälle, in denen Sie diese verschiedenen Strategien zur Katalogverwaltung implementieren könnten.

Wann Sie Updates senden sollten, wenn sich Ihr lokaler Katalog ändert

Idealerweise sollten Aktualisierungen erfolgen, sobald sich der Produktkatalog Ihres Backends ändert, um Abweichungen zu minimieren.

Diese Art von Updates ist eine gute Option, wenn:

  • Ihre Produkte müssen immer auf dem neuesten Stand sein.
  • Sie müssen jeden Tag einige Änderungen an Ihren Produkten vornehmen.
  • Sie müssen Produkte aktualisieren, die bereits in Produktion sind und verkauft werden.

Dieser Ansatz ist einfacher zu implementieren und ermöglicht es Ihnen, Ihren Katalog mit dem Zeitfenster für die geringste Abweichung in Einklang zu halten.

Wann sollten Sie regelmäßige Updates verwenden?

Regelmäßige Updates werden asynchron zur Produktversion in Ihrem Backend ausgeführt. Sie eignen sich gut in folgenden Fällen:

  • Sie müssen Ihre Produkte nicht kurzfristig aktualisieren.
  • Sie müssen Bulk-Aktualisierungen oder Abgleichprozesse planen.
  • Sie haben bereits ein Content- oder Katalogverwaltungssystem für Ihre digitalen Produkte, mit dem Ihr Katalog ständig aktualisiert wird.

Bei großen Katalogen sollten Sie Batchmethoden mit latenztoleranten Aktualisierungen verwenden, um den maximalen Durchsatz zu erzielen.

Produktkatalog erstellen

Wenn Sie einen großen Katalog bei Google Play hochladen möchten, sollten Sie das erste Laden automatisieren. Diese Art von ressourcenintensivem Prozess funktioniert am besten, wenn eine regelmäßige Strategie mit latenztoleranten Batchmethoden kombiniert wird.

Einmalkaufprodukte erstellen

Für die erstmalige Erstellung eines großen Produktkatalogs empfehlen wir die Methode inappproducts.batchUpdate. Legen Sie dabei das Feld allowMissing auf true und das Feld latencyTolerance auf PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT fest. So wird die Zeit für die Erstellung des Katalogs innerhalb der Kontingentlimits minimiert.

Bei kleineren Katalogen können Sie die Methode inapp_products.insert verwenden. Alternativ können Sie die Methode inappproducts.update mit dem Parameter allowMissing verwenden, wie im Abschnitt zu Produktupdates beschrieben. Bei diesem Ansatz muss Ihr Script nicht zustandsabhängig sein und kann bei einem Fehler von vorn gestartet werden.

Aboprodukte erstellen

Für die Ersteinrichtung eines großen Katalogs empfehlen wir die Methode monetization.subscriptions.batchUpdate. Dabei muss das Feld allowMissing auf true und das Feld latencyTolerance auf PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT festgelegt sein. So wird die Zeit für das Erstellen des Katalogs innerhalb der Kontingentlimits minimiert.

Für kleinere Abokataloge bietet die Play Developer API die Methode monetization.subscriptions.create. Alternativ können Sie Abos mit der Methode monetization.subscriptions.patch und dem Parameter allowMissing erstellen, wie im Abschnitt zu Produktupdates beschrieben.

Bei allen vorherigen Methoden werden Abos zusammen mit ihren Basistarifen erstellt (im Aboobjekt angegeben). Diese Basis-Abos sind anfangs inaktiv. Du kannst den Status von Base Plans über den Endpunkt monetization.subscriptions.basePlans verwalten. Du kannst damit auch einen Base Plan aktivieren, um ihn zum Kauf verfügbar zu machen. Außerdem kannst du über den Endpunkt monetization.subscriptions.basePlans.offers Angebote erstellen und verwalten.

Produktupdates

Mit den folgenden Methoden können Sie Ihre vorhandenen Produkte effizient ändern und dafür sorgen, dass Ihre Angebote Ihren neuesten Anpassungen entsprechen.

Einmalige Produkte aktualisieren

Es gibt drei Methoden, mit denen Sie vorhandene Einmalprodukte aktualisieren können.

  • inappproducts.patch: Mit dem Patch-Endpunkt können Sie eine Ressource teilweise aktualisieren. Sie können also bestimmte Felder aktualisieren, die Sie im Anfragetext angeben. Der Patch-Endpunkt wird in der Regel verwendet, wenn nur einige Felder einer Ressource aktualisiert werden müssen.
  • inappproducts.update: Mit dem Update-Endpunkt wird eine Ressource vollständig aktualisiert. Das bedeutet, dass Sie das gesamte Ressourcenobjekt im Anfragetext senden müssen. Der Endpunkt „update“ wird in der Regel verwendet, wenn alle Felder in einer Ressource aktualisiert werden müssen. Wenn der Parameter allowMissing auf true gesetzt ist und die angegebene Produkt-ID noch nicht vorhanden ist, wird das Produkt vom Endpunkt eingefügt, anstatt dass ein Fehler auftritt.
  • inappproducts.batchUpdate: Dies ist eine Batchversion des Update-Endpunkts, mit der Sie mehrere Produkte mit einer einzigen Abfrage ändern können. Verwenden Sie es zusammen mit dem Feld latencyTolerance, das auf PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT festgelegt ist, um einen höheren Durchsatz zu erzielen.

Aboprodukte aktualisieren

Mit der Methode monetization.subscriptions.patch können Sie vorhandene Abos aktualisieren. Für diese Methode sind die folgenden erforderlichen Parameter erforderlich:

  • packageName: Der Paketname der App, zu der das Abo gehört.
  • productId: Die eindeutige Produkt-ID des Abos.
  • regionsVersion: Die Version der Regionskonfiguration.

Sofern Sie kein neues Abo mit dem Parameter allowMissing erstellen, müssen Sie den Parameter updateMask angeben. Dieser Parameter ist eine durch Kommas getrennte Liste der Felder, die Sie aktualisieren möchten.

Wenn Sie beispielsweise nur einen Eintrag für ein Aboprodukt aktualisieren möchten, geben Sie das Feld listings für den Parameter updateMask an.

Mit monetization.subscriptions.batchUpdate können Sie mehrere Abos gleichzeitig aktualisieren. Verwenden Sie es zusammen mit dem Feld latencyTolerance, das auf PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT festgelegt ist, um einen höheren Durchsatz zu erzielen.

Verwende den Endpunkt monetization.subscriptions.basePlans, um Basis-Abos zu aktivieren, zu deaktivieren, zu löschen oder Abonnenten zu den neuesten Preisversionen für Basis-Abos zu migrieren.

Außerdem kannst du die Angebote deiner Basistarife mit der Methode monetization.subscriptions.basePlans.offers.patch aktualisieren.

Katalogabgleich

Unabhängig davon, ob Sie Ihren Google Play-Katalog jedes Mal aktualisieren, wenn sich der Katalog Ihres Backends ändert, oder regelmäßig, kann es bei einem Katalogverwaltungssystem oder einer Datenbank außerhalb des Google Play-Katalogs zu Abweichungen von der Konfiguration Ihres App-Katalogs bei Google Play kommen. Das kann an manuellen Katalogänderungen in der Console, einem Ausfall Ihres Katalogverwaltungssystems oder dem Verlust Ihrer neuesten Daten liegen.

Sie können einen Katalogabgleichsprozess erstellen, um ein längeres Zeitraum für Abweichungen zu vermeiden.

Überlegungen zum Diff-System

Wir empfehlen, ein Diff-System zu erstellen, um Inkonsistenzen zu erkennen und die beiden Systeme abzugleichen. Beachten Sie beim Erstellen eines Diff-Systems, mit dem Sie Ihre Kataloge synchronisieren können, Folgendes:

  • Datenmodelle verstehen:Im ersten Schritt müssen Sie die Datenmodelle des Entwickler-CMS und der Google Play Developer API verstehen. Dazu gehört auch, die verschiedenen Datentypen zu kennen, die in den einzelnen Systemen gespeichert sind, und wie die verschiedenen Datenelemente aufeinander abgestimmt sind.
  • Differenzregeln definieren:Nachdem Sie die Datenmodelle verstanden haben, müssen Sie die Differenzregeln definieren. Diese Regeln bestimmen, wie die Daten in den beiden Systemen verglichen werden. So können Sie beispielsweise Produkt-IDs abgleichen und wichtige Attribute des Abos und der zugehörigen Basistarife und Angebote vergleichen.
  • Diff-Algorithmus implementieren:Nachdem Sie die Diff-Regeln definiert haben, müssen Sie den Diff-Algorithmus implementieren. Dieser Algorithmus nimmt die Daten aus den beiden Systemen und vergleicht sie anhand der von Ihnen definierten Regeln. Sie können die Katalogdaten von Google Play mit den Methoden inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list und monetization.subscriptions.batchGet abrufen.
  • Diff-Berichte erstellen:Der Diff-Algorithmus generiert einen Diff-Bericht. In diesem Bericht werden die Unterschiede zwischen den beiden Systemen angezeigt.
  • Unterschiede beheben:Nachdem Sie den Differenzbericht erstellt haben, müssen Sie die Unterschiede beheben. Je nachdem, wie Sie Ihren Katalog normalerweise aktualisieren, müssen Sie möglicherweise die Daten in Ihrem CMS oder die Daten auf Google Play-Seite mithilfe der Endpunkte zur Katalogverwaltung der Developer API aktualisieren. Verwenden Sie die Aktualisierungsendpunkte wie im Abschnitt zu Produktupdates beschrieben, um nicht synchronisierte Produkte abzugleichen.

Einstellung von Produkten

Die Google Play Developer API bietet Entwicklern mehrere Methoden, um ihre Produkte einzustellen: inappproducts.delete und inappproducts.batchDelete für Einmalkaufprodukte und monetization.subscriptions.delete für Abos. Die Einstellung eines Produkts kann in verschiedenen Fällen erforderlich sein, z. B.:

  • Er wurde versehentlich erstellt.
  • Einstellung einer Funktion oder eines Dienstes

Wir empfehlen, die Einstellung von Produkten in Ihre Katalogverwaltungsstrategie einzubeziehen.

Einmalkaufprodukte werden eingestellt

Wenn Sie einmalige Produkte mit der Google Play Developer API löschen möchten, müssen Sie die Methode inappproducts.delete oder inappproducts.batchDelete verwenden.

Aboprodukte einstellen

Sie können Abos mit der Methode monetization.subscriptions.delete löschen. Ein Abo kann nicht entfernt werden, wenn mindestens ein Basis-Abo aktiviert wurde.