Zamieniaj e-maile w przychody dzięki Brew.
Poznaj marketingowe i transakcyjne e-maile wyzwalane zdarzeniami oraz praktyczny model danych zdarzeń, publikacji i sprawdzania warunków z opóźnieniem.
E-mail wyzwalany zaczyna się od czegoś, co się wydarzyło: rejestracji, nieudanej płatności faktury, zakończonego eksportu albo innego zdarzenia, które Twój system potrafi opisać. To zdarzenie daje kontekst dla wiadomości.
Wyzwalacz nie decyduje, czy wiadomość jest marketingowa, czy transakcyjna. Decydują o tym cel wiadomości i relacja z odbiorcą. Potwierdzenie płatności i propozycja ulepszenia planu mogą pochodzić z tego samego produktu, a mimo to wymagać różnych zasad wysyłki.
Wybierz nazwę, która opisuje działanie lub zweryfikowany stan. Zadeklaruj pola, których potrzebuje e-mail, i przetestuj reprezentatywne dane zdarzeń. Unikaj zdarzenia, które znaczy co innego w zależności od tego, która usługa je wysłała.
Na przykład zdarzenie zrealizowanego zamówienia może zawierać adres odbiorcy, numer zamówienia i link do zamówienia. Nie umieszczaj w danych zdarzenia informacji wrażliwych ani zbędnych. Obsługiwane formaty żądań opisuje dokumentacja API.
Model automatyzacji w Brew łączy wyzwalacz z krokami, takimi jak wysłanie e-maila. Utwórz i przejrzyj wersję roboczą, a potem opublikuj automatyzację – dopiero wtedy zdarzenia produkcyjne zaczną ją uruchamiać. Wpis o automatyzacji e-maili z AI podpowiada, które sekwencje cyklu życia zbudować najpierw, od rejestracji po reaktywację.
Sekwencja powitalna, która promuje produkt, to marketing. Potwierdzenie zamówienia albo wiadomość o bezpieczeństwie konta wysłana na prośbę użytkownika mogą być transakcyjne. Wiadomości mieszane wymagają oceny głównego celu; dodanie niewielkiej promocji nie przesądza automatycznie kwestii prawnej ani w jedną, ani w drugą stronę.
Niech najważniejsze informacje o koncie będą łatwe do znalezienia. Używaj domeny wysyłkowej o odpowiednim przeznaczeniu i przetestuj działanie subskrypcji. Różnicę i podlinkowane wymagania dostawców opisuje poradnik o e-mailach transakcyjnych.
W przypadku marketingu sprawdź zgodę i respektuj status wypisania i wykluczenia. Pasujące zdarzenie nie oznacza zgody na wysłanie e-maila każdemu, czyj adres akurat pojawi się w danych zdarzenia.
Załóżmy, że chcesz przypomnieć o konfiguracji użytkownikowi okresu próbnego, który po sześciu dniach wciąż jej nie dokończył. Zdarzenie rejestracji wie, co było prawdą w chwili rejestracji. Nie przewidzi, czy użytkownik skończy konfigurację jutro.
Przy sprawdzeniu w szóstym dniu w Brew krok filtra lub krok podziału warunkowego może odczytać bieżące pola kontaktu w Brew przez contact.<name>. Zdefiniuj i synchronizuj pola aktywacji i subskrypcji, a potem sprawdź je po kroku oczekiwania. Pola zdarzenia, takie jak payload.activated, nadal zawierają pierwotne wartości zdarzenia. Jeśli potrzebny stan znajduje się poza Brew, niech Twoja aplikacja sprawdzi go w szóstym dniu i wywoła nowe zdarzenie przypomnienia tylko wtedy, gdy użytkownik nadal spełnia warunki.
Ta sama zasada obowiązuje, gdy warunek brzmi „brak zakupu” albo „nadal na bezpłatnym planie”. Wzorzec po stronie aplikacji wyjaśnia poradnik o sekwencji e-maili w okresie próbnym.
Przetestuj żądanie ze zdarzeniem, uruchomienie automatyzacji i odebrany e-mail. Uwzględnij brakujące pola, ponowienia, prywatnych odbiorców testowych i zmianę stanu, która powinna zablokować późniejszą wysyłkę.
W przypadku połączonych dostawców używaj ich rzeczywistych nazw zdarzeń. Strona integracji ze Stripe wymienia zdarzenia obsługiwane przez Brew i wyjaśnia, dlaczego ustawienie „Synchronizuj imię i nazwisko” nie ma związku z publikacją automatyzacji.
Gdy ścieżka działa, zadbaj o to, żeby sekwencja pozostała zrozumiała. Niewielki zestaw jednoznacznych zdarzeń i sprawdzonych wiadomości łatwiej utrzymać niż jedną długą automatyzację, której warunków nikt nie potrafi wyjaśnić.
