Transformez vos e-mails en revenus avec Brew.
Déclencheurs d’authentification
Connectez Supabase pour lancer des e-mails à l’image de votre marque quand quelqu’un s’inscrit, confirme son adresse e-mail, change de mot de passe ou est banni. Un script de configuration ajoute un trigger de base de données à votre table auth.users, et Brew transforme chaque changement en l’un de ses 12 déclencheurs d’automatisation.
Supabase Auth reste responsable de la connexion, des liens de confirmation, des liens magiques et des réinitialisations de mot de passe. Brew crée et envoie les e-mails qui font suite à ces changements.
L’événement auth.user.signed_in est émis quand last_sign_in_at change. Les renouvellements de jeton de Supabase modifient aussi cette colonne : l’événement peut donc être émis à plusieurs reprises tant qu’un utilisateur reste connecté. Il ne prouve pas que quelqu’un est revenu après une longue absence.
C’est aussi l’événement dérivé le moins prioritaire. Quand une même mise à jour confirme une adresse e-mail ou convertit un utilisateur anonyme en compte permanent, Brew émet cet événement plutôt que auth.user.signed_in.
Pour prendre des nouvelles des utilisateurs inactifs, déterminez l’inactivité dans votre application, à partir de ses propres données d’activité. Ne déclenchez un événement personnalisé Brew distinct que pour les utilisateurs concernés, et laissez une automatisation active envoyer l’e-mail de prise de nouvelles à partir de cet événement.
Testez les deux chemins : un utilisateur inactif reçoit l’e-mail de prise de nouvelles ; un utilisateur qui était actif avant la vérification ne le reçoit pas.
Les événements auth.user.created, auth.user.updated et auth.user.deleted proviennent des insertions, mises à jour et suppressions dans auth.users. Brew déduit les autres événements d’une mise à jour, en comparant l’ancienne et la nouvelle ligne.
Une mise à jour produit un seul événement. Quand plusieurs colonnes changent en même temps, la première correspondance l’emporte, dans cet ordre : email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Une mise à jour qui ne correspond à aucun de ces cas arrive sous la forme d’un événement auth.user.updated.
Brew prend en charge les 12 types d’événements suivants :
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 le prénom, le nom, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url et supabase_provider.
Certains événements renseignent aussi des champs de cycle de vie. Le champ supabase_account_status prend la valeur active, invited, banned ou deleted. Les champs supabase_email_verified_at, supabase_phone_verified_at et supabase_last_sign_in_at proviennent des événements de confirmation et de connexion correspondants.
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 et, lorsqu’ils sont présents, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt et emailConfirmedAt. Les noms et les avatars proviennent de raw_user_meta_data, avec des solutions de repli pour les inscriptions via OAuth. Les trois horodatages sont exprimés en secondes Unix.
Les événements dérivés ajoutent previousValue, newValue ou les deux, qui contiennent l’ancienne et la nouvelle valeur de la colonne sous forme de texte. L’événement auth.user.password_changed n’en contient aucun. Le champ provider contient la méthode d’inscription, comme email, google ou github : vous pouvez ainsi orienter vos séquences de bienvenue selon la façon dont la personne s’est inscrite.
L’ID utilisateur Supabase n’est pas une balise de fusion. Brew le stocke sur le contact dans supabase_user_id, pour le filtrage et la segmentation.
Un compte Supabase ne vaut pas consentement aux e-mails marketing. Enregistrez le consentement lors de l’inscription et vérifiez-le avant tout envoi promotionnel.
Non. Supabase Auth envoie toujours les liens de confirmation, les liens magiques, les invitations et les réinitialisations de mot de passe via sa propre configuration e-mail, par exemple un SMTP personnalisé. Brew lance des automatisations une fois que ces changements ont atteint auth.users. Supabase recommande des domaines d’envoi distincts pour les e-mails d’authentification et les e-mails marketing.
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 événement concernant un utilisateur sans adresse e-mail, comme un utilisateur anonyme qui n’en a pas encore ajouté, ne crée aucun contact et ne lance aucune automatisation.
