Zamieniaj e-maile w przychody dzięki Brew.
Zakupy w aplikacji i subskrypcje
Połącz RevenueCat, aby wysyłać e-maile spójne z marką, gdy ktoś w Twojej aplikacji dokonuje zakupu, odnawia lub anuluje subskrypcję albo ma problem z płatnością. Brew obsługuje 11 zdarzeń cyklu życia RevenueCat, a ta sama sekwencja może obsłużyć subskrybentów z App Store, Google Play, Amazon, Stripe i Web Billing.
Za zakupy, odnowienia, zwroty i uprawnienia (entitlements) nadal odpowiadają RevenueCat i sklepy z aplikacjami. Brew tworzy i wysyła e-maile.
Zdarzenie CANCELLATION może dotyczyć anulowanej subskrypcji lub zwrotu i samo w sobie nie oznacza, że dostęp się skończył. O końcu dostępu informuje zdarzenie EXPIRATION. Zdarzenie SUBSCRIPTION_PAUSED tylko planuje przyszłe wstrzymanie.
Zdarzenia CANCELLATION używaj do e-maili reaktywacyjnych lub z ankietą po rezygnacji, a zdarzenia EXPIRATION – do wszystkiego, co zakłada, że dostępu już nie ma. Zdarzenie UNCANCELLATION nie zatrzymuje uruchomienia po anulowaniu, które już trwa, dlatego przed każdym kolejnym e-mailem dodaj warunek sprawdzający pole revenuecat_subscription_status.
Filtruj według pola environment, aby zdarzenia SANDBOX nie trafiały do aktywnych automatyzacji.
Brew obsługuje 11 typów zdarzeń:
Brew najpierw odczytuje odbiorcę z atrybutu subskrybenta $email, a jeśli go nie ma, akceptuje identyfikator użytkownika aplikacji (app user ID), pierwotny identyfikator użytkownika aplikacji (original app user ID) lub alias, o ile mają postać adresu e-mail. Aliasy w RevenueCat to historia identyfikatorów użytkownika aplikacji, więc zamiast na nich polegać, ustaw atrybut $email jawnie. Jeśli w żadnym z tych pól nie ma prawdziwego adresu, Brew zapisuje zdarzenie z nieustalonym odbiorcą, nie tworzy kontaktu i nie uruchamia automatyzacji.
Każde zweryfikowane zdarzenie z prawdziwym adresem e-mail tworzy lub aktualizuje kontakt w Brew dopasowany po adresie e-mail – niezależnie od tego, czy jakaś automatyzacja korzysta z tego zdarzenia. Jeśli zdarzenie zawiera odpowiednie dane, Brew ustawia pola revenuecat_app_user_id, revenuecat_store i revenuecat_environment.
Zdarzenia cyklu życia ustawiają pole revenuecat_subscription_status na active, cancelled, expired, billing_issue lub pause_scheduled. Brew zapisuje też pola revenuecat_product_id, revenuecat_cancel_reason, revenuecat_expiration_reason, revenuecat_last_purchase_at i revenuecat_pending_product_id, jeśli zdarzenie je zawiera.
W tagach personalizacji korzystaj ze schematu danych zadeklarowanego dla wybranego zdarzenia. Każde zdarzenie zawiera pola email, productId, priceUsd, pricePurchaseCurrency, currency, store, environment i createdAt, jeśli są dostępne. Pole priceUsd to cena w USD, a pricePurchaseCurrency – cena w walucie wskazanej w polu currency. Dane zdarzeń RevenueCat nie przekazują Brew imienia ani nazwiska.
Pole store jest przekazywane bez zmian z RevenueCat (np. APP_STORE lub PLAY_STORE), a RevenueCat może dodawać nowe wartości. Uwzględniaj w warunkach konkretne wartości, które Cię interesują.
Zakup nie oznacza zgody na e-maile marketingowe. Zapisuj zgodę osobno i sprawdzaj ją przed wysyłkami promocyjnymi.
RevenueCat wysyła zdarzenie TRANSFER z identyfikatorami użytkowników aplikacji, ale bez adresu e-mail odbiorcy. Brew zapisuje je jako zdarzenie z nieustalonym odbiorcą i nie uruchamia automatyzacji.
Odebranie zdarzenia i wysłanie e-maila to osobne kroki. Upewnij się, że pasująca automatyzacja jest aktywna, a potem przejrzyj jej filtry i historię uruchomień, sprawdź, czy odbiorca może otrzymać wiadomość, i skontroluj domenę wysyłkową. Zdarzenie TEST nigdy nie uruchamia automatyzacji. Gdy nie da się ustalić odbiorcy, najpierw sprawdź atrybut $email; Brew akceptuje też identyfikatory użytkowników aplikacji, pierwotne identyfikatory użytkowników aplikacji i aliasy, jeśli mają postać adresu e-mail.
