トリガー付きプッシュキャンペーン：コンテキストワークフローガイド

四半期の第2週になり、リテンションダッシュボードには6つの「自動」トリガーが稼働しており、すべて緑色で表示されています。カート放棄トリガーは、すでに支払い済みの購読者に対して繰り返し発火しています。ウィンバックは、同じく離反した顧客に対する価格下落アラートと重複しています。ウェルカムシリーズは、初回購入のプッシュとは独立して通知を送信します。購入後のレビューリクエストは、昨日注文を返品した購読者に届きます。

6つのトリガー型プッシュキャンペーンはそれぞれ、同じ購読者リストを指すパイプラインであり、他の5つが存在しないかのように振る舞っています。リピート購入率は12ヶ月前に動きを止め、トリガーは状態を共有しないため、チームの誰もトリガーごとの収益を特定できません。

これが、ほとんどのミッドマーケットのリテンションスタックにおける運用上の現実です。問題は戦略ではありません。戦略は問題ありません。問題はアーキテクチャです。2024年におけるトリガー型通知は、単一のイベントで発火する単一のメッセージでした。2026年、そのプリミティブだけでは不十分です。ジャーニーは、購読者が何をしたかを記憶し、それに基づいて分岐し、コンバージョンしたときに終了する必要があります。

この記事はアーキテクチャのケースを提示します。ブロードキャスト、トリガー、コンテクスチュアルプッシュ通知の境界を定義し、イベントトリガーとオーディエンストリガーの違いを説明し、単一のトリガーをコンテクスチュアルワークフローに変換する6つのノードタイプを挙げ、6つのスタンドアロンなトリガーを共有終了条件とワークフローごとの分析を備えた3つのコンテクスチュアルジャーニーに統合する3つの移行パターンを示します。

コンテクスチュアル、トリガー、ブロードキャスト：3つのプリミティブであり、1つではない

すべてのプッシュ通知プログラムの基盤には3つのプリミティブがあります。ほとんどのチームはそれらを「キャンペーン」と呼ばれる1つのバケットにまとめてしまい、そこにアーキテクチャの問題が始まります。

ブロードキャスト。同じ通知がスケジュールに従って、一致するすべてのオーディエンスに送信されます。正午のフラッシュセール。発売日の新コレクションアラート。ブロードキャストは、すべての受信者が同じペイロードを受け取る、時間制限のあるアナウンスに適したプリミティブです。購読者の状態に依存するあらゆるものには不適切なプリミティブです。

トリガー。単一のイベントが発生すると、単一の通知が発火します。購読者がカートを放棄すると、カート放棄通知が発火します。購読者が商品ページを表示すると、閲覧通知が発火します。購読者が購入すると、購入後通知が発火します。トリガーには記憶がありません。5分前に何が起こったのか、または来週火曜日に何がスケジュールされているのかを知りません。各トリガーは、他のすべてのトリガーを無視するパイプラインです。

コンテキストベース。 ワークフローはトリガーを入力ポイントとして使用し、その後、購読者の状態に合わせて適応します。同じカート放棄イベントが、1時間の待機、最初のリマインダー、24時間の待機、カートがまだ開いているかを確認する決定、割引付きの2番目のリマインダー、48時間の待機、3番目のリマインダー、そして購読者が購入した瞬間にワークフローをキャンセルする終了ルールという、複数のステップのジャーニーを開始します。キャンペーンはトリガーではなく、ワークフローです。コンテキストベースのプッシュ通知は、アーキテクチャが追いついたときのトリガーメッセージの動作方法です。

3つのプリミティブは、3つのワークロードにきれいにマッピングされます。現在のスタックを監査するときは、このテーブルを使用してください。

機能	ブロードキャスト	トリガー	コンテキストベース
購読者ごとの状態	いいえ	いいえ	はい
行動による分岐	いいえ	いいえ	はい
終了条件	いいえ	いいえ	はい
1つのキャンペーン内でのマルチチャネルルーティング	いいえ	いいえ	はい
組み込みA/B（送信時間、コピー、チャネル）	いいえ	いいえ	はい
適切なワークロード	フラッシュセール、ローンチアナウンス	単発トランザクションピング（低ボリューム）	ライフサイクルジャーニー（ウェルカム、カート、ウィンバック、更新）

ほとんどのライフサイクルプログラムにはコンテキストベースが必要です。ほとんどのチームはトリガーをシップします。そのギャップがこの記事の対象です。コンテキストベースのジャーニーをシップするマーケティングオートメーションワークフローは、長いトリガーリストのように見えません。共有語彙から構成された、より少ない数のマルチステップジャーニーのように見えます。実際に欲しいプッシュ通知ワークフローは、9つのトリガーではなく、3つのコンテキストベースのジャーニーです。

イベントトリガーとオーディエンストリガーは非常に異なる動作をします

ノードの解剖学の前に、このトピックに関するほとんどすべての記事が間違っている1つの分類法上のポイントがあります。プッシュ通知ワークフローにおける「トリガー」は、単一のプリミティブではありません。それは、外見は似ていて、内部では非常に異なる動作をする2つのプリミティブです。

イベントトリガーは、実際のイベントで購読者ごとに発生します。 PushEngageワークフローでサポートされているイベントには、PushEngage.Subscriber.Added、PushEngage.Subscriber.AddSegment、PushEngage.Subscriber.RemoveSegment、PushEngage.Subscriber.UpdateField、PushEngage.Subscriber.UpdateAttribute、PushEngage.Goal.Tracked、およびPushEngage.CustomEventが含まれます。イベントが発生すると、システムはアクティブなワークフローを評価し、イベントフィルター基準をチェックし、終了ルールをチェックし、その購読者の一致するワークフローをキューに入れます。トリガーからキューまでのギャップは数秒です。イベントトリガーは、カート放棄、閲覧放棄、購入フォローアップ、セグメント参加ウェルカムなど、あらゆるリアクティブキャンペーンに適したプリミティブです。イベントトリガーのプッシュキャンペーンは、eコマース、SaaSオンボーディング、およびリアルタイムシグナルを持つあらゆるプログラムで支配的なケースです。

オーディエンスのトリガーは、スケジュールされた時間にフィルターに火をつけます。フィルターは、last_active > 30 days、loyalty_tier = gold、またはcity = New York AND segments includes "vip"のような特定の基準に一致するサブスクライバーを選択します。スケジューラーポーラーは、一致するサブスクライバーセットを1000件のバッチで取得し、実行を15秒から2分間ずらし、サブスクライバーごとに1つのワークフローインスタンスを作成します。オーディエンストリガーは、再エンゲージメント、誕生日キャンペーン、地理的プロモーション、およびイベントではなく属性によってセットが定義されるあらゆるプログラムに最適なプリミティブです。

違いは、概念的なだけでなく、運用上も重要です。

側面	イベントトリガー	オーディエンストリガー
開始	サブスクライバーイベントのリアルタイム	ポーラーによるスケジュール
速度	数秒以内	バッチ処理、1〜2分の遅延
サブスクライバーの選択	イベントごとに1人のサブスクライバー	ワークフロー開始時にのみ一括選択
開始後の新規サブスクライバー	次のイベントで自動的に含まれる	ワークフロー開始後に自動的に含まれない
開始後のフィルター変更	該当なし	フィルターの編集では新規サブスクライバーは追加されません
イベントデータが利用可能	はい（変数置換用）	いいえ

3行目が落とし穴です。オーディエンスベースのワークフローは、ワークフロー開始時にサブスクライバーセットを一度選択します。ワークフロー開始後に非アクティブになったサブスクライバーは自動的に追加されません。アクティブなワークフローでオーディエンスフィルターを編集しても、新しい候補者は追加されません。「30日以上非アクティブなサブスクライバー向けのウィンバック」ワークフローを送信して90日間実行させた場合、毎日新しいサブスクライバーが30日のしきい値を超えても、90日間全体で同じ固定されたコホートが表示されます。

アーキテクチャ上の解決策は、オーディエンスワークフローを月次または週次の定期的なスケジュールで複製することです。これにより、各複製は前回実行以降に閾値を超えた候補者をキャプチャします。これはドキュメントの1行の運用上の注意であり、オーディエンストリガーをイベントトリガーのように扱うチームでは、「なぜこのサブスクライバーはキャンペーンを受け取らなかったのですか？」というサポートチケットの繰り返し発生源となります。

トリガーをコンテクスチュアルキャンペーンに変える6つのノード

トリガーが発火すると、ワークフロー自体は6つのノードタイプで構成されます。語彙は5分で学習できるほど小さく、リテンションチームがこれまで出荷したいと考えていたあらゆるコンテキストキャンペーンを構成できるほど大きいです。

START。エントリポイント。STARTノードは、トリガー（イベントベースまたはオーディエンスベース）とフィルター基準を定義します。ワークフローにはSTARTが1つだけあります。エントリポイントは、前のセクションのトリガー分類法を決定し、下流ノードが読み取ることができるイベントデータコンテキストを設定します。

WAIT。遅延。WAITノードは、指定された期間（分、時間、日）または特定のカレンダー時刻まで、加入者を保持します。WAITは、ワークフローが加入者の状態と加入者のタイムゾーンを尊重する方法です。ワークフローは、カート放棄のリマインダーのために1時間、ウェルカムシリーズでの機能ハイライトのために3日、またはビジネスアワーの送信のために加入者のローカルタイムゾーンで火曜日の午前10時まで待機できます。WAITを使用すると、最初の60秒ですべてのメッセージを送信することなく、複数ステップのドリップを構成することもできます。

DECISION。双方向分岐。DECISIONノードは、イベントフィルターまたはオーディエンスフィルターをチェックし、加入者をYESパスまたはNOパスにルーティングします。加入者は購入しましたか？まだカート放棄セグメントにいますか？ロイヤルティティアは変更されましたか？Decisionノードは、行動プッシュ通知がすべての加入者を同じように扱うのをやめ、各加入者が実際に行ったことに適応を開始する方法です。サポートされている演算子には、等しい、等しくない、含まれる、含まれない、より大きい、より小さい、および存在するが含まれており、リテンションチームが必要とするあらゆる決定ロジックを表現するのに十分です。

SPLIT_PATH。A/Bテスト用のパーセンテージベースのフォーク。SPLIT_PATHノードは、設定されたパーセンテージに基づいて加入者を2つ以上のパスにルーティングします。2方向テストの場合は50/50、3方向送信時間テストの場合は33/33/34、ホールドアウトグループの場合は90/10です。システムは、各新規加入者を最も利用率の低いパスにルーティングするロードバランシングアルゴリズムを使用しており、これにより、小さなサンプルサイズでも正確な分布が維持されます。テストが有意性に達したら、winner_edge_idを設定すると、ワークフローはワークフローを再構築することなく、トラフィックの100％を勝者バリアントに昇格させます。

ACTION。実際の作業。ACTIONノードは、プッシュ通知の送信以上のことを行います。PushEngageワークフローは、11種類のアクションタイプをサポートしています：SendPushNotification、AddSegment、RemoveSegment、UpdateField、UpdateAttribute、Update（結合）、HttpRequest、CustomEvent.Send、SendTriggerCampaignEvent、Workflow.Start、およびWorkflow.Stop。リテンションプログラムで最も一般的な4つは、SendPushNotification、AddSegment（加入者をコンバージョン済み、オンボーディング済み、またはチャーンリスクとしてタグ付け）、UpdateAttribute（ロイヤルティカウンターをインクリメントまたは最終購入日を設定）、およびHttpRequest（CRMに状態を同期、高価値リードのSlackアラートを発火、または下流サービスを呼び出す）です。

終了 / 終了ノード。 ワークフローを完了し、分析を更新します。終了ノードはワークフローの自然な結論を示します。終了ノードは通常、サブスクライバーが適格でない場合の決定の「いいえ」パス、または制御グループとして設計された分割パスブランチに配置されます。システムは、ワークフローレベルの終了基準もサポートしています。これは、各ノードが実行される前にアクティブなワークフローをキャンセルするaudience_filterまたはtrigger_eventです。終了ルールは、サブスクライバーが現在どのノードにいるかに関係なくトリガーされます。これにより、すでに購入したサブスクライバーにリマインダーを送信するカート放棄ワークフローが停止します。

この記事のすべてのコンテキストキャンペーンは、これら6つの要素で構成されています。語彙が共有されれば、以下の移行パターンはすぐに読めるようになります。

3つの移行パターン：6つのスタンドアロントリガーが3つのコンテクスチュアルワークフローになる

ほとんどのミッドマーケットのリテンションスタックには、4つから8つのスタンドアロンのトリガーが実行されています。パターンは一貫しています。ウェルカム通知、初回購入のプッシュ、カート放棄、閲覧放棄、購入後のレビューリクエスト、ウィンバック、再エンゲージメント、休眠VIP。これらはそれぞれ、独自のコピー、独自の担当者、独自の分析を持つ個別のトリガーです。それらのどれもがお互いを認識していません。同じ3つのコンテキストワークフローで、表面積を3分の1にしながら、同じ収益を上げることができます。

パターン1 — オンボーディングの統合

ウェルカムシリーズと初回購入プッシュを、購入ステータスに関する決定を伴う1つのワークフローにまとめます。

• 開始: イベントPushEngage.Subscriber.Added
• 実行タイプ: シングル（完了後90日間のクールダウン）
• フロー: 1日待機 → アクション：ウェルカム通知を送信 → 3日待機 → 決定：サブスクライバーは購入しましたか？ → YESパス：アクション：ありがとうメッセージを送信 + アクション：AddSegmentをcustomersに追加 + 終了 → NOパス：アクション：初回購入10%割引を送信 → 4日待機 → 決定：サブスクライバーは購入しましたか？ → YESパス：アクション：ありがとうメッセージを送信 + 終了 → NOパス：アクション：最終プッシュを送信 + 終了
• 終了基準: ワークフローレベルではなし。決定分岐がコンバージョンしたサブスクライバーを処理します。
• 置き換え対象: ウェルカムトリガー + 初回購入トリガー（トリガー2つ → ワークフロー1つ）

共有状態がすべてです。3回目の通知は、4日目までにコンバージョンしていないサブスクライバーにのみ送信されます。古いアーキテクチャの初回購入トリガーは、最初のセッションで購入したサブスクライバーを含む、すべての新規サブスクライバーに対してトリガーされました。ワークフローはそれらを煩わせるのをやめます。

パターン2 — カートからレビューへのチェーン

カート放棄からの回復と購入後のレビューリクエストを、ワークフローチェーンのハンドオフを伴う1つのワークフローにまとめます。

• 開始: カスタムイベントcart_abandoned
• 実行タイプ: 複数並列（放棄されたカートごとに個別のインスタンス）
• フロー: 1時間待機 → アクション：リマインダー#1 → 24時間待機 → 決定：カートはまだ放棄されていますか？ → YESパス：アクション：リマインダー#2（10%割引付き） → 48時間待機 → 決定：カートはまだ放棄されていますか？ → YESパス：アクション：最終リマインダー（20%割引付き） → 終了
• 終了条件（ワークフローレベル）：トリガーイベントのcart_idに一致するGoal.Tracked = purchase。購読者が購入した時点で、ワークフローはキャンセルされます。
• 引き継ぎ：購入による終了時、システムはレビューリクエストワークフローを対象としたPushEngage.Workflow.Startを発火させます。レビューワークフローは、実際に購入した購読者に対してのみ開始されます。購入しなかったことによる終了パスは、引き継ぎを完全にスキップします。
• 置き換え対象：カートトリガー + 購入後レビュートリガー + 購入しなかった購読者に届くレビューリクエストからのサポートチケット（3つの問題 → 1つのワークフロー）

Workflow.Startを介した連鎖は、ライフサイクル進行に対するアーキテクチャ上の回答です。2つのトリガーが独立して発火し、同じ購読者に重複する代わりに、購入時のカートワークフローの終了がレビューワークフローを開始します。レビューはコンバージョンした購読者に対してのみ発火します。カートはコンバージョン後に発火しません。引き継ぎはエンジンによって強制されます。

パターン3 — 再エンゲージメントの統合

ウィンバック、リアクティベーション、および失効したVIPキャンペーンを、オーディエンストリガーと3つの意思決定分岐を持つ1つのワークフローに統合します。

• 開始：オーディエンスフィルターlast_active > 30 days
• 実行タイプ：シングル（90日間のウィンドウごとに購読者あたり1回の再エンゲージメント試行）
• フロー：決定：ロイヤルティティア？ → ゴールド分岐：アクション「寂しいです、VIP様」を20%オフで送信 → シルバー分岐：アクション「寂しいです」を10%オフで送信 → 非ティア分岐：アクション標準「寂しいです」を送料無料オファーで送信 → 5日間待機 → 決定（分岐ごと）：購読者はエンゲージしたか、サイトを訪問したか？ → YESパス：アクションAddSegmentをre-engagedに追加 + 終了 → NOパス：アクション「最後のチャンス」をより深いオファーで送信 + 終了
• 終了条件（ワークフローレベル）：オーディエンスフィルターlast_active < 7 days。購読者は自らアクティブになり、ワークフローの役目は終了しました。
• 置き換え対象：ウィンバックトリガー + リアクティベーショントリガー + 失効VIPトリガー（3つのトリガー → 1つのワークフロー）
• 運用上の注意：前のセクションのオーディエンストリガーの落とし穴により、このワークフローは、ワークフロー開始後に30日のしきい値を超えた購読者を自動的に含みません。新しい候補をキャプチャするために、ワークフローを毎月複製します。単一の長時間実行オーディエンスワークフローは、ここでは間違ったプリミティブです。

これらの3つの移行後、リテンションチームは6つ（または8つ）のスタンドアロン トリガーではなく、3つのコンテクスチュアルジャーニーを管理します。プッシュメッセージの総量はほぼ同じままです。共有終了条件と決定分岐が購読者の状態が一致しなくなったときにワークフローを停止するため、過剰なメッセージングはなくなります。「調整できない6つのダッシュボード」からの分析の断片化が、「擁護できる3つのファネル」に変わります。これが、イベントトリガーのプッシュキャンペーンが成熟した姿です。

スタンドアロントリガーにはできない、コンテクスチュアルワークフローができること

コンテキストワークフロー内には4つの機能が存在し、スタンドアロントリガーをまたいで構成することはできません。それぞれが収益または節約の実際の源泉となります。

ワークフローをまたぐ終了基準。スタンドアロントリガーは、イベントが発生するとすぐに起動し、それ以上はありません。ワークフロー内では、加入者がどのノードにいても終了ルールが起動します。カート放棄ワークフローは購入時に終了します。ウィンバックワークフローは再アクティベーション時に終了します。更新ワークフローは早期更新時に終了します。停止するように指示されなかったトリガーは、終了ルールを定義するワークフローです。

1つのワークフロー内でのマルチチャネルルーティング。個別のシングルチャネルツールでは、「Webプッシュを起動し、メールにフォールバックし、WhatsAppにエスカレートする」には、3つのベンダーログイン、2つのセグメンテーションエンジン、および少なくとも1つのZapierフローが必要です。1つのワークフローエンジン内では、3つのACTIONノードと、その間に2つのDECISIONノードがあり、1つの加入者IDと1つの終了基準セットを共有します。詳細については、マルチチャネルプッシュおよびメールオーケストレーション投稿を参照してください。

rescheduleフォールバックによるサイレントアワー。加入者のローカルタイムゾーンで午前3時に配信されるプッシュ通知は、サイレントアワーがフォールバックとしてrescheduleで構成されている場合、午前8時01分まで保持されます。代替のskipは、通知をサイレントにドロップし、スキップされたアクションの通知分析を更新しません。ほとんどのリテンションチームにとって、rescheduleが適切なデフォルトです。なぜなら、ドロップされた分析は、収益アトリビューションの低下を意味するからです。リテンションチームが実際に送信したいコンテキストプッシュ通知は、ファネルから消えることなく、加入者のタイムゾーンを尊重します。

ワークフローの連鎖。Workflow.StartおよびWorkflow.Stopアクションにより、ライフサイクル進行は実際のアーキテクチャになります。ウェルカムワークフローが終了し、エンゲージメントワークフローが開始されます。カートワークフローは購入時に終了し、レビューワークフローが開始されます。すべてが独立して起動するトリガーのフォルダと比較して、これはステートマシンです。ワークフローのグラフであり、それぞれに独自の開始条件、終了条件、および次のステージへの引き継ぎがあります。トリガーは互いを認識しません。ワークフローは認識します。

ワークフローごとの分析：ファネルの読み方

次のP&Lレビューで擁護できないワークフローは、廃止されるワークフローです。PushEngage Workflowsは、各ノードで3つの数値（queued_users、completed_users、exited_users）と、総入力数、現在アクティブ数、完了数、終了数に対するワークフローレベルの合計を追跡します。リテンションマネージャーの仕事は、このファネルを読み取り、各項目が何を生み出したかを財務に伝えることです。

パターン2のカートからレビューへのチェーンのノードレベル分析の外観を以下に示します。6％の月間カート放棄率を持つ、現実的な200,000人の加入者リストから描かれた、説明的な数値です。

ノード	キューに入れられた	完了	離脱	メモ
開始（cart_abandoned）	0	12,400	320	320人の加入者がワークフロー開始時に終了基準に一致しました（カートイベントとワークフローのスキャン間に購入）
1時間待機	180	11,900	320	通常のキュー深度
アクション：リマインダー#1	0	11,900	0	送信済み
24時間待機	240	9,800	1,860	1,860人の加入者がリマインダー#1の後に購入しました（目標purchaseで終了）
決定：カートはまだ放棄されています	0	9,800	0	ブランチが評価されました
ACTION：リマインダー #2 (10%)	0	9,800	0	送信済み
48時間待機	90	6,300	3,410	リマインダー #2 の後、3,410人の購読者が購入しました
ACTION：最終リマインダー (20%)	0	6,300	0	送信済み
終了	該当なし	6,300	該当なし	6,300人の購読者が購入せず。これらの購読者向けにワークフローの連鎖がレビューされていません
Workflow.Start → レビューワークフロー	該当なし	5,270	該当なし	購入した5,270人の購読者（1,860 + 3,410）に送信されました

5,270件の連鎖ハンドオフは、このアーキテクチャが新たに提示するメトリックです。カートワークフローは、42.5%のカート率（12,400件中5,270件が開始）を回復し、レビューリクエストワークフローを受け取るのは、その5,270人の購読者のみです。古いアーキテクチャでは、カートを放棄したことのない購読者、返品した購読者、すでにレビューを送信した購読者を含む、購入したことのあるすべての購読者にレビューリクエストが送信されていました。アーキテクチャの修正は小規模ですが、過剰なメッセージングによる節約は大きいです。

知っておくべき2つのボトルネックパターンがあります。高出口ノード（上記の2つのWAITノードなど）は、ワークフローがそのジョブを実行していることを示しています。購読者は待機ウィンドウ中に購入し、終了基準が満たされると、次のリマインダーは送信されません。逆のパターン、アクションノードでの高出口と待機ノードでの低出口の組み合わせは、タイミングが間違っており、待機時間を短縮する必要があることを意味します。高キューノードは、静寂時間による停止、長い待機時間、または下流のポーラー遅延を示します。ワークフローが壊れていると仮定する前に、タイミング設定を確認してください。

これらのパターンのより深いeコマース固有の処理については、eコマース向けの5つのプッシュ通知ワークフローに関する補足記事で、カート、ブラウズ、購入後、ウェルカム、ウィンバックをスタンドアロンのジャーニーとして紹介しています。eコマースプッシュ通知ハブは、より広範なキャンペーンタイプの状況をカバーし、カート放棄回復シーケンスはプラットフォームごとのケイデンス調整を説明し、自動プッシュ通知の概要は、このワークフローアーキテクチャとともに、古い自動化タイプのリスト記事を紹介しています。

同じ分析形状は、さまざまな業種で機能します。SaaSには更新ファネルとトライアルから有料へのコンバージョンがあります。パブリッシャーには記事エンゲージメントファネルとアーカイブ再参加があります。旅行には予約ファネルと価格変動アラートフローがあります。SaaSチームがトライアルから有料へのコンバージョンを促進するために使用する行動プッシュ通知は、eコマースチームがカートから購入へのコンバージョンを促進するために使用するものと構造的に同一です。リアルタイムイベントでの1つのSTART、意思決定分岐を伴う3〜4ステップ、コンバージョンでの終了基準、次のワークフローへのオプションの引き継ぎ。業種によってトリガー名とオファーコピーが異なります。アーキテクチャは同じです。

PushEngageワークフローで構築する

上記の3つの移行パターンのそれぞれは、PushEngage Workflowsコンポーネントに直接マッピングされます。

パターン	使用ノードタイプ	使用アクションタイプ	ワークフローオプション	推奨テンプレートの開始点
オンボーディング統合	START、WAIT、DECISION、ACTION、END	SendPushNotification、AddSegment	実行タイプ：シングル	「初回購入分岐付きウェルカムシリーズ」
カートからレビューへの連鎖	START、WAIT、DECISION、ACTION、END	SendPushNotification, Workflow.Start	実行タイプ：複数並列；終了基準 Goal.Tracked = purchase	「カート放棄エスカレーション」
再エンゲージメント統合	START（オーディエンス）、DECISION、ACTION、WAIT、END	SendPushNotification、AddSegment	実行タイプ：単一；オーディエンストリガー；月次重複	「ティアベースオファーによる再エンゲージメント」

ワークフローエンジンには、上記の各移行パターンを網羅した60以上の出荷済みテンプレートが付属しています。各テンプレートは出発点です。パターンは、Shopify、Shopify Plus、WooCommerce、BigCommerce、MagentoではPushEngageワークフロービルダー内に、またはJavaScript SDKとイベントAPIを介して任意のSaaS、パブリッシャー、またはトラベルスタックに5分未満でインストールできます。

無料プランでは、200人の購読者、すべてのチャネル（ウェブプッシュ、アプリプッシュ、WhatsApp、ライブチャット）、および完全なワークフローエンジンを初日から利用できます。これは、予算を要求する前に、3つのパターンのうち1つを現在のトリガースタックから移行し、アーキテクチャを証明するのに十分です。無料プランから始めると、1時間以内に最初のコンテキストワークフローをリリースできます。

この記事から何か一つ持ち帰るとしたら、それは、トリガーされたプッシュキャンペーンはもはや通知ではないということです。それはワークフローです。独立して実行される6つのスタンドアロントリガーは、同じ購読者リストに向けられた6つのパイプラインであり、それぞれがお互いを認識していません。

共有状態、意思決定分岐、終了基準、および連鎖的な引き継ぎを実行する3つのコンテキストワークフローは、購読者ごとの1つのジャーニーであり、分岐および境界設定されています。ワークフローごとの防御可能なファネルと複利で増加するリピート購入率を生み出すマーケティングオートメーションワークフローは、トリガーの長いリストではなく、より小さく、よりシャープなコンテキストジャーニーのセットです。アーキテクチャがキャンペーンです。トリガーはドアです。