Zamieniaj e-maile w przychody dzięki Brew.
Wyzwalacze zdarzeń uwierzytelniania
Połącz Supabase, aby wysyłać e-maile spójne z marką, gdy ktoś się rejestruje, potwierdza adres e-mail, zmienia hasło lub zostaje zablokowany. Skrypt konfiguracyjny dodaje do Twojej tabeli auth.users wyzwalacz bazy danych, a Brew zamienia każdą zmianę w jeden z 12 wyzwalaczy automatyzacji.
Za logowanie, linki potwierdzające, magiczne linki i resety haseł nadal odpowiada Supabase Auth. Brew tworzy i wysyła e-maile, które następują po tych zmianach.
Zdarzenie auth.user.signed_in pojawia się, gdy zmienia się wartość last_sign_in_at. Tę kolumnę zmieniają też odświeżenia tokenów w Supabase, więc zdarzenie może się powtarzać, dopóki użytkownik pozostaje zalogowany. Nie świadczy ono o tym, że ktoś wrócił po długiej nieobecności.
Ma też najniższy priorytet spośród zdarzeń pochodnych. Gdy ta sama aktualizacja potwierdza adres e-mail lub przenosi anonimowego użytkownika na stałe konto, Brew emituje właśnie to zdarzenie zamiast auth.user.signed_in.
Jeśli chcesz odezwać się do nieaktywnych użytkowników, ustalaj brak aktywności w swojej aplikacji na podstawie jej własnych danych o aktywności. Osobne własne zdarzenie Brew wywołuj tylko dla użytkowników, którzy spełniają warunki, a wiadomość niech wysyła aktywna automatyzacja uruchamiana tym zdarzeniem.
Przetestuj obie ścieżki: nieaktywny użytkownik dostaje wiadomość; użytkownik, który był aktywny przed sprawdzeniem, jej nie dostaje.
Zdarzenia auth.user.created, auth.user.updated i auth.user.deleted pochodzą z operacji wstawiania, aktualizacji i usuwania w tabeli auth.users. Pozostałe zdarzenia Brew wyznacza na podstawie aktualizacji, porównując stary i nowy wiersz.
Jedna aktualizacja daje jedno zdarzenie. Gdy jednocześnie zmienia się kilka kolumn, liczy się pierwsze dopasowanie w tej kolejności: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Aktualizacja, która nie pasuje do żadnego z nich, przychodzi jako zdarzenie auth.user.updated.
Brew obsługuje 12 typów zdarzeń:
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 imię, nazwisko oraz pola supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url i supabase_provider.
Niektóre zdarzenia ustawiają też pola cyklu życia. Pole supabase_account_status przyjmuje wartość active, invited, banned lub deleted. Pola supabase_email_verified_at, supabase_phone_verified_at i supabase_last_sign_in_at pochodzą z odpowiednich zdarzeń potwierdzenia i logowania.
W tagach personalizacji korzystaj ze schematu danych zadeklarowanego dla wybranego zdarzenia. Każde zdarzenie zawiera pole email, a jeśli są dostępne – także pola firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt i emailConfirmedAt. Imiona, nazwiska i awatary pochodzą z raw_user_meta_data, z wartościami zastępczymi dla rejestracji przez OAuth. Te trzy znaczniki czasu są podawane jako czas uniksowy w sekundach.
Zdarzenia pochodne dodają pole previousValue, newValue lub oba – ze starą i nową wartością kolumny w postaci tekstu. Zdarzenie auth.user.password_changed nie ma żadnego z nich. Pole provider zawiera metodę rejestracji, np. email, google lub github, więc możesz dobierać sekwencję powitalną do sposobu rejestracji.
Identyfikator użytkownika Supabase nie jest tagiem personalizacji. Brew zapisuje go w kontakcie jako pole supabase_user_id, aby można było według niego filtrować i segmentować kontakty.
Konto w Supabase nie oznacza zgody na e-maile marketingowe. Zapisuj zgodę przy rejestracji i sprawdzaj ją przed wysyłkami promocyjnymi.
Nie. Linki potwierdzające, magiczne linki, zaproszenia i resety haseł nadal wysyła Supabase Auth przez skonfigurowaną u siebie usługę e-mail, np. własny serwer SMTP. Brew uruchamia automatyzacje, gdy te zmiany trafią do tabeli auth.users. Supabase zaleca osobne domeny wysyłkowe dla e-maili uwierzytelniających i marketingowych.
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 dotyczące użytkownika bez adresu e-mail, np. anonimowego użytkownika, który go jeszcze nie dodał, nie tworzy kontaktu i nie uruchamia automatyzacji.
