Förstå händelsestyrda marknadsförings- och transaktionsmejl, med en praktisk modell för utlösarens nyttolast, publicering och villkor som kontrolleras senare.
Ett triggat mejl börjar med något som har hänt: en registrering, en misslyckad fakturabetalning, en slutförd export eller någon annan händelse som ditt system kan beskriva. Händelsen ger sammanhanget för ett meddelande.
Utlösaren avgör inte om meddelandet är marknadsföring eller transaktionellt. Det gör meddelandets syfte och relationen till mottagaren. Ett kvitto och en uppmaning att uppgradera kan komma från samma produkt och ändå behöva olika regler för utskick.
Välj ett namn som beskriver en handling eller ett verifierat tillstånd. Deklarera de fält som mejlet behöver och testa representativa nyttolaster. Undvik en händelse som betyder olika saker beroende på vilken tjänst som skickade den.
En händelse för en slutförd beställning kan till exempel innehålla mottagarens adress, en beställningsreferens och en länk till beställningen. Håll känslig eller onödig data utanför nyttolasten. API-referensen dokumenterar vilka format på anropen som stöds.
Automatiseringsmodellen i Brew kopplar en utlösare till steg som att skicka ett mejl. Skapa och granska utkastet och publicera sedan automatiseringen innan du räknar med att händelser i produktion ska köra den. E-postautomatisering med AI går igenom vilka livscykelflöden du ska bygga först, från registrering till återaktivering.
En välkomstsekvens som marknadsför en produkt är marknadsföring. Ett orderkvitto eller ett efterfrågat meddelande om kontosäkerhet kan vara transaktionellt. Blandade meddelanden kräver en bedömning av huvudsakligt syfte; att lägga till lite marknadsföring avgör inte automatiskt den juridiska frågan åt något håll.
Gör viktig kontoinformation lätt att hitta. Använd en avsändardomän med rätt syfte och testa hur prenumerationsstatusen hanteras. Läs guiden om transaktionsmejl för skillnaden och de länkade kraven från leverantörerna.
För marknadsföring verifierar du samtycket och respekterar avregistreringar och spärrar. En matchande händelse ger inte rätt att mejla vem som helst vars adress råkar finnas i nyttolasten.
Säg att du vill påminna en användare med provperiod som inte har slutfört konfigurationen efter sex dagar. Registreringshändelsen vet vad som gällde vid registreringen. Den kan inte förutse om användaren blir klar i morgon.
För kontrollen dag sex i Brew kan ett filter eller en villkorsstyrd förgrening läsa aktuella kontaktfält i Brew via contact.<name>. Definiera och synka fälten för aktivering och prenumeration, och kontrollera dem efter väntetiden. Händelsefält som payload.activated innehåller fortfarande de ursprungliga värdena från händelsen. Om den status du behöver finns utanför Brew låter du din applikation kontrollera den dag sex och skicka en ny påminnelsehändelse bara om användaren fortfarande uppfyller villkoren.
Samma regel gäller när villkoret är ”har inte köpt” eller ”har fortfarande gratisplanen”. Artikeln om sekvenser för provperioder förklarar mönstret med kontroller i applikationen.
Testa anropet med händelsen, automatiseringens körning och mejlet som tas emot. Ta med saknade fält, nya försök, privata testmottagare och en statusändring som ska förhindra ett senare utskick.
För anslutna leverantörer använder du deras faktiska händelsenamn. Sidan om Stripe listar de händelser som Brew stöder och förklarar varför inställningen Synka fullständigt namn inte har något med publiceringen av en automatisering att göra.
När kedjan fungerar håller du sekvensen begriplig. Ett litet antal tydliga händelser och granskade meddelanden är lättare att underhålla än en lång automatisering vars villkor ingen kan förklara.
