Transformez vos e-mails en revenus avec Brew.
Achats intégrés et abonnements
Connectez RevenueCat pour lancer des e-mails à l’image de votre marque quand quelqu’un effectue un achat, renouvelle ou résilie son abonnement, ou rencontre un problème de facturation dans votre app. Brew prend en charge 11 événements de cycle de vie RevenueCat, et une même séquence peut servir les abonnés App Store, Google Play, Amazon, Stripe et Web Billing.
RevenueCat et les stores restent responsables des achats, des renouvellements, des remboursements et des droits d’accès (entitlements). Brew crée et envoie les e-mails.
L’événement CANCELLATION peut signaler un abonnement résilié ou un remboursement, et ne signifie pas à lui seul que l’accès a pris fin. C’est l’événement EXPIRATION qui indique la fin de l’accès. L’événement SUBSCRIPTION_PAUSED ne fait que programmer une pause à venir.
Utilisez CANCELLATION pour les e-mails de reconquête ou de questionnaire de départ, et EXPIRATION pour tout ce qui suppose que l’accès a pris fin. Un événement UNCANCELLATION n’arrête pas une exécution déjà lancée par une résiliation : vérifiez donc revenuecat_subscription_status dans une condition avant chaque e-mail suivant.
Filtrez sur environment pour tenir les événements SANDBOX à l’écart de vos automatisations actives.
Brew prend en charge les 11 types d’événements suivants :
Brew lit d’abord le destinataire dans l’attribut d’abonné $email, puis accepte à défaut un app user ID, un original app user ID ou un alias qui a la forme d’une adresse e-mail. Les alias RevenueCat correspondent à l’historique des app user IDs : renseignez donc $email explicitement plutôt que de vous fier à eux. Si aucun de ces champs ne contient d’adresse réelle, Brew enregistre l’événement comme non résolu, ne crée aucun contact et ne lance aucune automatisation.
Chaque événement vérifié qui contient une adresse e-mail réelle crée ou met à jour un contact Brew, identifié par son adresse e-mail, qu’une automatisation utilise l’événement ou non. Lorsque les données sont présentes, Brew renseigne revenuecat_app_user_id, revenuecat_store et revenuecat_environment.
Les événements de cycle de vie donnent à revenuecat_subscription_status la valeur active, cancelled, expired, billing_issue ou pause_scheduled. Brew enregistre aussi revenuecat_product_id, revenuecat_cancel_reason, revenuecat_expiration_reason, revenuecat_last_purchase_at et revenuecat_pending_product_id lorsque l’événement les fournit.
Pour les balises de fusion, utilisez le schéma de payload déclaré par l’événement sélectionné. Tous les événements incluent email, productId, priceUsd, pricePurchaseCurrency, currency, store, environment et createdAt, lorsque ces champs sont présents. Le champ priceUsd contient le prix en USD, et pricePurchaseCurrency le prix dans la devise indiquée par currency. Les payloads RevenueCat ne fournissent à Brew ni prénom ni nom.
Le champ store est transmis tel quel par RevenueCat, par exemple APP_STORE ou PLAY_STORE, et RevenueCat peut ajouter de nouvelles valeurs. Ciblez explicitement les valeurs qui vous intéressent.
Un achat ne vaut pas consentement aux e-mails marketing. Enregistrez le consentement séparément et vérifiez-le avant tout envoi promotionnel.
RevenueCat envoie TRANSFER avec des app user IDs, mais sans adresse e-mail de destinataire. Brew l’enregistre comme non résolu et ne lance aucune automatisation.
Recevoir un événement et envoyer un e-mail sont deux étapes distinctes. Vérifiez qu’une automatisation correspondante est active, puis contrôlez ses filtres, son historique d’exécution, l’éligibilité du destinataire et le domaine d’envoi. Un envoi TEST ne lance jamais d’automatisation. Quand un destinataire n’est pas résolu, vérifiez d’abord $email ; Brew accepte aussi les app user IDs, les original app user IDs et les alias qui ont la forme d’une adresse e-mail.
