Trasforma le email in fatturato con Brew.
Eventi di acquisti in-app + abbonamenti
Collega RevenueCat per far partire email in linea con il tuo brand quando qualcuno acquista, rinnova, disdice o ha un problema di fatturazione nella tua app. Brew supporta 11 eventi del ciclo di vita di RevenueCat, e lo stesso flusso può servire gli abbonati di App Store, Google Play, Amazon, Stripe e Web Billing.
RevenueCat e gli store restano responsabili di acquisti, rinnovi, rimborsi ed entitlement. Brew crea e invia le email.
L’evento CANCELLATION può indicare un abbonamento disdetto o un rimborso e, da solo, non significa che l’accesso sia terminato. L’evento che indica la fine dell’accesso è EXPIRATION. L’evento SUBSCRIPTION_PAUSED si limita a programmare una pausa futura.
Usa CANCELLATION per le email di riattivazione o i sondaggi di uscita, ed EXPIRATION per tutto ciò che presuppone che l’accesso sia terminato. Un evento UNCANCELLATION non interrompe un’esecuzione per la disdetta già avviata, quindi controlla revenuecat_subscription_status in una condizione prima di ogni email successiva.
Filtra su environment per tenere gli eventi SANDBOX fuori dalle automazioni attive.
Brew supporta questi 11 tipi di evento:
Brew legge il destinatario prima di tutto dall’attributo dell’abbonato $email, poi, in alternativa, accetta un ID utente dell’app, un ID utente originale dell’app o un alias, purché abbia la forma di un indirizzo email. Gli alias di RevenueCat sono lo storico degli ID utente dell’app, quindi imposta $email in modo esplicito invece di affidarti agli alias. Se nessuno di questi campi contiene un indirizzo reale, Brew registra l’evento come non risolto, non crea alcun contatto e non avvia alcuna automazione.
Ogni evento verificato con un indirizzo email reale crea o aggiorna un contatto di Brew, abbinato in base all’email, che un’automazione usi o meno l’evento. Quando i dati sono presenti, Brew imposta revenuecat_app_user_id, revenuecat_store e revenuecat_environment.
Gli eventi del ciclo di vita impostano revenuecat_subscription_status su active, cancelled, expired, billing_issue o pause_scheduled. Brew salva anche revenuecat_product_id, revenuecat_cancel_reason, revenuecat_expiration_reason, revenuecat_last_purchase_at e revenuecat_pending_product_id, quando l’evento li fornisce.
Per i merge tag, usa lo schema del payload dichiarato dall’evento selezionato. Ogni evento include email, productId, priceUsd, pricePurchaseCurrency, currency, store, environment e createdAt, quando presenti. Il campo priceUsd è il prezzo in USD, mentre pricePurchaseCurrency è il prezzo nella valuta indicata da currency. I payload di RevenueCat non forniscono a Brew né il nome né il cognome.
Il campo store arriva così come lo invia RevenueCat, ad esempio APP_STORE o PLAY_STORE, e RevenueCat può aggiungere nuovi valori. Imposta le condizioni sui valori che ti interessano.
Un acquisto non costituisce un consenso all’email di marketing. Raccogli il consenso a parte e verificalo prima degli invii promozionali.
RevenueCat invia TRANSFER con gli ID utente dell’app ma senza l’email del destinatario. Brew lo registra come non risolto e non avvia alcuna automazione.
Ricevere un evento e inviare un’email sono passaggi separati. Verifica che un’automazione corrispondente sia attiva, poi controlla i suoi filtri, la cronologia delle esecuzioni, l’idoneità del destinatario e il dominio di invio. Una consegna TEST non avvia mai un’automazione. Quando un destinatario non è risolto, controlla prima $email; Brew accetta anche ID utente dell’app, ID utente originali dell’app e alias, purché abbiano la forma di un indirizzo email.
