Trasforma le email in fatturato con Brew.
Trigger da eventi di autenticazione
Collega Supabase per far partire email in linea con il tuo brand quando qualcuno si registra, conferma la propria email, cambia la password o riceve un ban. Uno script di configurazione aggiunge un trigger alla tua tabella auth.users e Brew trasforma ogni modifica in uno dei 12 trigger delle automazioni.
Supabase Auth resta responsabile di accesso, link di conferma, magic link e reimpostazione della password. Brew crea e invia le email che seguono queste modifiche.
L’evento auth.user.signed_in scatta quando cambia last_sign_in_at. Anche il rinnovo dei token di Supabase modifica quella colonna, quindi l’evento può scattare più volte mentre un utente resta connesso. Non dimostra che qualcuno sia tornato dopo una lunga assenza.
È anche l’evento derivato con la priorità più bassa. Quando lo stesso aggiornamento conferma un’email o converte un utente anonimo, Brew emette quell’evento al posto di auth.user.signed_in.
Per un follow-up con gli utenti inattivi, stabilisci l’inattività nella tua applicazione in base ai suoi dati di attività. Invia a Brew un evento personalizzato separato solo per gli utenti idonei, e lascia che un’automazione attiva invii il follow-up a partire da quell’evento.
Testa entrambi i percorsi: un utente inattivo riceve il follow-up; un utente che è stato attivo prima della verifica no.
Gli eventi auth.user.created, auth.user.updated e auth.user.deleted provengono da inserimenti, aggiornamenti ed eliminazioni su auth.users. Brew ricava gli altri eventi da un aggiornamento, confrontando la riga vecchia con quella nuova.
Un aggiornamento produce un solo evento. Quando cambiano più colonne insieme, vince la prima corrispondenza in quest’ordine: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Un aggiornamento che non corrisponde a nessuno di questi arriva come auth.user.updated.
Brew supporta questi 12 tipi di evento:
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 nome, cognome, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url e supabase_provider.
Alcuni eventi impostano anche campi sul ciclo di vita dell’account. Il campo supabase_account_status diventa active, invited, banned o deleted. I campi supabase_email_verified_at, supabase_phone_verified_at e supabase_last_sign_in_at provengono dai corrispondenti eventi di conferma e di accesso.
Per i merge tag, usa lo schema del payload dichiarato dall’evento selezionato. Ogni evento include email e, quando presenti, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt ed emailConfirmedAt. Nomi e avatar provengono da raw_user_meta_data, con valori di riserva per le registrazioni tramite OAuth. I tre timestamp sono in secondi Unix.
Gli eventi derivati aggiungono previousValue, newValue o entrambi, con il valore vecchio e quello nuovo della colonna in formato testo. L’evento auth.user.password_changed non ha né l’uno né l’altro. Il campo provider indica il metodo di registrazione, come email, google o github, così puoi indirizzare i flussi di benvenuto in base a come qualcuno si è registrato.
L’ID utente di Supabase non è un merge tag. Brew lo salva sul contatto come supabase_user_id, per i filtri e la segmentazione.
Un account Supabase non costituisce un consenso all’email di marketing. Raccogli il consenso al momento della registrazione e verificalo prima degli invii promozionali.
No. Supabase Auth continua a inviare link di conferma, magic link, inviti e reimpostazioni della password tramite la propria configurazione email, ad esempio un SMTP personalizzato. Brew avvia le automazioni dopo che queste modifiche arrivano in auth.users. Supabase consiglia domini di invio separati per le email di autenticazione e per quelle di marketing.
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. Un evento relativo a un utente senza indirizzo email, ad esempio un utente anonimo che non ne ha ancora aggiunto uno, non crea alcun contatto e non avvia alcuna automazione.
