トリガーベースのエントリー
カートに追加した瞬間、決済に失敗した瞬間、注文が確定した瞬間――重要な行動が起きたその場でジャーニーを開始します。次のセグメント更新を待つ必要はありません。
その瞬間に、ジャーニーを動かす
ジャーニーは何かが起きたその瞬間に始まってほしいものです。次のセグメント更新のタイミングを待っていては意味がありません。1つの自動化だけが動いているうちは簡単な約束ですが、カゴ落ちフォローの隣で他にも10本のジャーニーが動いている状況では、それぞれが単体では妥当でも足並みが揃わなくなります。「お忘れ物はありませんか」というメッセージも、1時間後の夜間バッチで送られるのと、ユーザーがスマートフォンを置く前にすでに動き出しているのとでは、まったく別のメッセージです。トリガーベースのエントリーは、このギャップを埋める仕組みです。
トリガーベースのエントリーでできること
イベントを1つ選べば、それを発火させた人は保存済みセグメントの次回スキャンを待たず、その場でジャーニーに入ります。
リアルタイムに反応
次回スケジュールスキャンではなく、イベント発火の瞬間にエントリーします。
ペイロードで絞り込み
イベント自身の属性に条件を追加でき、イベント名だけでなくその中身でエントリーを判定できます。
複数セッションを同時に実行
order_id や product_id をキーにした並行実行により、1人のユーザーが複数のセッションを同時に保持できます。
再エントリーを制御
要素ごとに、再発火をブロックするか、セッションを再スタートさせるかを選べます。
| 設定項目 | 選択肢 |
|---|---|
| イベントソース | SDKのpostEvent、REST API、デフォルトのPW_*イベント、カスタムイベント、ジオゾーンへの進入・退出 |
| エントリー条件 | 任意：イベント自身の属性で絞り込み（属性・演算子・値） |
| エントリーする人 | イベントを発火させた本人、またはペイロード内で指定されたユーザー |
| 再エントリー | 許可しない（デフォルト）、または許可してセッションを再スタート |
| 並行実行 | ユーザーごとに1セッションのみ、またはorder_idやproduct_idなどのセッション属性をキーにした複数セッション |
オーディエンスベースのエントリーはスケジュールに沿ってセグメントを再チェックする仕組みです。トリガーベースのエントリーはイベント発火と同じ瞬間に反応し、ユーザーごとに複数セッションを実行できるため、進行中の注文が3件あれば、それぞれが1つに衝突することなく独自のステータスジャーニーを持てます。日本のフードデリバリーや配車マッチングのように、1人のユーザーが複数の注文・予約を同時に抱えやすい業態ほど、この違いが効いてきます。後から届くイベントを正しいセッションへルーティングする役目は、キャンバスの先にあるWait for Triggerのセッション別マッチングが担います。条件・再エントリー制御を含む要素本体は、無料プランから利用できます。
ジャーニービルダーにとっての意味
ジャーニービルダーの価値は、そのエントリーポイント次第で決まります。オーディエンスベースのエントリーは、ニュースレターや休眠ユーザー向けの掘り起こしキャンペーンのような定期配信をカバーします。ビルダーに必要なもう一つの力は、決済が失敗した瞬間やカゴ落ちが起きた瞬間に反応する手段であり、それをカスタマージャーニービルダーに与えているのがトリガーベースのエントリーです。キャンバスの他部分がセグメンテーションや分岐にすでに使っているのと同じイベントカタログを参照するため、扉を開く合図と、その後のフローを動かす合図は同じものになります。
次に何を引き継ぐか
add_to_cartイベントが発火し、カゴ落ちフォローのジャーニーが始まります。続くWait for Trigger要素が、購入完了までユーザーを最大90日間待たせてから、呼び戻しパスへ分岐します。どちらの要素も単体では何も送信しません。両方ともチャネルブロックへ処理を引き継ぐだけで、最初に「誰をフローに入れるか」を決めたのがエントリー要素です。
セッションを開始したイベントは、後の分岐が注文を区別するために必要なキーも同時に運べます。すべて同じカスタマージャーニービルダーキャンバス上で完結します。
イベントとジャーニーは、名前のあるインフラの上で完結
トリガーベースのエントリー要素が読み取るすべてのイベントは、プラットフォームの他機能と同じインフラ上で処理されます。PushwooshはSOC 2 Type IおよびISO 27001:2022認証を取得済みで、GDPRに準拠し、米国とドイツの自社ハードウェア上でBDSG（ドイツ連邦データ保護法）にも準拠して稼働しています。情シス審査で求められる第三者認証やデータ所在地の確認にもそのままお使いいただけます。詳細はデータセーフティページをご覧ください。
使い方
-
エントリー要素を配置
キャンバス上にトリガーベースのエントリー要素を追加し、イベントを選びます。デフォルトのPW_*イベントでも、SDKのpostEventやサーバー呼び出しで送るカスタムイベントでも構いません。
-
エントリーを絞り込み、対象を決める
たとえばadd_to_cartでcart_valueが50を超える場合のように、イベントの属性に条件を追加してエントリーを絞り込み、イベントを発火させた本人が入るか、ペイロード内で指定されたユーザーが入るかを選びます。
-
再エントリーと並行実行を設定
すでにジャーニー内にいる人が再度トリガーを発火できるかどうか、また1人のユーザーがorder_idなどの属性をキーに複数セッションを同時に保持できるかどうかを決めます。
ひとつのイベントを、今すぐ動くジャーニーに変える。
関連製品を見る
1 つのビジュアルツールでキャンペーンを設計し、効率化します。Pushwoosh カスタマージャーニービルダーを使用して、顧客とのコミュニケーション、エンゲージメントの向上、リテンション、コンバージョン、セグメンテーション、実験を行います。
イベントベースのトリガーでエンゲージメントを促進。顧客が行動を起こした瞬間に自動的にキャンペーンを開始し、コンバージョンとリテンションのための完璧な瞬間を捉えます。
最大3分岐・各4イベントのAND/OR条件でユーザーの行動を待ち、最大90日で「Not triggered」分岐へ。注文・配車単位のセッション別マッチングに対応するカスタマージャーニー要素です。
固定期間、時刻指定、日付指定、曜日指定、またはユーザープロフィールの日付を起点にジャーニーを一時停止します。最大30日の固定待機に対応。
カート回復の自動化により、放棄されたカートを収益に変えます。タイミングの優れたリマインダー、パーソナライズされたオファー、そしてコンバージョンを促進するインセンティブを送信します。
プッシュ通知・メール・SMS・WhatsApp・LINEの到達可能性を送信前に確認し、閉じたチャネルを自動で迂回するカスタマージャーニー機能です。LINEユーザーも確実にカバーできます。