체험 전환 이메일은 사용자가 한 행동에 맞춰 반응해야 해요. 아직 프로젝트를 만들지 않은 사람에게는 설정 도움이 필요해요. 제품을 매일 써 온 사람에게는 유료 요금제에 대한 분명한 설명이 필요해요. 두 사람에게 똑같은 카운트다운 이메일을 보내면 이 차이를 놓쳐요.

이 가이드는 시퀀스 설계와, 각 이메일을 누가 받아야 하는지 정하는 애플리케이션 로직을 나눠서 다뤄요.

활성화 이벤트 고르기

사용자가 제품에서 처음으로 쓸모 있는 결과를 얻었음을 보여 주는 행동 하나를 고르세요. 백엔드에서 기록할 수 있을 만큼 구체적이어야 해요. 프로젝트 생성, 가져오기 완료, 팀원 초대 같은 행동이에요. 페이지 조회만으로는 충분하지 않은 경우가 대부분이에요.

가입 시각, 체험 종료일, 활성화 여부, 유료 전환 상태는 그 정보의 원본을 가진 시스템에 기록하세요. 이메일 플랫폼의 연락처 필드는 동기화된 데이터로 다루세요. 앞서 시작된 플로우가 최신 상태를 읽고 있다는 증거로 여기면 안 돼요.

이메일마다 역할 하나씩 주기

이 발송 시점은 테스트를 위한 출발점일 뿐, 측정으로 검증한 최적의 간격이 아니에요. 실제 체험 마감일과 그 이후에 일어날 일을 밝히세요. 있지도 않은 희소성을 지어내거나, 등록된 결제 수단이 없는데 요금이 청구될 것처럼 암시하지 마세요.

대상 여부를 확인할 데이터 출처 고르기

Brew의 이벤트 트리거 플로우에서 ‘필터’ 노드나 조건 분할 노드가 실행될 때, payload.activated 값은 원래 이벤트를 읽고 contact.activated 값은 수신자의 현재 Brew 연락처 필드를 읽어요. 활성화한 사용자에게 설정 리마인더를 건너뛰려면 그 불리언 필드를 선언하고, 제품에서 계속 동기화하고, 관련된 대기 단계마다 그 뒤에서 contact.activated equals false 조건을 확인하세요. 값이 없는 것은 false가 아니니 따로 테스트하세요.

이 조건은 애플리케이션 데이터베이스나 Stripe에 실시간으로 보낸 요청이 아니라, Brew에 저장된 연락처를 읽어요. 활성화 이벤트나 결제 이벤트를 받아도 앞서 시작된 실행이 자동으로 취소되지는 않아요. 그래서 그래프에는 상태에 따라 달라지는 발송마다 그 앞에 조건이 필요해요.

Brew 밖에 있는 정보라면 애플리케이션에서 작업을 예약하세요. 예정된 시점이 되면 현재 계정이나 인보이스를 읽고, 수신자가 여전히 조건에 맞을 때만 별도의 Brew 사용자 지정 이벤트를 보내세요. 개인화에 필요한 현재 데이터는 그 새 이벤트에 담으세요.

예를 들어 애플리케이션이 일정을 관리하는 리마인더는 이렇게 작동해요.

Signup committed → fire welcome event
Reminder job becomes due → read current account
  Already activated or paid → finish without firing an email event
  Still eligible → fire setup-reminder event with current data

Brew가 반환한 실제 트리거 ID와 트리거에 선언된 스키마를 사용하세요. 자동화 설정 가이드와 타입이 지정된 페이로드 정의를 따르세요. 이벤트 전송을 재시도할 때는 문서에 나온 멱등성 방식을 쓰세요.

Stripe가 원본인 정보는 Stripe에서 가져오기

체험을 Stripe가 관리한다면 Stripe의 구독 이벤트가 결제 맥락을 알려 줘요. Stripe 연동은 customer.subscription.trial_will_end 이벤트를 포함해 지원되는 이벤트 트리거를 제공해요. 그래도 제품 활성화 정보는 따로 보내지 않는 한 애플리케이션이 원본이에요.

나중에 보내는 결제 관련 리마인더라면 현재 Stripe 기록을 확인하세요. 카드 정보가 업데이트됐다고 해서 인보이스가 결제됐다는 증거는 아니에요. Stripe가 직접 보내는 이메일과도 조율해서, 고객이 목적마다 안내를 한 번씩만 받게 하세요.

대상 규칙을 정한 뒤에 이메일 쓰기

수신자의 실제 상황에서 시작하세요. 유용한 행동 하나를 설명하고, 그 행동으로 바로 가는 링크를 넣으세요. 설정 이메일에는 짧은 예시와 회신 주소를 넣을 수 있어요. 유료 요금제 이메일에는 관련된 한도나 기능과 실제 가격을 설명하고, 현재 요금 페이지 링크를 넣으세요.

마케팅 수신 동의, 수신 거부 처리, 도메인 용도를 메시지 성격에 맞추세요. 체험에 가입했다고 해서 관련 없는 프로모션 이메일을 보내도 되는 건 아니에요.

종료 조건이 작동하는지 검증하기

대상 여부를 확인하는 시점마다, 그 전에 연락처가 활성화하거나 결제하면 어떻게 되는지 테스트하세요. 연락처 조건이라면 대기 중에 관련 Brew 필드를 업데이트하고 리마인더를 건너뛰는지 확인하세요. 애플리케이션에서 예약한 확인이라면 대상이 아닌 계정에서 리마인더 이벤트가 발생하지 않는지 확인하세요. 재시도, 체험 연장, 계정 삭제, 수신 거부, 필드 누락도 테스트하세요. 애플리케이션 로그와 Brew 실행 기록을 모두 확인하세요.

활성화와 유료 전환은 제품 데이터로, 전달 실패는 이메일 플랫폼으로 평가하세요. 오픈율만으로는 시퀀스가 체험 사용자에게 도움이 됐는지 알 수 없어요. 예시는 웰컴 시퀀스 설계를, 구현 방식을 나누는 기준은 MCP와 REST 비교를 참고하세요.