All articles Analytics Growth Infrastructure Product Updates

Das neue Abonnement Modell und die Übersicht über die Google Play Billing Library 5.0

Kamo Spertsyan

Während der jährlichen I/O-Konferenz hat Google seine neue Hauptversion der Google Play Billing Library vorgestellt. Neben der Abschaffung der klassischen Methoden gab es auch umfangreiche Informationen über die neue Abonnement-Architektur, die die Erstellung, Verwaltung und den Verkauf von In-App-Käufen vereinfachen soll. In diesem Artikel gehe ich auf die Aktualisierungen von Google Play Billing Library 5.0 ein und erläutere die interessantesten davon.

Das neue Abonnement-Modell

Das Google Play Billing System ist das wichtigste Tool, mit dem Sie Ihre App über Abonnements monetarisieren können. Lesen Sie unbedingt diesen Artikel, wenn Sie mit diesem Service noch nicht vertraut sind. Mit der neuesten Version seiner Bibliothek hat Google die Struktur der Definition von Abonnementprodukten geändert. Dies hat zu Änderungen bei der Art und Weise geführt, wie sie in der App verkauft und in Ihrem Backend verwaltet werden.

Mit Google Play Billing Library 5.0. hat Google eine neue Abonnement-Architektur eingeführt und Einheiten wie Basispläne und Angebote hinzugefügt. Lassen Sie uns einen Blick darauf werfen.

Nehmen wir an, Sie haben ein Premium-Abonnement in Ihrer App und bieten Ihren Kunden Wochen-, Monats- und Jahresabonnements an. Vor diesen Updates hätten Sie drei verschiedene Abonnements erstellen müssen – eines für jeden Zeitraum. Dann stellen Sie sich vor, dass Sie Nutzern, die Ihre App verlassen haben, eine kostenlose Testversion anbieten möchten, um sie zurück zu gewinnen. Dann müssten Sie ein weiteres Jahresabonnement mit einer kostenlosen Testversion erstellen.

Dies sind nur zwei der häufigsten Fälle, die dazu führen, dass viele Abonnements mit dem bisherigen Abo-Modell erstellt werden – es könnte noch viele weitere Beispiele geben.

Ab sofort können Sie jedoch alle diese Szenarien mit nur einem Abonnement abwickeln. Google hat ein Abonnementmodell in drei Einheiten unterteilt – das Abonnement selbst, die Basispläne und die Angebote.

Die neue Abonnementeinheit umfasst:

Bezeichner
Titel
Beschreibung
Steuerinformationen

Der Rest der Informationen wird über Basispläne und Angebote eingerichtet.

Ein Basisplan enthält:

Bezeichner
Verlängerungsart (automatische Verlängerung oder Prepaid)
Dauer
Tilgungsfreie Zeit
Preise und Verfügbarkeit für verschiedene Regionen
Einige weniger wichtige Einstellungen

Die gesamte Liste der Details finden Sie in der offiziellen Dokumentation.

Ein Angebot enthält:

Bezeichner
Berechtigungskriterien – eine Option, die festlegt, welche Benutzer auf dieses Angebot zugreifen können (Erstabonnenten, Benutzer, die ein Upgrade von einem anderen Abonnement durchführen, oder vom Entwickler bestimmte Benutzer),
Phasen, einschließlich kostenloser Testversionen und einmaliger oder wiederkehrender Zahlungen (die Verwendung der Phasen ist im Screenshot unten dargestellt)
Preisnachlass – entweder ein fester Betrag oder ein prozentualer oder absoluter Nachlass, abhängig vom Preis des Basisplans

Jedes Abonnement kann einen oder mehrere Basispläne enthalten, die wiederum mehrere Angebote enthalten können (siehe das Schema oben). Für das obige Beispiel können Sie also ein Premium-Abonnement mit drei Basisplänen erstellen – einen pro Zeitraum und ein Angebot mit einer kostenlosen Testversion für den jährlichen Basisplan.

Erwerb neuer Abonnements

Da wir gerade von Code sprechen: In Google Play Billing Library 5.0 ist die Klasse SkuDetails veraltet, ebenso wie jede andere Einheit oder Methode, die Sku in ihrem Namen enthält. Jetzt sollten Sie für diesen Zweck ProductDetails verwenden. ProductDetails enthalten Informationen über ein Abonnement, einschließlich der Basispläne und Angebote.

Davor haben Sie Abonnementdetails wie die folgenden angefordert:

val params = SkuDetailsParams.newBuilder()
    .setType(BillingClient.SkuType.SUBS)
    .setSkusList(listOf("premium"))
    .build()

billingClient.querySkuDetailsAsync(params) { 
        billingResult, skuDetailsList -> // Process the result
}

Jetzt sollten Sie Folgendes tun:

val productList = listOf(
    QueryProductDetailsParams.Product.newBuilder()
        .setProductType(BillingClient.SkuType.SUBS)
        .setProductId("premium")
        .build()
)

val params = QueryProductDetailsParams.newBuilder()
    .setProductList(productList)
    .build()

billingClient.queryProductDetailsAsync(params) {
    billingResult, productDetailsList -> // Process the result
}

Und um den Erwerbsvorgang zu starten, haben Sie die folgenden Konstruktionen verwendet:

val billingFlowParams = BillingFlowParams.newBuilder()
    .setSkuDetails(skuDetails)
    .build()

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

Wohingegen sie jetzt so aussehen sollten wie die folgenden:

// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription.
val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return

val productDetailsParamsList = listOf(
    BillingFlowParams.ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setOfferToken(offerToken)
        .build()
)

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(productDetailsParamsList)

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

Sie können sich auch die Migrationsbeispiele in den offiziellen Migrationsschritten von Google ansehen. In den Beispielen sind ein paar Tippfehler enthalten, die hier korrigiert wurden.

Lassen Sie uns einen Überblick über die Änderungen geben.

Wie ich bereits erwähnt habe, sollten Sie jetzt ProductDetails verwenden, um Abonnementdetails und den Kaufprozess abzufragen. Sie sollten auch einen offerToken in die Parameter des Abrechnungsvorgangs einbeziehen, da jedes ProductDetails mehrere Angebote enthalten kann. Beachten Sie, dass das Array der Angebotsdetails (productDetails.subscriptionOfferDetails) immer die Details des Basisplans enthält (falls ein Basisplan existiert). Selbst wenn Ihr Abonnement also nur einen Basisplan ohne Angebote enthält, wird es dennoch offerTokens zum Kauf enthalten.

Sie werden feststellen, dass der neue Kaufprozess mehrere ProductDetails anstelle von nur einem SkuDetails wie in der vorherigen Version akzeptiert. Wenn Sie jedoch mehr als ein ProductDetails angeben, wird der Prozess mit einem Fehler beendet. Der offizielle Integrationsleitfaden gibt das falsche Beispiel, die Methoden setProductDetails und setOfferToken direkt in der Klasse BillingFlowParams.Builder zu verwenden, aber für diese Zwecke gibt es nur die Methode setProductDetailsParamsList. Es scheint, dass Google vor kurzem beschlossen hat, von einzelnen Produktdetails auf mehrere umzusteigen, mit einer Vision für die Zukunft, wenn Billing mehrere verschiedene Abonnementkäufe auf einmal unterstützt.

Der restliche Ablauf – nämlich die Bearbeitung des Kaufs – bleibt derselbe wie in der Google Play Billing Library 4.0.

Rückwärtskompatibilität von Abonnements

Bis jetzt hört sich alles gut an, aber was ist, wenn Sie nicht sofort migrieren möchten? Google hat sich darum gekümmert.

Obwohl die Google Play Console bereits nur mit dem neuen Abonnementmodell funktioniert, werden alle alten Abonnements automatisch in das neue Format gewandelt, wobei ihre Abwärtskompatibilität erhalten bleibt. Das bedeutet, dass Sie Ihre Abonnements im neuen Format in der Google Console sehen, aber weiterhin mit ihnen arbeiten können, wie Sie es bisher in Ihrer App getan haben.

Sie werden auch feststellen, dass alle alten Abonnements nach der Migration schreibgeschützt sind. Google warnt Sie, dass durch die Bearbeitung der Support der InAppProducts API für dieses Abonnement deaktiviert wird.

Möglicherweise verwenden Sie diese API in Ihrem Backend, um einige Produktdetails abzurufen. Vorsicht: Nachdem Sie das Abonnement editierbar gemacht haben, erhalten Sie von dieser API Fehlermeldungen (wie unten gezeigt), wenn Sie versuchen, umgewandelte Abonnementinformationen abzurufen. Das Gleiche gilt für alle neuen Abonnements, die nach dem 11. Mai erstellt werden.

HTTP code - 422
Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}

Wenn Sie also die InAppProducts API verwenden, sollten Sie ein Upgrade in Betracht ziehen, bevor Sie neue Abonnements erstellen oder alte bearbeiten.

Wenn Sie die neue Abonnement-Benutzeroberfläche in der Google Play Console durchsuchen, finden Sie die Markierung “Abwärtskompatibel” in der Nähe der Abonnement-Basispläne und -angebote. Das bedeutet, dass Sie, wenn Sie diese Abonnements mit den veralteten SkuDetails erwerben (wie in Google Play Billing Library 4.0), kaufen Sie genau dieselben kompatiblen Basispläne/Angebote. Wenn es nur einen kompatiblen Basisplan ohne ein kompatibles Angebot gibt, wird dieser Basisplan gekauft. Wenn sowohl ein kompatibler Basisplan als auch ein kompatibles Angebot verfügbar sind, wird das Angebot gekauft, wenn es für den aktuellen Nutzer in Frage kommt, andernfalls – der Basisplan. Wenn Sie möchten, können Sie einen anderen Basisplan/ein anderes Angebot als abwärtskompatibel auswählen.

Hinweis: Diese Rückwärtskompatibilität bezieht sich auf die Google Play Billing Library, nicht aber auf die InAppProducts API. Wenn Sie, wie bereits erwähnt, neue Funktionen verwenden, z. B. mehrere Basispläne oder Angebote für ein Abonnement oder es einfach von schreibgeschützt in bearbeitbar umwandeln, kann dieses Abonnement für eine App immer noch abwärtskompatibel sein, aber nicht für die API.

Die anderen Updates

Es gab mehrere kleinere Aktualisierungen in der Google Play Billing Library 5.0, die kurz erwähnt werden sollten.

Die Methode queryPurchases, die in der Google Play Billing Library 4.0 veraltet war, wurde entfernt
Keine synchronisierten Anfragen mehr, nur noch queryPurchasesAsync.
launchPriceChangeFlow ist veraltet – der neue empfohlene Preisänderungsprozess erfordert die Bestätigung der Kunden über die Google Play-Abonnementseite. Sie sollten daher Deep Links für die Navigation dort verwenden, anstatt die Methode BillingClient aufzurufen.
Die Methode setIsOfferPersonalized wurde hinzugefügt, um einen personalisierten Preis für EU-Kunden gemäß der Richtlinie über Verbraucherrechte anzugeben. Diese Option fügt am Boden des Google Billing-Kaufbildschirms eine Zeile hinzu, die darauf hinweist, dass ein Preis personalisiert ist.

Das neue Abonnementmodell und die Qonversion

Während wir an der Unterstützung von Google Play Billing Library 5.0 arbeiten, können Sie Qonversion SDK weiterhin für Ihre In-App-Käufe verwenden. Wir verwenden jetzt Google Play Billing Library 4.0, was bedeutet, dass wir nur Abonnements mit rückwärtskompatiblen Basisplänen und Angeboten verwalten können. Sie können nach wie vor Eigenschaften bearbeiten, die im vorherigen Abonnementmodell verfügbar waren, wie z.B. Preis, Karenzzeit, Testdauer usw., und auch neue Abonnements erstellen. Stellen Sie nur sicher, dass Sie danach immer noch mindestens einen abwärtskompatiblen Basisplan und, falls erforderlich, ein abwärtskompatibles Angebot haben. Außerdem benötigen wir für die Konfiguration von Produkten in unserem Product Center nach wie vor eine vollständige Abonnementkennung, keine Basisplan- oder Angebotskennungen.

Wenn Sie Fragen haben, lassen Sie es uns bitte wissen. Wir helfen Ihnen gerne weiter.