RevenueCat-Abonnements: 16 Grenzfälle und schlaflose Nächte

Wichtige Punkte: In-App-Abonnements mit RevenueCat zu implementieren, scheint einfach: drei Stufen, ein SDK. In Wirklichkeit sind es 16 Grenzfälle bei Planänderungen, französische gesetzliche Verpflichtungen zur Anzeige von Preisen inklusive Steuern und ein Singleton PurchaseService, der die Wiederherstellung von Käufen in Echtzeit verwalten muss. Hier ist alles, was die Dokumentation nicht sagt.

Als ich beschloss, TAMSIV zu monetarisieren, war die Wahl von RevenueCat naheliegend. Sie kümmern sich um die Komplexität der Stores für dich – Google Play Receipts, Servervalidierung, Abonnement-Tracking. Zumindest in der Theorie.

In der Praxis habe ich drei Wochen mit der Implementierung verbracht. Nicht wegen RevenueCat selbst (das SDK ist gut gemacht), sondern wegen all der Grenzfälle, die niemand in den Tutorials erwähnt. Hier ist der vollständige Erfahrungsbericht.

Wie strukturiert man die Abonnementstufen einer KI-App?

TAMSIV bietet drei Pläne an:

• Free — Zugang zu grundlegenden Funktionen mit täglichen Limits. Genug, um die App kennenzulernen, nicht genug für intensive Nutzung.
• Pro — Alles freigeschaltet: KI-Bildgenerierung, Deepgram Cloud STT (besser als nativ in lauten Umgebungen), unbegrenzte Memos, alle TTS-Stimmen.
• Team — Die komplette Kollaborationsschicht: hierarchische Gruppen auf 6 Ebenen, Zuweisungen, Gruppen-Checklisten, erweiterte Berechtigungen.

Die Wahl von drei Stufen ist nicht willkürlich. Studien zeigen, dass drei Optionen die Konversion maximieren – der Ankereffekt drängt Benutzer zum mittleren Plan. Free zieht an, Pro konvertiert, Team monetarisiert Teams.

Die Datei planLimits.ts

Auf Code-Seite zentralisiert eine Datei config/planLimits.ts alle Feature Gates. Jede Funktion prüft den aktiven Plan, bevor sie ausgeführt wird:

// Vereinfachtes Beispiel
const PLAN_LIMITS = {
  free:  { dailyVoiceTasks: 5,  aiImages: 0,  cloudSTT: false },
  pro:   { dailyVoiceTasks: -1, aiImages: 20, cloudSTT: true  },
  team:  { dailyVoiceTasks: -1, aiImages: 50, cloudSTT: true  },
};

Diese einzelne Datei ist die Quelle der Wahrheit. Keine verstreuten if (plan === 'pro')-Bedingungen im Code – alles läuft über die konfigurierten Limits. Wenn ich einen Plan ändere, berühre ich nur eine Datei.

Was sind die 16 Grenzfälle bei Planänderungen?

Hier wird es zum Albtraum. Ein Benutzer kann:

• Upgraden: Free → Pro, Free → Team, Pro → Team
• Downgraden: Team → Pro, Team → Free, Pro → Free
• Periode ändern: Monatlich → Jährlich, Jährlich → Monatlich
• Beides kombinieren: Upgrade + Periodenänderung
• Kündigen: Mit Zugang bis zum Ende der Periode
• Reaktivieren: Vor oder nach Ablauf
• Wiederherstellen: Auf einem neuen Telefon

Ich habe 16 verschiedene Fälle gezählt. Für jeden muss Folgendes verwaltet werden:

1. Der Aktivierungszeitpunkt: Ein Upgrade wird sofort wirksam. Ein Downgrade wird auf das Ende der aktuellen Periode verschoben.
2. Die anteilige Berechnung: Google Play berechnet automatisch den anteiligen Betrag für Upgrades. Aber du musst es in der Benutzeroberfläche korrekt anzeigen.
3. Die Echtzeit-Aktualisierung der Feature Gates: Wenn ein Benutzer ein Upgrade durchführt, müssen die neuen Funktionen sofort freigeschaltet werden, ohne die App neu zu starten.
4. Die korrekte Anzeige: Der richtige Plan, das richtige Ablaufdatum, der richtige Preis, der richtige Status.

Drei Tage Tests, um alles abzudecken. Es ist mühsam, methodisch und absolut unerlässlich. Ein einziger fehlender Fall, und du erhältst eine E-Mail von einem wütenden Benutzer, der für Pro bezahlt hat und immer noch Free ist.

Wie geht man mit den französischen gesetzlichen Verpflichtungen für Abonnements um?

Wenn du in Frankreich verkaufst, schreibt die DGCCRF strenge Regeln vor:

• Preis inklusive Steuern obligatorisch: In Frankreich werden für Verbraucher immer Preise inklusive aller Steuern (TTC - Toutes Taxes Comprises) angezeigt. Die Stores liefern die lokalisierten Preise, aber du musst überprüfen, ob die Anzeige der Gesetzgebung entspricht.
• Erwähnung "Prix TTC": Der Text muss explizit sein.
• Link zu den AGB: Die Allgemeinen Geschäftsbedingungen müssen vom Zahlungsbildschirm aus zugänglich sein.
• Information über das Widerrufsrecht: Für digitale Käufe gilt das Widerrufsrecht unter bestimmten Bedingungen. Du musst den Benutzer darüber informieren.
• Vertragslaufzeit: Der Benutzer muss klar wissen, ob er ein monatliches oder jährliches Abonnement abschließt und wie er es kündigen kann.

Die Nichteinhaltung dieser Regeln birgt das Risiko, dass die App von Google abgelehnt wird oder eine Geldstrafe von der DGCCRF verhängt wird. Die AGB und rechtlichen Hinweise von TAMSIV sind über die Website und über die App zugänglich.

Wie architektoniert man den PurchaseService in React Native?

Alles läuft über einen Singleton PurchaseService. Das ist das Muster, das ich für alle Dienste in TAMSIV verwende – ConversationService, CalendarService, GamificationService, alle folgen dem gleichen Modell (ich spreche darüber in dem Artikel über Refactoring Clean Architecture).

Der PurchaseService macht 4 Dinge:

1. Initialisiert RevenueCat beim Start der App mit dem API-Schlüssel des Projekts.
2. Hört auf Zustandsänderungen: Upgrade, Downgrade, Ablauf, Wiederherstellung. Jede Änderung löst eine Aktualisierung der Feature Gates aus.
3. Exponiert den aktiven Plan über einen Hook: usePurchase() gibt den aktuellen Plan, das Ablaufdatum und die verfügbaren Funktionen zurück.
4. Synchronisiert mit Supabase: Der aktive Plan wird auch in der Datenbank gespeichert, damit das Backend die Berechtigungen überprüfen kann (z. B. die Anzahl der Sprachanfragen für den Free-Plan begrenzen).

Die Wiederherstellung von Käufen

Das ist der kniffligste Fall. Ein Benutzer wechselt das Telefon, installiert die App neu und erwartet, sein Pro-Abonnement wiederzufinden. RevenueCat verwaltet dies über restorePurchases(), aber das Timing ist entscheidend: Die Wiederherstellung kann einige Sekunden dauern, während der der Benutzer im Free-Modus ist. Wenn du diesen Zwischenzustand nicht verwaltest, sieht der Benutzer einen "Upgrade auf Pro"-Bildschirm, obwohl er bereits Pro ist.

Die Lösung: ein expliziter "Lade"-Zustand beim Start, der die Anzeige der Feature Gates blockiert, bis RevenueCat den aktiven Plan bestätigt hat.

Welche Metriken sollte man für Abonnements verfolgen?

RevenueCat bietet ein ausgezeichnetes Dashboard. Die Metriken, die ich täglich verfolge:

• MRR (Monthly Recurring Revenue): Der monatlich wiederkehrende Umsatz. Die Königskennzahl.
• Konversion Free → Pro: Welcher Prozentsatz der kostenlosen Benutzer führt ein Upgrade durch?
• Churn Rate: Wie viele Abonnenten kündigen jeden Monat?
• Trial Conversion: Wenn du eine kostenlose Testphase anbietest, welcher Prozentsatz konvertiert?
• Revenue per User: Der durchschnittliche Umsatz pro aktivem Benutzer.

Diese Metriken speisen das Admin-Dashboard, das ich erstellt habe, um den Projektzustand in Echtzeit zu überwachen.

Welche Fehler sollte man mit RevenueCat vermeiden?

Hier sind die Fallen, in die ich getappt bin:

• Nicht in der Sandbox testen: Google Play hat einen Sandbox-Modus für Käufe. Nutze ihn systematisch. Ein Zahlungsfehler in der Produktion bedeutet eine Rückerstattung + einen verlorenen Benutzer.
• Die Migration bestehender Benutzer vergessen: Wenn du Abonnements zu einer bestehenden App hinzufügst, müssen die aktuellen Benutzer ordnungsgemäß auf den Free-Plan migriert werden. Keine stillschweigenden Downgrades.
• Den Flugmodus nicht verwalten: RevenueCat speichert den aktiven Plan lokal im Cache. Aber wenn der Benutzer während eines Upgrades offline ist, können die Feature Gates desynchronisiert sein. Plane einen Abgleichmechanismus für die Rückkehr online ein.
• Webhooks ignorieren: RevenueCat sendet Webhooks für jedes Ereignis (Kauf, Kündigung, Verlängerung). Das Backend muss sie verarbeiten, um Supabase synchron zu halten.

Wie interagiert das Empfehlungssystem mit Abonnements?

TAMSIV hat ein Empfehlungssystem, das einen kostenlosen Monat Pro oder Team anbietet, wenn ein Benutzer einen Freund einlädt. Das fügt eine weitere Komplexitätsebene hinzu: Der RevenueCat-Promo-Code muss korrekt angewendet werden, der kostenlose Monat muss zur richtigen Zeit beginnen und die Rückkehr zum ursprünglichen Plan muss transparent sein.

Die Interaktion Empfehlung + Abonnement hat 3 der 16 oben genannten Grenzfälle erzeugt. Es ist ein ausgezeichneter Wachstumshebel, erfordert aber eine sorgfältige Implementierung.

FAQ

Warum RevenueCat statt der nativen Google Play Billing API?

Die native Google Play Billing API ist komplex, schlecht dokumentiert und ändert sich regelmäßig. RevenueCat abstrahiert diese Komplexität mit einem sauberen SDK, einem Analyse-Dashboard und plattformübergreifender Unterstützung (Android + iOS). Die Kosten (kostenlos bis 2,5k $ MRR, dann 1% des Umsatzes) sind vernachlässigbar im Vergleich zur eingesparten Entwicklungszeit.

Sollte man eine kostenlose Testphase anbieten?

Das hängt von deinem Modell ab. Für TAMSIV ist der Free-Plan bereits eine dauerhafte Testphase der Grundfunktionen. Eine kostenlose 7-tägige Testphase für Pro wird getestet – erste Daten zeigen eine höhere Konversionsrate, aber auch einen höheren Churn nach der Testphase.

Wie zeigt man Preise in mehreren Währungen an?

Google Play liefert die lokalisierten Preise über die API. RevenueCat zeigt sie in offerings.current.availablePackages an. Du musst die Währungsumrechnung nicht selbst verwalten – der Store zeigt immer den lokalen Preis an. In Frankreich ist das in Euro inklusive Steuern.

Was passiert, wenn Google Play nicht verfügbar ist?

RevenueCat speichert den aktiven Plan auf dem Gerät im Cache. Wenn Google Play vorübergehend nicht verfügbar ist, behält der Benutzer seinen Zugang. Das Risiko ist minimal, da Google Play eine Verfügbarkeit von 99,99% hat. Aber der PurchaseService sieht einen Fallback auf den lokalen Cache vor, falls die API ein Timeout hat.

Wie geht man mit der Mehrwertsteuer für internationale Verkäufe um?

Der Store verwaltet die Mehrwertsteuer, nicht du. Google Play erhebt und überweist die Mehrwertsteuer je nach Land des Käufers. Du erhältst den Nettobetrag. Aber du musst trotzdem die Preise inklusive Steuern in der App anzeigen und die Anzeigeregeln des Benutzerlandes beachten.