イベントで送るマーケティングメールとトランザクションメールを、トリガーのペイロード、公開、時間をおいた対象条件の確認という実践的なモデルで解説します。
トリガーメールは、何かが起きたことから始まります。新規登録、請求の失敗、エクスポートの完了など、システムが記述できるイベントです。そのイベントが、メッセージに文脈を与えます。
メッセージがマーケティングかトランザクションかを決めるのは、トリガーではありません。決めるのは、メッセージの目的と受信者との関係です。領収書とアップグレードの売り込みは、同じ製品から生まれることもありますが、それでも異なる送信ルールが必要です。
行動や確認済みの状態を表す名前を選びましょう。メールに必要なフィールドを宣言し、代表的なペイロードでテストします。送信元のサービスによって意味が変わるようなイベントは避けましょう。
たとえば、注文完了のイベントには、受信者のアドレス、注文番号、注文へのリンクを含められます。機密性の高いデータや不要なデータは、ペイロードに含めないでください。対応しているリクエストの形式は、APIリファレンスに記載されています。
Brew のオートメーションでは、トリガーを、メールの送信などのステップにつなげます。下書きを作成して確認したら、オートメーションを公開します。公開するまでは、本番のイベントが届いても実行されません。新規登録から再エンゲージメントまで、どのライフサイクルフローから作るべきかは、AIでメールを自動化するで解説しています。
製品を宣伝するウェルカムシーケンスは、マーケティングです。注文の領収書や、ユーザーが求めたアカウントのセキュリティに関するメッセージは、トランザクションになりえます。両方の要素を含むメッセージには、主な目的による判断が必要です。ちょっとした宣伝を加えたからといって、法的な問いの答えがどちらかに自動的に決まるわけではありません。
アカウントに関する重要な情報は、見つけやすくしておきましょう。送信ドメインには適切な用途を設定し、購読状態に応じた動作をテストします。両者の違いと、リンク先のプロバイダーの要件については、トランザクションメールのガイドをお読みください。
マーケティングメールでは、許諾を確認し、配信停止と配信除外の状態を守りましょう。イベントが一致したからといって、たまたまペイロードにアドレスが含まれている人にメールを送ってよいことにはなりません。
6日たってもセットアップを完了していないトライアルユーザーに、リマインダーを送りたいとします。登録イベントが知っているのは、登録時点で事実だったことです。ユーザーが翌日にセットアップを終えるかどうかは予測できません。
Brew で6日目のチェックを行うには、「フィルター」ノードや条件分岐ノードで、contact.<name> を使って Brew のコンタクトフィールドの現在の値を読み取ります。アクティベーションと購読のフィールドを定義して同期し、待機の後でチェックしましょう。payload.activated のようなイベントのフィールドには、元のイベントの値が残ったままです。必要な状態が Brew の外にある場合は、アプリケーションで6日目にチェックし、ユーザーがまだ対象である場合にだけ、新しいリマインダーのイベントを送信します。
条件が「まだ購入していない」や「まだ無料プランのまま」の場合も、同じルールが当てはまります。アプリケーション側で行うパターンは、トライアルのシーケンスのガイドで説明しています。
イベントのリクエスト、オートメーションの実行、受信したメールをテストします。フィールドの欠落、再試行、自社で管理するテスト用の受信者、そして後の送信を止めるはずの状態の変化も含めましょう。
接続済みのプロバイダーについては、実際のイベント名を使います。Stripe のページには、Brew が対応しているイベントの一覧があり、「氏名を同期」の設定がオートメーションの公開と関係しない理由も説明しています。
経路が機能するようになったら、シーケンスをわかりやすい状態に保ちましょう。明確に定義された少数のイベントと確認済みのメッセージのほうが、誰も条件を説明できない長いオートメーション1つよりも、ずっと保守しやすくなります。
