Jak fungují marketingové a transakční e-maily spouštěné událostmi: praktický model pro payloady spouštěčů, publikování a pozdější kontrolu podmínek.
E-mail spouštěný událostí začíná něčím, co se stalo: registrací, neúspěšnou platbou faktury, dokončeným exportem nebo jinou událostí, kterou tvůj systém umí popsat. Tato událost dává zprávě kontext.
O tom, jestli je zpráva marketingová, nebo transakční, nerozhoduje spouštěč. Rozhoduje její účel a vztah s příjemcem. Účtenka i nabídka upgradu můžou vzejít ze stejného produktu, a přesto pro ně platí jiná pravidla odesílání.
Zvol název, který popisuje akci nebo ověřený stav. Deklaruj pole, která e-mail potřebuje, a otestuj reprezentativní payloady. Vyhni se události, která znamená něco jiného podle toho, která služba ji poslala.
Událost dokončené objednávky může například obsahovat adresu příjemce, číslo objednávky a odkaz na objednávku. Citlivá nebo zbytečná data do payloadu nedávej. Podporované tvary požadavků popisuje referenční dokumentace API.
Model automatizací v Brew propojuje spouštěč s kroky, jako je odeslání e-mailu. Vytvoř a zkontroluj koncept a automatizaci publikuj dřív, než budeš čekat, že ji spustí produkční události. Které sekvence životního cyklu postavit jako první, od registrace po reaktivaci, rozebírá článek Automatizace e-mailů s AI.
Uvítací sekvence, která propaguje produkt, je marketing. Účtenka za objednávku nebo vyžádaná zpráva o zabezpečení účtu můžou být transakční. U smíšených zpráv je potřeba posoudit hlavní účel; přidání drobné propagace samo o sobě právní otázku nerozhodne ani jedním směrem.
Důležité informace o účtu musí být snadno k nalezení. Použij vhodný účel odesílací domény a otestuj, jak se chová odběr. Rozdíl i odkazované požadavky poskytovatelů vysvětluje průvodce transakčními e-maily.
U marketingu ověř souhlas a respektuj odhlášení i blokované adresy. Odpovídající událost tě neopravňuje psát komukoli, jehož adresa se náhodou objeví v payloadu.
Řekněme, že chceš po šesti dnech připomenout uživateli zkušební verze, že nedokončil nastavení. Událost registrace ví, co platilo v okamžiku registrace. Nedokáže předpovědět, jestli uživatel nastavení dokončí zítra.
Pro kontrolu šestý den můžou v Brew uzly Filtr a podmíněné rozdělení číst aktuální pole kontaktu v Brew přes contact.<name>. Nadefinuj a synchronizuj pole pro aktivaci a odběr a po čekání je zkontroluj. Pole události jako payload.activated pořád obsahují původní hodnoty z události. Pokud je potřebný stav uložený mimo Brew, nech ho šestý den zkontrolovat svou aplikaci a novou událost pro připomínku vyslat, jen když uživatel pořád splňuje podmínky.
Stejné pravidlo platí, když podmínka zní „zatím nenakoupil“ nebo „je pořád na bezplatném tarifu“. Postup na straně aplikace vysvětluje článek o sekvenci pro zkušební verze.
Otestuj požadavek s událostí, běh automatizace i doručený e-mail. Zahrň chybějící pole, opakované pokusy, soukromé testovací příjemce a změnu stavu, která má pozdějšímu odeslání zabránit.
U připojených poskytovatelů používej jejich skutečné názvy událostí. Stránka integrace Stripe uvádí události, které Brew podporuje, a vysvětluje, proč nastavení synchronizace jmen nesouvisí s publikováním automatizace.
Až cesta funguje, udržuj sekvenci srozumitelnou. Pár jasně definovaných událostí a zkontrolovaných zpráv se udržuje snáz než jedna dlouhá automatizace, jejíž podmínky nikdo neumí vysvětlit.
