Salesforce Marketing Cloud Journey Builder チケット販売リマインドと離脱フォローの設計

イベント運営やチケット制のサービス提供において、予約から実際の来場、あるいは決済完了までの「顧客の離脱」をいかに防ぐかは収益に直結する課題です。Salesforce Marketing CloudのJourney Builderを活用すれば、顧客一人ひとりの行動やステータスに応じた高度な自動フォローが可能になります。

本記事では、IT実務者の視点から、チケット販売におけるリマインド配信と離脱フォローのシナリオ設計、および実装時に注意すべきデータ構造について詳しく解説します。

1. チケット販売における「リマインド」と「離脱フォロー」の重要性

チケットビジネスには、一般的なECとは異なる特有の「時間軸」が存在します。チケットをカートに入れた直後の「決済完了までの離脱」と、購入後にイベント当日を迎えるまでの「来場忘れ防止」の2点をケアしなければなりません。

• 決済離脱の防止: 申込完了後、銀行振込やコンビニ決済を選択したユーザーが支払いを忘れるケース。
• リマインドによるCX向上: イベント3日前、前日、当日にQRコードチケットを表示するリンクを送信し、入場をスムーズにする。

これらを属人的なオペレーションで回すのは不可能です。Marketing CloudのJourney Builderを使い、Salesforce CRM側のデータ更新をトリガーにして自動走査する仕組みを構築することが標準的な解となります。具体的なアーキテクチャについては、【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』で紹介している全体像を把握しておくと、データ連携のイメージが湧きやすくなります。

2. 前提となるデータ基盤とオブジェクト設計

Journey Builderを駆動させるためには、まず「誰に」「いつ」「何を」送るかを決定するためのデータがMarketing Cloud側に同期されている必要があります。

Salesforce CRMからのデータ同期

Marketing Cloud Connectを利用し、Sales Cloud上の「取引先責任者（Contact）」や、チケット申込情報を管理する「カスタムオブジェクト」を同期データデカテンション（Synchronized Data Extensions）として取り込みます。この際、以下の項目が必須となります。

• Contact Key (Subscriber Key): CRM側のIDと一致させる。
• 申込ステータス: 「予約中」「決済完了」「キャンセル」などの区分。
• イベント開催日時: リマインドの起算点となる日付型フィールド。

Data Extension (DE) の正規化

ジャーニーのエントリーソースとして使用するDEは、可能な限り軽量に保つのが鉄則です。Automation StudioのSQLクエリを用いて、CRMから同期された膨大なデータから「今日から3日後にイベントを控えている未購入者」といったセグメントを抽出し、配信専用のDEに書き込みます。

3. 【設計編】チケット購入リマインドのジャーニー構築

購入者に対するリマインドは、イベントの「満足度」を高め、当日のトラブルを減らすために不可欠です。

「日付属性による待機」の活用

Journey Builderには「Wait by Attribute（属性による待機）」というアクティビティがあります。これを使えば、「イベント開催日の〇日前」までユーザーをジャーニー内で待機させ、指定の時間に一斉に配信を行うことができます。

1. Entry Source: チケット購入が確定したユーザーをDEに投入。
2. Wait by Attribute: 属性として「Event_Date」を指定し、「1 day before at 9:00 AM」のように設定。
3. Email Activity: 前日リマインドメールを配信。

目標（Goal）の設定による最適化

チケット販売においては、ジャーニーの途中でユーザーが「キャンセル」を選択した場合、リマインドを止める必要があります。Journey Builderの「Goal」機能に「Status = Cancelled」という条件を設定しておくことで、条件を満たした瞬間にユーザーをジャーニーから離脱（Exit）させ、不要なメール送付を防ぐことができます。

4. 【設計編】未決済・カゴ落ちユーザーへの離脱フォロー

チケットをカートに入れた、あるいは予約ボタンを押したが決済が完了していない「離脱ユーザー」へのフォローは、コンバージョン率を劇的に改善します。

決定分岐（Decision Split）の設計

申込から24時間経過しても決済フラグが「True」にならないユーザーに対し、フォローメールを送信します。

• Step 1: 申込完了直後にジャーニーへ入場。
• Step 2: 24時間の「Wait（待機）」。
• Step 3: Decision Splitで「Payment_Status = Paid」か判定。
• Step 4: 「False」の場合のみ、支払い忘れ防止のメールを送信。

より高度なトラッキングを行う場合は、Webサイト上の行動データとLINEを連携させる手法も有効です。詳細は広告からLINEミニアプリへ。離脱を最小化しCXを最大化する「摩擦ゼロ」の顧客獲得アーキテクチャを参考にしてください。

5. Marketing Cloud Journey Builder と他手法の比較

チケットフォロー施策を実現する手段は、Journey Builderだけではありません。コストや実装難易度に応じた比較表を以下に示します。

※Marketing Cloudの最新の料金体系については、Salesforce公式の価格ページをご確認ください。エディション（Pro, Corporate, Enterprise）によって利用可能なJourney Builderの機能が異なります。

6. 実務で直面する設定の落とし穴と解消法

現場でよく発生するトラブルとその対策をまとめます。

連絡先（Contact）の再入場設定

「Settings」タブにある「Contact Entry」の設定は非常に重要です。チケット販売の場合、一人のユーザーが「A公演」と「B公演」の両方を購入することがあります。この時、設定を「No re-entry（再入場不可）」にしていると、2つ目の公演のリマインドが飛びません。基本的には「Re-entry anytime（いつでも再入場可能）」を選択しますが、その場合は同じ内容のメールが重複して届かないよう、フィルター条件を厳密に設定する必要があります。

スロットリング（配信流量制限）

数万人規模のイベントで、一斉に「当日リマインド」を配信すると、メールサーバーへの負荷や、リンク先サイトへのアクセス集中が問題になります。Journey Builderの「Throttling」設定を活用し、1時間あたりの配信数を調整することを検討してください。

また、こうした大規模な配信基盤を支えるデータ戦略については、高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例での議論が、アーキテクチャ選定のヒントになります。

7. マルチチャネルへの拡張：メールからLINEへのフォールバック

チケットの決済忘れ防止など、緊急性の高い通知はメールよりもLINEの方が開封率が高い傾向にあります。Marketing Cloudの「LINEチャットメッセージ」アクティビティをJourney Builderに組み込むことで、以下のようなフローが実現可能です。

• 条件: メール送信から6時間経過しても「未開封」である。
• アクション: LINE公式アカウントから「決済期限が迫っています」というプッシュ通知を自動送信。

この設計には、Marketing Cloud Connectだけでなく、LINEのID連携（名寄せ）が完了していることが前提となります。LINEを活用した高度なマーケティングについては、LINE データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャが、具体的な実装の参考になります。

8. まとめ：データドリブンなチケット体験の実現に向けて

Journey Builderを用いたチケット販売の最適化は、単なる「メールの自動送信」に留まりません。CRM上の顧客データ、Web上の行動ログ、そして決済ステータスをリアルタイムに結合し、顧客にとって最も必要なタイミングで情報を届ける「体験のデザイン」そのものです。

設計のポイントは以下の3点に集約されます。

1. データの鮮度: CRMとの同期タイミングを考慮したジャーニー設計を行う。
2. 例外処理: キャンセルやステータス変更時に、即座に配信を停止する「目標」を設定する。
3. チャネルの最適化: メールの開封状況に応じてLINEやプッシュ通知を使い分ける。

まずはスモールステップとして、決済期限の24時間前リマインドから自動化を開始し、徐々にイベント当日の案内や事後のアンケートへとシナリオを拡張していくことを推奨します。