이벤트로 시작하는 마케팅 이메일과 트랜잭션 이메일을 이해하세요. 트리거 페이로드, 게시, 시간이 지난 뒤의 대상 여부 확인을 실무 모델로 정리했어요.
트리거 이메일은 실제로 일어난 일에서 시작해요. 가입, 인보이스 결제 실패, 내보내기 완료처럼 시스템이 설명할 수 있는 이벤트예요. 그 이벤트가 메시지의 맥락이 돼요.
메시지가 마케팅인지 트랜잭션인지는 트리거가 정하지 않아요. 메시지의 목적과 수신자와의 관계가 정해요. 영수증과 업그레이드 권유는 같은 제품에서 나오더라도 서로 다른 발송 규칙이 필요할 수 있어요.
행동이나 검증된 조건을 설명하는 이름을 고르세요. 이메일에 필요한 필드를 선언하고, 대표적인 페이로드로 테스트하세요. 어느 서비스가 보냈느냐에 따라 의미가 달라지는 이벤트는 피하세요.
예를 들어 주문 완료 이벤트에는 수신자 주소, 주문 번호, 주문 링크를 담을 수 있어요. 민감하거나 불필요한 데이터는 페이로드에 넣지 마세요. 지원되는 요청 형식은 API 레퍼런스에 나와 있어요.
Brew의 자동화 모델은 트리거를 이메일 발송 같은 단계에 연결해요. 초안을 만들어 검토한 다음, 실서비스 이벤트로 자동화가 실행되길 기대하기 전에 먼저 게시하세요. 가입부터 재참여까지 어떤 라이프사이클 플로우를 먼저 만들지는 AI 이메일 자동화에서 다뤄요.
제품을 홍보하는 웰컴 시퀀스는 마케팅이에요. 주문 영수증이나 사용자가 요청한 계정 보안 메시지는 트랜잭션일 수 있어요. 두 성격이 섞인 메시지는 주된 목적을 따져 봐야 해요. 작은 홍보 문구를 더했다고 해서 법적 판단이 어느 쪽으로든 자동으로 정해지지는 않아요.
꼭 필요한 계정 정보는 찾기 쉽게 두세요. 알맞은 발신 도메인 용도를 쓰고, 구독 상태에 따른 동작을 테스트하세요. 두 메시지의 구분과, 함께 링크된 메일 서비스 제공업체 요건은 트랜잭션 이메일 가이드에서 확인하세요.
마케팅이라면 수신 동의를 확인하고, 수신 거부와 발송 제외 상태를 지키세요. 조건에 맞는 이벤트가 들어왔다고 해서, 페이로드에 주소가 들어 있는 아무에게나 이메일을 보내도 된다는 뜻은 아니에요.
6일이 지나도록 설정을 마치지 않은 체험 사용자에게 리마인더를 보내고 싶다고 해 볼게요. 가입 이벤트는 가입 당시에 사실이었던 것만 알아요. 사용자가 내일 설정을 마칠지는 예측하지 못해요.
Brew에서 6일 차에 확인하려면, ‘필터’ 노드나 조건 분할 노드에서 contact.<name> 형식으로 현재 Brew 연락처 필드를 읽을 수 있어요. 활성화 필드와 구독 필드를 정의해 동기화하고, 대기 단계 뒤에 확인하세요. payload.activated 같은 이벤트 필드에는 여전히 원래 이벤트의 값이 담겨 있어요. 필요한 상태가 Brew 밖에 있다면, 6일 차에 애플리케이션이 확인하게 하고 사용자가 여전히 조건에 맞을 때만 새 리마인더 이벤트를 보내세요.
조건이 ‘구매하지 않음’이나 ‘아직 무료 요금제 사용 중’일 때도 같은 규칙이 적용돼요. 애플리케이션에서 확인하는 패턴은 체험 시퀀스 글에서 설명해요.
이벤트 요청, 자동화 실행, 받은 이메일을 모두 테스트하세요. 필드 누락, 재시도, 비공개 테스트 수신자, 그리고 이후 발송을 막아야 하는 상태 변화도 포함하세요.
연결된 서비스라면 실제 이벤트 이름을 쓰세요. Stripe 연동 페이지에는 Brew가 지원하는 이벤트 목록이 있고, ‘전체 이름 동기화’ 설정이 자동화 게시와 왜 무관한지도 설명해요.
경로가 제대로 작동하면 시퀀스를 이해하기 쉽게 유지하세요. 명확한 이벤트 몇 개와 검토를 마친 메시지로 이뤄진 구성이, 아무도 조건을 설명하지 못하는 긴 자동화 하나보다 관리하기 쉬워요.
