Verbinde RevenueCat, um markenkonforme E-Mails auszulösen, wenn jemand in deiner App kauft, verlängert, kündigt oder auf ein Abrechnungsproblem stößt. Brew unterstützt 11 Lifecycle-Events von RevenueCat, und derselbe Flow deckt Abonnenten aus App Store, Google Play, Amazon, Stripe und Web Billing ab.
Für Käufe, Verlängerungen, Rückerstattungen und Entitlements bleiben RevenueCat und die Stores zuständig. Brew erstellt und versendet die E-Mails.
Das Event CANCELLATION kann ein gekündigtes Abo oder eine Rückerstattung bedeuten und heißt für sich genommen nicht, dass der Zugang beendet ist. Das Ende des Zugangs meldet erst EXPIRATION. SUBSCRIPTION_PAUSED plant nur eine künftige Pause.
Nutze CANCELLATION für Rückgewinnungs-E-Mails oder Umfragen zum Kündigungsgrund und EXPIRATION für alles, was voraussetzt, dass der Zugang weg ist. Ein UNCANCELLATION-Event stoppt keine Ausführung, die durch die Kündigung bereits gestartet wurde. Prüfe also vor jeder späteren E-Mail revenuecat_subscription_status in einer Bedingung.
Filtere nach environment, damit SANDBOX-Events nicht in Live-Automatisierungen landen.
Brew unterstützt diese 11 Event-Typen:
Brew liest den Empfänger zuerst aus dem Abonnentenattribut $email und akzeptiert als Fallback eine App-User-ID, eine ursprüngliche App-User-ID oder einen Alias, sofern sie wie eine E-Mail-Adresse aussehen. Aliasse sind bei RevenueCat der Verlauf der App-User-IDs, setze $email also lieber ausdrücklich, statt dich auf sie zu verlassen. Steht in keinem dieser Felder eine echte Adresse, erfasst Brew das Event als nicht aufgelöst, legt keinen Kontakt an und startet keine Automatisierung.
Jedes verifizierte Event mit einer echten E-Mail-Adresse legt einen Brew-Kontakt an oder aktualisiert ihn – zugeordnet über die E-Mail-Adresse und unabhängig davon, ob eine Automatisierung das Event nutzt. Wenn die Daten vorhanden sind, setzt Brew revenuecat_app_user_id, revenuecat_store und revenuecat_environment.
Lifecycle-Events setzen revenuecat_subscription_status auf active, cancelled, expired, billing_issue oder pause_scheduled. Außerdem speichert Brew revenuecat_product_id, revenuecat_cancel_reason, revenuecat_expiration_reason, revenuecat_last_purchase_at und revenuecat_pending_product_id, wenn das Event sie liefert.
Richte dich bei Merge-Tags nach dem deklarierten Payload-Schema des gewählten Events. Jedes Event enthält email, productId, priceUsd, pricePurchaseCurrency, currency, store, environment und createdAt, sofern vorhanden. Das Feld priceUsd ist der Preis in USD, pricePurchaseCurrency der Preis in der Währung, die in currency steht. Vor- und Nachnamen liefern die Payloads von RevenueCat nicht.
Den Wert von store übernimmt Brew unverändert von RevenueCat, etwa APP_STORE oder PLAY_STORE, und RevenueCat kann neue Werte hinzufügen. Filtere gezielt nach den Werten, die für dich wichtig sind.
Ein Kauf begründet keine Einwilligung in Marketing-E-Mails. Halte die Einwilligung separat fest und prüfe sie vor Werbeversänden.
RevenueCat sendet TRANSFER mit App-User-IDs, aber ohne E-Mail-Adresse eines Empfängers. Brew erfasst das Event als nicht aufgelöst und startet keine Automatisierung.
Ein Event zu empfangen und eine E-Mail zu senden, sind getrennte Schritte. Prüfe, ob eine passende Automatisierung live ist, sieh dir dann ihre Filter und ihren Ausführungsverlauf an und prüfe, ob der Empfänger erreichbar und die Versanddomain bereit ist. Eine TEST-Zustellung startet nie eine Automatisierung. Ist ein Empfänger nicht aufgelöst, prüfe zuerst $email; Brew akzeptiert auch App-User-IDs, ursprüngliche App-User-IDs und Aliasse, die wie eine E-Mail-Adresse aussehen.
