React Native Empfehlungssystem: Vollständiger Leitfaden in 1 Tag

Ich habe 8 Stunden damit verbracht, etwas zu programmieren, das nichts mit dem Produkt selbst zu tun hat. Keine neue Funktion. Keine Fehlerbehebung. Keine Optimierung. Ein komplettes Empfehlungssystem – Android Deep Links, Play Store Install Referrer, gestapelte Belohnungen, Push-Benachrichtigungen in 6 Sprachen – 22 geänderte Dateien, 1324 hinzugefügte Zeilen. An einem Tag. Hier erfährst du, wie ich ein komplettes Empfehlungssystem in React Native aufgebaut habe, welche technischen Fallstricke es zu vermeiden gilt und warum dies die rentabelste Marketinginvestition für einen Solo-Entwickler ist.

Wichtige Erkenntnisse:
- Ein Empfehlungssystem benötigt 3 Erfassungsquellen (Web-Deep-Links, Android App Links, Play Store Install Referrer), um alle Installationsszenarien abzudecken.
- Der Play Store Install Referrer ist die am meisten unterschätzte Quelle: Er erfasst den Code, auch wenn die Installation 3 Tage nach dem Klick erfolgt.
- Gestapelte Belohnungen (Warteschlange für kostenlose Monate) sind motivierender als eine einmalige Belohnung, erhöhen aber die Komplexität mit RevenueCat.
- Die Überprüfung von Android App Links ist fragil: Der SHA256 in assetlinks.json muss exakt dem Signaturschlüssel entsprechen.

Warum ist ein Empfehlungssystem die beste Investition für einen Solo-Entwickler?

Ich entwickle TAMSIV, einen sprachgesteuerten Aufgabenmanager für Android. Solo-Entwickler, über 660 Commits, 6 Monate Arbeit. Ich habe 12 Alpha-Tester im Play Store und ich brauche, dass diese Zahl wächst – organisch.

Die klassischen Optionen zur Nutzerakquise für eine mobile App sind kostspielig:

• Bezahlte Werbung: 1 bis 5 EUR pro Installation auf Google Ads, ohne Garantie auf Bindung.
• ASO (App Store Optimization): langfristig, unsichere Ergebnisse ohne Marketingbudget.
• Influencer: außerhalb des Budgets für einen Solo-Entwickler.

Empfehlungen sind anders. Wie ReferralCandy zeigt, haben durch Empfehlungen gewonnene Nutzer eine um 37 % höhere Bindungsrate und einen um 16 % höheren LTV (Lifetime Value). Der Grund ist einfach: Die Empfehlung eines Freundes ist die zuverlässigste Form des Marketings.

Das Konzept ist einfach: Jeder Nutzer hat einen einzigartigen Empfehlungscode. Du teilst ihn. Wenn sich jemand damit anmeldet, gewinnen beide 1 Monat kostenloses Pro. Und das summiert sich – 10 Empfehlungen = 10 kostenlose Monate, die nacheinander in eine Warteschlange gestellt werden.

Welche 3 unverzichtbaren Erfassungsquellen gibt es für ein Android-Empfehlungssystem?

Der schwierigste Teil ist nicht das Generieren der Codes. Es ist das zuverlässige Erfassen. Auf Android gibt es drei völlig unterschiedliche Installationsszenarien, und jedes erfordert seinen eigenen Erfassungsmechanismus.

Quelle 1: Deep Links über die Website

Wenn jemand tamsiv.com/invite/CODE besucht, leitet Next.js zum Play Store mit dem integrierten Empfehlungscode weiter. Das ist der einfachste Ablauf:

1. Benutzer A teilt seinen Link tamsiv.com/invite/ABC123
2. Benutzer B klickt – Next.js erkennt den Code und leitet zum Play Store weiter
3. Der Code wird über den Parameter referrer der Play Store URL übergeben
4. Die App ruft ihn bei der Installation über die Install Referrer API ab

Quelle 2: Android App Links (direkte Öffnung)

Wenn die App bereits installiert ist, öffnet tamsiv://invite/CODE sie direkt. Dies ist der Fall, wenn ein bestehender Benutzer seinen Code an jemanden weitergibt, der die App bereits hat. Dies erfordert:

• Die Konfiguration der AndroidManifest.xml mit den Intent-Filtern für das Schema tamsiv://
• Eine assetlinks.json-Datei auf der Website zur Domain-Verifizierung durch Google
• Den exakten SHA256 des Signaturschlüssels in der assetlinks-Datei

Hier wird es kompliziert. Die Android App Links-Verifizierung ist fragil. Wenn der SHA256 nicht exakt übereinstimmt – und es gibt einen Unterschied zwischen dem Debug-Schlüssel und dem Produktionsschlüssel – öffnet sich der Link im Browser statt in der App. Keine Fehlermeldung, keine Nachricht. Es funktioniert einfach nicht.

Quelle 3: Play Store Install Referrer

Dies ist die am meisten unterschätzte und mächtigste Quelle. Wenn jemand auf einen Play Store Link mit einem Parameter &referrer=CODE klickt, speichert Android diese Zeichenkette. Selbst wenn die Person die App 3 Tage später installiert, kann der Code immer noch gelesen werden.

Die API Play Install Referrer ermöglicht es, diesen Parameter beim ersten Start abzurufen. Die meisten Tutorials überspringen diese Methode, aber es ist der einzige zuverlässige Weg, Empfehlungen über verzögerte Installationen zu erfassen.

Wie implementiert man gestapelte Belohnungen mit RevenueCat?

Die meisten Empfehlungssysteme geben eine einmalige Belohnung. "Empfehle einen Freund, erhalte einen kostenlosen Monat." Fertig. Keine Motivation für eine zweite Empfehlung.

Ich wollte, dass sich die Belohnungen ansammeln. Jede Empfehlung fügt 30 Tage Pro hinzu, die nach Ablauf der vorherigen in eine Warteschlange gestellt werden. 10 Empfehlungen = 10 kostenlose Monate. Der Anreiz bleibt konstant.

Die technische Komplexität mit RevenueCat

RevenueCat verwaltet die Abonnements von TAMSIV (Free, Pro, Team). Aber RevenueCat hat kein natives Konzept für "gestapelte kostenlose Zeitguthaben". Dies muss serverseitig verwaltet werden:

1. Belohnungstabelle: Jede Empfehlung erstellt einen Eintrag in privat.referral_rewards mit einem Status (pending, active, used, expired).
2. Warteschlange: Wenn eine aktive Belohnung abläuft, wird die nächste in der Warteschlange automatisch über einen Backend-Cronjob aktiviert.
3. RevenueCat-Synchronisation: Das Backend verwendet die RevenueCat-API, um eine promotional entitlement von 30 Tagen zu gewähren, die automatisch verlängert wird, wenn weitere Belohnungen ausstehen.
4. Doppelprüfung: Ein Benutzer kann dieselbe Person nicht zweimal empfehlen. Der Code wird serverseitig überprüft, bevor die Belohnung gewährt wird.

Ein einfaches "gib 1 kostenlosen Monat" ist einfach. Mehrere Belohnungen in eine Warteschlange zu stellen, erfordert die Verwaltung von Start- und Enddaten sowie die Beziehung zu RevenueCat. Das war der Teil, der an diesem Tag die meiste Zeit in Anspruch nahm.

Wie versendet man Empfehlungs-Push-Benachrichtigungen in 6 Sprachen?

Wenn jemand deinen Code verwendet, erhältst du eine Push-Benachrichtigung. In deiner Sprache. Da TAMSIV 6 Sprachen spricht, überprüft das Backend die Sprachpräferenz des Werbers, bevor es die Benachrichtigung über FCM (Firebase Cloud Messaging) versendet.

Die Benachrichtigungsvorlage ist in den 6 Sprachen übersetzt:

• DE: "Dein Freund {name} hat deinen Code verwendet! Du erhältst 1 kostenlosen Pro-Monat."
• EN: "Your friend {name} used your code! You earn 1 free Pro month."
• FR, ES, IT, PT: entsprechende Übersetzungen

Das ist ein Detail, aber es ist die Art von Detail, die das System professionell macht. Eine Empfehlungsbenachrichtigung in einer Sprache zu erhalten, die du nicht verstehst, tötet die Aufregung des Moments. Die Benachrichtigung muss so natürlich sein wie eine Nachricht von einem Freund.

Welche technischen Fehler gilt es bei Android Deep Links zu vermeiden?

Nach diesem Entwicklungstag sind hier die Fallstricke, auf die ich gestoßen bin:

Falle 1: Die Datei assetlinks.json

Die Datei .well-known/assetlinks.json muss genau am richtigen Ort (https://tamsiv.com/.well-known/assetlinks.json) mit dem exakten SHA256 deines Signaturschlüssels bereitgestellt werden. Achtung: Der Debug-Schlüssel und der Produktionsschlüssel haben unterschiedliche SHA256-Werte. Google Play App Signing fügt eine zusätzliche Ebene hinzu – du musst den SHA256 des Upload-Zertifikats verwenden, nicht den des Signing-Zertifikats.

Falle 2: Das Caching von Intent-Filtern

Android speichert Intent-Filter im Cache. Wenn du deine assetlinks.json korrigierst, kann das Gerät stundenlang die alte Überprüfung verwenden. Lösung: Die App vollständig deinstallieren, den Chrome-Cache leeren und neu installieren.

Falle 3: Die Referrer URL-Kodierung

Der Parameter referrer der Play Store URL muss korrekt kodiert sein. Sonderzeichen im Code (wenn du UUIDs verwendest) müssen maskiert werden. Ich habe 30 Minuten wegen eines + in einem Code verloren, der als Leerzeichen dekodiert wurde.

Welche Ergebnisse sind von einem Empfehlungssystem für eine Alpha-App zu erwarten?

Mit 12 Alpha-Testern sind die absoluten Ergebnisse bescheiden. Aber das System ist bereit zu skalieren. Der ROI wird in zwei Dimensionen gemessen:

• Akquisitionskosten: 0 EUR pro über Empfehlung gewonnenen Nutzer (vs. 1-5 EUR bei bezahlter Werbung).
• Qualität der Nutzer: Ein geworbener Nutzer kennt das Konzept bereits durch die Empfehlung – die Bindungsrate ist mechanisch höher.
• Viraler Effekt: Jeder neue Nutzer kann selbst werben – die Grenzkosten der Akquisition tendieren gegen Null.

Für einen Solo-Entwickler ohne Marketingbudget ist dies genau die Art von Mechanismus, die es ermöglicht, ohne Bezahlung zu wachsen. Dies ergänzt die Strategie der Internationalisierung als Akquisitionskanal, die ich implementiert habe.

Wie lautet die technische Bilanz dieses Entwicklungstages?

In Zahlen:

• 22 Dateien geändert (Backend, Frontend, Website, Android-Manifest)
• 1.324 Zeilen hinzugefügt
• 1 Tag konzentrierte Arbeit (8 Stunden)
• 6 Sprachen für Benachrichtigungen unterstützt
• 3 Erfassungsquellen für maximale Abdeckung

Das System berührt alle Schichten der Architektur: das Monorepo (Frontend, Backend, Website), die Datenbank (Supabase), die Benachrichtigungen (FCM) und die Abonnements (RevenueCat). Das macht die Funktion komplex – sie ist nicht in einem Modul isoliert, sondern durchdringt alles.

Häufig gestellte Fragen

Funktioniert der Play Store Install Referrer auf allen Android-Geräten?

Ja, vorausgesetzt, der Play Store ist aktuell (Version 8.3.73+, also >99% der aktiven Geräte). Die API wird von Google über die Bibliothek com.android.installreferrer bereitgestellt. Auf den seltenen Geräten ohne Play Services (Huawei AppGallery) ist ein Fallback erforderlich.

Wie lange wird der Referrer vom Play Store gespeichert?

Laut der Google-Dokumentation wird der Referrer 90 Tage nach dem Klick gespeichert. Das ist mehr als ausreichend, um verzögerte Installationen zu erfassen – selbst wenn der Nutzer mehrere Wochen wartet, bevor er die App installiert.

Wie vermeidet man Missbrauch des Empfehlungssystems (mehrere Konten)?

Drei Schutzmechanismen: (1) Überprüfung der eindeutigen E-Mail-Adresse – eine E-Mail kann nur eine Empfehlungsprämie erhalten, (2) Rate Limiting – maximal 5 Empfehlungen pro Stunde pro Werber, (3) serverseitige Überprüfung – der Code ist gültig und der Geworbene wurde noch nie zuvor geworben. Das globale Rate Limiting-System von TAMSIV schützt vor Missbrauchsversuchen.

Unterstützt RevenueCat nativ Werbeberechtigungen (promotional entitlements)?

Ja, über die REST-API (POST /subscribers/{app_user_id}/entitlements/{entitlement_id}/promotional). Du kannst eine Berechtigung für eine definierte Dauer (in unserem Fall 30 Tage) gewähren. Die Verwaltung der Warteschlange (Stapelung von Belohnungen) muss jedoch serverseitig erfolgen – RevenueCat verwaltet nur die aktive Berechtigung.

Benötigt man ein Backend für ein Empfehlungssystem oder kann man alles clientseitig erledigen?

Ein Backend ist für die Sicherheit unerlässlich. Die gesamte Validierungslogik (gültiger Code, berechtigter Benutzer, Betrugsbekämpfung) muss serverseitig erfolgen. Das Frontend sendet lediglich den Code und empfängt das Ergebnis. Die Codegenerierung, die Zuweisung von Belohnungen und das Senden von Benachrichtigungen erfolgen ausschließlich serverseitig.