# SaaSのトライアル転換メール：製品イベントでシーケンスを作る

正規URL：https://brew.new/ja/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
執筆：Thomas Park
公開日：2026-09-26
更新日：2026-09-29

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

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

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

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

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

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

| メッセージ | 役に立つタイミング | 送信時点の対象条件 |
| --- | --- | --- |
| ウェルカム | 登録後、またはメールアドレスの確認後 | アカウントが存在し、このメッセージを受け取ってよい |
| セットアップのサポート | 約2日後（製品に合わせて調整） | まだアクティベーションしていない |
| 次に役立つ行動 | アクティベーション後 | アクティベーション済みで、その行動をまだ完了していない |
| トライアル終了 | 実際のトライアル期限の前 | トライアルがまだ有効で、アカウントが有料になっていない |
| 最後の様子伺い | トライアル終了後（適切な場合） | まだ支払いがなく、引き続き対象で、マーケティングメールの受信も許諾している |

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

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

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

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

Brew の外にある事実については、アプリケーションでジョブをスケジュールします。予定の時刻になったら、現在のアカウントや請求書を読み取り、受信者がまだ対象である場合にだけ、別の Brew のカスタムイベントを送信します。その新しいイベントには、パーソナライズに必要な現在のデータを含めましょう。

たとえば、アプリケーション側でスケジュールするリマインダーは、次のように動きます。

```text
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と、そのトリガーで宣言されたスキーマを使います。[オートメーションのセットアップガイド](https://docs.brew.new/create-emails/build-an-automation)と[型付きのペイロード定義](https://docs.brew.new/api-reference/guides/typed-payload-contracts)に従ってください。イベントの送信を再試行する場合は、ドキュメントに記載された冪等性の仕組みを使います。

## Stripe が管理する事実には Stripe を使う

トライアルを Stripe で管理しているなら、そのサブスクリプションのイベントから請求の状況がわかります。[Stripe 連携](/ja/browse/integrations/stripe)では、`customer.subscription.trial_will_end` を含む、対応しているイベントトリガーを利用できます。製品のアクティベーションは、その情報を別途送信しない限り、引き続きアプリケーションが管理します。

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

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

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

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

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

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

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