トライアル転換のメールは、ユーザーがこれまでに何をしたかに応じた内容であるべきです。まだプロジェクトを作成していない人には、セットアップのサポートが必要です。製品を毎日使っている人には、有料プランについてのわかりやすい説明が必要です。2人に同じカウントダウンを送ると、この違いを見落としてしまいます。

このガイドでは、シーケンスの設計と、各メールを誰に送るべきかを判断するアプリケーションのロジックを、分けて考えます。

アクティベーションのイベントを選ぶ

ユーザーが、製品で最初の役に立つ成果にたどり着いたことを示す行動を1つ選びます。プロジェクトの作成、インポートの完了、チームメンバーの招待など、バックエンドで記録できるくらい具体的なものにしましょう。ページの閲覧だけでは、ほとんどの場合不十分です。

登録日時、トライアルの終了日、アクティベーション、支払い状況は、それらの事実を管理しているシステムに記録します。メール配信プラットフォームのコンタクトフィールドは同期されたデータとして扱い、以前に始まったフローが最新の状態を読み取っている証拠とはみなさないでください。

各メッセージの役割を1つに絞る

これらのタイミングはテストの出発点であり、効果が実証された最適な間隔ではありません。実際のトライアルの期限と、その後どうなるかを明記しましょう。希少性をでっち上げたり、支払い方法が登録されていないのに請求が発生するかのようにほのめかしたりしてはいけません。

対象条件のチェックに使う情報源を選ぶ

Brew のイベントトリガー型のフローでは、payload.activated は元のイベントを読み取ります。一方、contact.activated は、「フィルター」ノードや条件分岐ノードが実行された時点での、受信者の現在の Brew のコンタクトフィールドを読み取ります。アクティベーション後にセットアップのリマインダーをスキップするには、その真偽値のフィールドを宣言し、製品から同期し続けて、該当する各「待機」の後に contact.activated equals false をチェックします。値がないことと false は同じではないので、別途テストしましょう。

これらの読み取りで使われるのは Brew に保存されたコンタクトで、自社のアプリケーションのデータベースや、Stripe へのリアルタイムのリクエストではありません。アクティベーションや支払いのイベントを受け取っても、以前に始まった実行が自動的にキャンセルされることはありません。状態に左右される各送信の前に、フローのグラフに条件を置く必要があります。

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 連携では、customer.subscription.trial_will_end を含む、対応しているイベントトリガーを利用できます。製品のアクティベーションは、その情報を別途送信しない限り、引き続きアプリケーションが管理します。

後で送る支払い関連のリマインダーでは、Stripe の現在のレコードを確認します。カードの更新が成功しても、請求書が支払われた証拠にはなりません。Stripe 自体が送るメールと調整し、顧客には目的ごとに1通の通知が届くようにしましょう。

対象条件のルールを決めてから、メールを書く

受信者の実際の状況から書き始めます。役に立つ行動を1つ説明し、そこへ直接リンクしましょう。セットアップのメールなら、短い例と返信先のアドレスを示せます。有料プランのメールでは、関係する上限や機能と実際の価格を説明し、最新の料金ページへのリンクを添えましょう。

マーケティングメールへの同意、配信停止の動作、ドメインの用途を、メッセージの内容と合わせておきましょう。トライアルに登録したからといって、関係のない販促メールを送ってよいことにはなりません。

終了条件が機能することを確かめる

コンタクトが各対象条件のチェックより前にアクティベーションしたり支払ったりした場合に、何が起きるかをテストします。コンタクトの条件を使う場合は、待機中に該当する Brew のフィールドを更新し、リマインダーがスキップされることを確認します。アプリケーション側でスケジュールするチェックの場合は、対象外のアカウントでリマインダーのイベントが発生しないことを確認します。再試行、トライアルの延長、アカウントの削除、配信停止、フィールドの欠落もテストしましょう。アプリケーションのログと Brew の実行履歴の両方を確認します。

アクティベーションと有料プランへの転換は製品のデータで、配信の失敗はメール配信プラットフォームで評価します。開封率だけでは、シーケンスがトライアルユーザーの役に立ったかどうかはわかりません。例についてはウェルカムシーケンスの設計を、実装の役割分担についてはMCPとREST APIの比較ガイドをご覧ください。