四半期の第3金曜日、あなたはリテンションダッシュボードを見ています。カート放棄シーケンスが実行中です。閲覧放棄トリガーが実行中です。購入後レビューリクエストが実行中です。値下げアラートが実行中です。サインアップごとにウェルカム通知が送信されます。6つの「自動化された」プッシュ通知。過去18ヶ月で設定された6つのトリガー。リピート購入率は12ヶ月前に動きを止めました。
これが、ほとんどの中規模ECリテンションスタックにおけるプッシュ通知自動化の現状です。6つの断片化されたトリガーがあり、それぞれが異なるキャンペーンオーナーからのコピーを配信し、互いを認識していません。カート放棄シリーズは、すでに購入した購読者に対して通知を送信し続けています。ウィンバックキャンペーンは、同じ顧客に対する値下げアラートと重複しています。共有ロジック、共有終了条件、共有IDはありません。単に6つの独立したパイプがあり、それぞれが同じ購読者リストを対象とし、他の5つが存在しないかのように振る舞っています。
ECのプッシュ通知自動化は、このように機能すべきではありません。単一の購読者IDから、Webプッシュ、アプリプッシュ、WhatsApp、ライブチャット全体で実行される、共有トリガー、共有意思決定ロジック、共有終了条件を持つマルチノードジャーニーのセットとして、1つのワークフローアーキテクチャとして機能すべきです。この記事では、そのアーキテクチャがどのようなものか、すぐに使える5つの完全なワークフローブループリントを紹介し、ワークフローごとのファネルの読み方を説明して、項目が財務部門に説明可能になるように解説します。
ほとんどの「自動プッシュ通知」は実際には自動化されていません
「自動化」という言葉は、ECブログ界で多くの不当な恩恵を受けてきました。ほとんどの記事で「自動プッシュ通知」と言っている場合、それは「トリガー付きプッシュ通知」を意味します。つまり、イベントが発生したときに単一の通知が送信され、それ以上の状態、待機、分岐、終了条件はありません。購読者がカートを放棄すると、カート放棄通知が送信されます。購読者が製品を表示すると、閲覧通知が送信されます。購読者が購入すると、購入後通知が送信されます。各トリガーは独自のパイプラインであり、他のすべてのトリガーを認識していません。
ワークフローはそれとは異なります。ワークフローは状態を持つマルチステップジャーニーです。購読者がどこから入ったか、現在どこにいるか、各ノードにいつ入ったか、どのような条件でジャーニーがキャンセルされるかを知っています。カート放棄ワークフローは、1時間後に単一の通知を送信するだけではありません。1時間後に送信し、1日待って、カートがまだ放棄されているかを確認し、2回目のタッチで割引を送信し、さらに2日待って、最後のタッチを送信し、購読者が購入した瞬間に、どのステップにいてもワークフローを終了します。
最後の句が違いを生みます。トリガーには記憶がありません。ワークフローにはあります。「放棄されたカート自動化」が、顧客がすでに支払った後もリマインダーを送信し続けている場合、それは自動化ではありません。停止するように指示されていないトリガーです。
中規模市場のEコマースリテンションチームにとって、この区別は、リピート購入率が複利で増加するか、停滞するかの違いとなります。6つのトリガーを並行して実行すると、6つのノイズチャネルが生成されます。5つのワークフローを連携して実行すると、購読者ごとに1つのジャーニーが生成され、分岐および制限されます。このキーワードのページ1の検索結果のほとんどは、「どのような通知を送信するか」という問題として提示され、9つ、12、または15のテンプレートのリスト記事で回答しています。それは問題ではありません。問題は、ジャーニーをどのように構成するかということです。
プッシュ通知ワークフローの構造
設計図の前に、語彙。プッシュ通知ワークフローは6つのノードタイプから構築されます。それぞれの機能がわかれば、この記事のすべての設計図は説明ではなく図として読めるようになります。
START。 エントリーポイント。STARTノードは、購読者のイベント（カート放棄、ページ表示、セグメント参加、購入目標追跡）またはスケジュールされた時間に特定の基準に一致する購読者を選択するオーディエンスフィルターによって、ワークフローがどのようにトリガーされるかを定義します。ワークフローにはSTARTが1つだけあります。
WAIT。 遅延。WAITノードは、指定された期間（分、時間、日）または特定のカレンダー時刻（購読者のタイムゾーンでの火曜日の午前10時、サイト時間の12月15日午後8時）まで、購読者をこのポイントで保持します。Waitは、ワークフローが一度限りの一斉送信にならないようにする方法です。
DECISION。 双方向分岐。DECISIONノードは、条件（購読者が購入したか、まだカート放棄セグメントにいるか、ロイヤルティティアが「ゴールド」か）をチェックし、YESパスまたはNOパスにルーティングします。Decisionは、ワークフローがすべての購読者を同じように扱うのをやめる方法です。
SPLIT_PATH。 パーセンテージベースの分岐。SPLIT_PATHノードは、設定されたパーセンテージに基づいて購読者を複数のパスにルーティングします：A/Bテストの場合は50/50、3方向の送信時間テストの場合は33/33/34。勝者が決まったら、勝ったパスを100%に昇格させ、ワークフローは証明されたバリアントで実行を続けます。
ACTION。 作業そのもの。ACTIONノードは、プッシュ通知を送信したり、購読者をセグメントに追加したり、属性を更新したり、Webhookをトリガーしたり、別のワークフローを開始したり、停止したりします。PushEngage Workflowsは11種類のアクションタイプをサポートしています。Eコマースで最も一般的なのは、SendPushNotification、AddSegment、UpdateAttribute、HttpRequestです。
END / EXIT。 ターミナル。ENDおよびEXITノードは、ワークフローの完了をマークし、分析を更新します。ENDは自然な結論です。EXITは通常、早期終了に使用されます：購読者が資格がない場合のDecisionノードのNOパス、またはコントロールグループとして設計されたSplit Pathブランチ。
以下のすべてのワークフローは、これらの6つのピースから構成されています。語彙が共有されれば、設計図は速く読めるようになります。
Eコマース向けの5つのワークフロー設計図
これらは「例」ではありません。動作する設計図です。それぞれにトリガー、実行タイプ、ノードシーケンス、終了条件、および意図された保持メトリックがリストされています。それぞれを直接PushEngage Workflowsビルダーにインポートして、1時間以内に実行を開始できます。
設計図 1 — ウェルカムシリーズ
- トリガー（開始）：イベント
PushEngage.Subscriber.Added - 実行タイプ：シングル（購読者ごとに1回のウェルカムジャーニー、再参加には90日間のクールダウン期間あり）
- フロー：ウェルカム通知（即時）→ 2日間待機 → 機能紹介通知 → 3日間待機 → 決定：購読者は購入しましたか？ → はい：感謝の通知を送信し、
customersセグメントに追加 → いいえ：初回購入割引を送信 → 終了 - 終了条件：なし。ジャーニーは短いため、すべての購読者が完了するはずです。
- 保持メトリック：初回購入までの時間。ウェルカムシリーズを完了した新規購読者は、完了しなかった購読者よりも早く購入します。これは、3回目のタッチが初回購入の意図が具体化または停滞した瞬間に発生するためです。
設計図 2 — ブラウズ放棄
- トリガー（開始）：カスタムイベント
page_viewを、30分以内にadd_to_cartを発生させなかった商品詳細ページにフィルタリング - 実行タイプ：複数並列（購読者はセッション中に複数の商品をブラウズ放棄する可能性があり、それぞれに独自のワークフローインスタンスが作成されます）
- フロー：30分待機 → 決定：購読者はまだサイトを閲覧していますか？ → はい：終了（アクティブなセッションを中断しないでください） → いいえ：閲覧した商品のリマインダー通知を送信 → 24時間待機 → 決定：カートに追加しましたか？ → はい：終了（ここからはカート放棄ワークフローが引き継がれます） → いいえ：関連商品のおすすめを含む2回目のタッチを送信 → 終了
- 終了条件：目標
add_to_cart（カートワークフローがジャーニーを引き継ぎます）または目標purchase（それ以上のメッセージングは不要です） - 保持メトリック：以前に閲覧した商品に対するブラウズからカートへのコンバージョン率。PushEngageのブラウズ放棄キャンペーンに関する投稿では、この設計図が引き継ぐセグメンテーション作業について説明しています。
設計図 3 — カート放棄エスカレーション
- トリガー（開始）：カスタムイベント
cart_abandoned - 実行タイプ：複数並列（放棄された各カートは独自のジャーニーであるため、最初のカートがアクティブな間に2番目のカートを放棄した購読者には、2番目の同時インスタンスが作成されます）
- フロー：1時間待機 → リマインダー#1（割引なし、丁寧なトーン）→ 24時間待機 → 決定：カートはまだ放棄されていますか？ → はい：10%割引付きリマインダー#2 → 48時間待機 → 決定：カートはまだ放棄されていますか？ → はい：緊急性を強調した最終リマインダー（20%割引付き）→ 終了
- 終了条件: トリガーイベントからの
cart_idに一致するpurchaseゴール。購読者が購入した時点で、現在の場所に関わらず、そのカートのワークフローはキャンセルされます。 - リテンション指標: チャネルあたりの放棄されたカートあたりの回収カート価値。これは、ページ上で最も影響力の大きいワークフローであり、損益計算書で最も防御しやすいものです。特にカート放棄回収シーケンスの詳細については、PushEngageカート放棄プレイブックで、プラットフォームの動作に合わせてケイデンスがどのように調整されるかを説明しています（Shopify Plusのチェックアウトフローは、最初の待機時間に影響を与える点でWooCommerceとは異なります）。
ブループリント 4 — 購入後のレビューリクエスト
- トリガー（開始）: イベント
PushEngage.Goal.Tracked、ここでgoal_name = purchase - 実行タイプ: 複数シーケンシャル（購読者ごとに一度に1つのアクティブなレビューリクエストジャーニーですが、次の購入で新しいインスタンスがトリガーされます）
- フロー: 7日間待機（製品を受け取り、意見を形成するのに十分な長さ）→パス分割 50/50：午前送信（購読者の現地時間午前9時）対午後送信（購読者の現地時間午後7時）→レビューリクエスト通知→アクション：CRMへのHTTPリクエストでレビューリクエスト送信を記録→終了
- サイレントアワー: 購読者のタイムゾーンで午後10時から午前8時まで、フォールバック
reschedule。夜間に配信されるプッシュ通知は、ドロップする代わりに午前8時01分まで待機します。skipはサイレントに通知をドロップし、分析から除外するため、ほとんどのリテンションチームが望まないため、reschedule設定はこのワークフローの適切なデフォルトです。 - 終了条件: ゴール
review_submitted - リテンション指標: 送信時間バリアント別のレビュー送信率。分割パスは、キャンペーンレポートに付随する afterthought ではなく、ワークフローの一部としてA/Bテストを行います。
ブループリント 5 — ウィンバック
- トリガー（開始）: オーディエンスフィルター
last_active > 30 days - 実行タイプ: シングル（90日間のウィンドウごとに購読者ごとに1回のウィンバック試行）
- フロー: 「寂しいです」通知→3日間待機→決定：購読者は通知にエンゲージしたか、サイトを訪問しましたか？→はいパス：
re-engagedセグメントに追加し、感謝と割引を送信、終了→いいえパス：より強力なオファーをより深い割引で送信→5日間待機→決定：まだ非アクティブですか？→はいパス：最終的な「最後のチャンス」通知→終了 - 終了条件: オーディエンスフィルター
last_active < 7 days。購読者は自分でアクティブになり、ワークフローのジョブは完了しました。 - リテンション指標: ワークフローエントリーから60日後の再エンゲージメント率。
A word on the trigger. This is the only blueprint in this article that uses an audience-based trigger rather than an event-based trigger. Audience triggers in PushEngage Workflows batch-process the matching subscriber set at workflow start time only. Subscribers who become inactive after the workflow starts are not auto-included, and editing the audience filter on an active workflow does not add new subscribers. If you want a rolling re-engagement program, duplicate the workflow on a recurring schedule (monthly or quarterly) rather than expecting one long-running audience workflow to keep ingesting new candidates. This is a real source of “why didn’t this subscriber get the win-back?” support tickets in teams that misunderstand the trigger type.
Segmentation, A/B testing, and exit criteria live inside the workflow
The dominant pattern across the page-one search results for this keyword is to list segmentation, A/B testing, and quiet hours as “best practices”: generic bullets at the end of the article, divorced from the campaign that uses them. That is the wrong frame. These are not best practices that sit next to the workflow. They are the workflow.
Here is the same set of concepts, framed as best practices versus framed as workflow nodes:
| Concept | Best-practice framing (wrong) | Workflow-node framing (correct) |
|---|---|---|
| RFM segmentation | “Segment your list before you send” | A DECISION node that checks recency, frequency, and monetary value, then routes high-RFM subscribers to a different path than low-RFM ones. The PushEngage segmentation post covers the RFM bucket definitions that feed this node. |
| A/Bテスト | “Always A/B test your copy” | A SPLIT_PATH node with 50/50 percentage allocation, load-balanced subscribers per path, and a winner_edge_id field that promotes the winner to 100% once the test reaches significance |
| サイレントアワー | 「午前3時に送信しないでください」 | A workflow-level option with start_at, end_at, timezone, and a fallback setting that either skips the send or reschedules it to one minute after quiet hours end |
| 終了条件 | “Stop sending to people who bought” | 各ノードの前にサブスクライバーをオーディエンスフィルターまたはトリガーされたゴールに対してチェックし、一致した場合はワークフローをキャンセルするワークフローレベルのルール |
この違いは重要です。なぜなら、ベストプラクティスの箇条書きは簡単に同意できるものの、実施が難しいからです。ワークフローノードはエンジン自体によって強制されます。DECISION は毎回実行されます。SPLIT_PATH はすべてのサブスクライバーをバランスさせます。サイレントアワーのフォールバックは、誰も時間をチェックすることを覚えていなくても機能します。終了ルールは、キャンペーンオーナーが注意を払っているかどうかにかかわらず、ワークフローをキャンセルします。
For the cart-abandonment blueprint above, this means the moment a subscriber purchases the abandoned items, the exit rule fires, the workflow cancels for that subscriber, and the second and third reminders never go out. No support ticket, no email from finance, no apology campaign. The workflow stopped because the engine had a rule that told it to stop.
Multi-channel orchestration: one workflow, four channels
Most push notification platforms are one-channel tools. Some are two-channel. The question they cannot answer well is the one a mid-market retention team actually needs to answer: given this subscriber’s state, which channel should fire? Web push if they opted in. Email if they opted out of web push. WhatsApp if the cart value is over $200. Live chat if the subscriber is currently on the site.
この決定ツリーは、4つのツールで4つのキャンペーンを実行するのではなく、単一のマルチチャネルプッシュ通知自動化ワークフローです。PushEngageワークフローを使用すると、カート放棄ジャーニーは次のように構成できます。
- 開始：
cart_abandonedイベント - 待機： 1時間
- 決定ノード1：購読者はウェブプッシュに登録していますか？
- YESパス：アクション、ウェブプッシュリマインダーを送信
- NOパス：次の決定に進む
- 待機：ウェブプッシュ後30分（またはプッシュが送信されなかった場合は直ちに）
- 決定ノード2：購読者はウェブプッシュをクリックしましたか、またはウェブプッシュに登録されていませんか？
- ウェブプッシュが送信され、クリックされた場合：終了（カートフローを完了させる）
- ウェブプッシュが送信されたがクリックされなかった場合、またはウェブプッシュがない場合：続行
- 決定ノード3：カートの価値は200ドルを超えていますか？
- YESパス：アクション、WhatsAppチャネルのSendPushNotificationアクションを介してWhatsAppメッセージを送信
- NOパス：アクション、ESPへのHTTPリクエストを介してメールを送信
- 目標
purchaseで終了
4つのチャネル、1つのワークフロー、1つの終了基準セット、1つの購読者ID。以前は3つのベンダーログインとZapierフローなしではこれをオーケストレーションできなかった同じリテンションマネージャーが、エンジンによって強制される1つのワークフロー内でこれを構成できるようになりました。
個別のツールで同じことを行うことは、プラットフォーム間の6回の同期、誰が「VIP購読者」としてカウントされるかについて意見が異なる2つのセグメンテーションエンジン、および各ツールが独自のコンバージョンを報告するため単一の収益アトリビューションがないことを意味します。1つのワークフローエンジン内でこれを行うことは、1つの購読者ID、1つの決定ロジックセット、および1つのファネルレポートを意味します。プッシュとメールが単一のリテンションプラン内でどのように連携するかについては、プッシュとメールのマルチチャネルオーケストレーションを参照してください。
これは、支配的なページ1の結果には類似するものがない差別化要因です。このキーワードのトップ15の結果のいずれも、クロスチャネルワークフローを単一のオブジェクトとして説明していません。それらはすべて、プッシュをトピックとして、メールを比較として扱っています。
リテンションの計算：ワークフローあたりの収益、チャネルあたりの収益、通知あたりの収益
次のP&Lレビューで擁護できないワークフローは、廃止されるワークフローです。リテンションマネージャーの仕事は、各項目がどれだけの収益を生み出したかをドルで示すことです。「eコマース向けの自動プッシュ通知」に関するほとんどの記事は、クリック率で終わっています。それは十分ではありません。適切な指標は、購読者あたりの収益、ワークフローあたりの収益、チャネルあたりの収益です。
PushEngageワークフローは、各ノードで3つの数値を追跡します。
- キューに入れられたユーザー: このノードで現在待機しているサブスクライバー（通常はWAITまたは静寂時間による再スケジュール）
- 完了したユーザー: このノードを通過したサブスクライバー
- 終了したユーザー：このノードでワークフローを離れた購読者。終了基準が一致したか、購読解除したためです。
アクティブなカート放棄ワークフローのノードレベル分析は次のようになります（例示的な数値で、現実的な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の後に1,860人の購読者が購入しました |
| 決定：カートはまだ放棄されています | 0 | 9,800 | 0 | 品目が行使可能な場合（このワークフローはXドルでYドルの全コストでカートを回収しました）、予算の議論は短くなります。 |
| アクション：リマインダー #2（10%オフ） | 0 | 9,800 | 0 | 割引付きで通知を送信しました |
| 48時間待機 | 90 | 6,300 | 3,410 | さらに3,410件の購入が離脱を引き起こしました |
| アクション：最終リマインダー（20%オフ） | 0 | 6,300 | 0 | 最終通知 |
| 終了 | 該当なし | 6,300 | 該当なし | 6,300人の購読者が購入しませんでした |
このファネルでは、5,270人の購読者（1,860 + 3,410）がワークフロー内で購入し、42.5%のカート回収率を達成しました。2つの待機（24時間と48時間）はファネル内で最も離脱が多いノードであり、これは予想されるパターンです。購入までの意思決定は、アクションウィンドウではなく、待機ウィンドウで行われます。ワークフローで逆のパターンが表示され、アクションノードで離脱が多く、待機ノードで離脱が少ない場合は、タイミングが間違っており、待機時間を短縮する必要があります。
リテンションの計算にはコストも考慮する必要があります。プッシュ通知は、購読者がオプトインすれば送信あたりのコストはかかりません。EメールのコストはESPによって異なりますが、200,000件の購読者リストでKlaviyoまたはBloomreachのような一般的なセットアップの場合、1回のカート放棄送信でメーター使用量で数百ドルかかります（契約条件が適用されます）。
42%のカートを回収できるプッシュ優先の放棄カートプッシュ通知自動化は、プッシュとEメールのワークフローが38%の場合と同じ回収収益額を、大幅に低いコストで達成できます。ご自身のリストサイズとESP契約で計算してみてください。重要なのは、プッシュ、アプリプッシュ、WhatsAppはEメールのような送信あたりのコストがかからず、ワークフローのジョブは、購読者の状態が許す限り、常に最も安価なチャネルを最初に利用することです。
When the line item is defensible (this workflow recovered $X in carts at a $Y all-in cost), the budget conversation is short.
PushEngageワークフローで構築する
この記事のすべてのブループリントは、PushEngageワークフローコンポーネントに直接マッピングされます。上記の5つのブループリントのマッピングは次のとおりです。
| ブループリント | 使用ノードタイプ | 使用アクションタイプ | ワークフローオプション |
|---|---|---|---|
| ウェルカムシリーズ | START、WAIT、DECISION、ACTION、END | SendPushNotification、AddSegment | 実行タイプ：シングル |
| 閲覧放棄 | START、WAIT、DECISION、ACTION、EXIT | SendPushNotification | 実行タイプ：複数並列 |
| カート放棄エスカレーション | START、WAIT、DECISION、ACTION、END | SendPushNotification | 実行タイプ：複数並列；目標購入で終了 |
| 購入後レビューリクエスト | START、WAIT、SPLIT_PATH、ACTION、END | SendPushNotification、HttpRequest | 実行タイプ：複数逐次；サイレントアワー 22:00～8:00、フォールバック再スケジュール |
| ウィンバック | START、ACTION、WAIT、DECISION、END | SendPushNotification、AddSegment | 実行タイプ：シングル；オーディエンスベースのトリガー |
ワークフローエンジンには、これらの各フローをカバーする60以上の出荷済みテンプレートが付属しています。各テンプレートは出発点です。上記のすべてのブループリントは、PushEngageプッシュ通知ワークフロービルダー内で、Shopify、Shopify Plus、WooCommerce、BigCommerce、またはMagentoに5分未満でインストールできます。
ワークフロー機能は、前のセクションでのマルチチャネルルーティングを可能にする意思決定ロジックとパーソナライゼーションステップもカバーしており、通知の送信以上のことができる11のアクションタイプをサポートしています。購読者属性の更新、CRMへのWebhookの起動、下流のワークフローの開始、または競合するワークフローの停止などです。
これらのワークフローが完全なeコマースリテンションプログラムにどのように適合するかをより広く理解するために、eコマースプッシュ通知ハブの投稿では、これらのブループリントが実装するキャンペーンタイプについて説明しています。
無料プランでは、200人の購読者、4つのチャネル（Webプッシュ、アプリプッシュ、WhatsApp、ライブチャット）すべて、および完全なワークフローエンジンを初日から利用できます。これは、予算計上する前にチャネルを証明するのに十分です。
これが変えること
この記事から何か一つ持ち帰るとしたら、それはこれです。eコマース向けのプッシュ通知自動化は、ワークフローアーキテクチャであり、トリガーキャンペーンの詰め合わせではありません。購入時に終了するカート放棄ジャーニー、初回購入行動に基づいて分岐するウェルカムシリーズ、各購読者に最も安価な実行可能なチャネルを選択するクロスチャネルオーケストレーションは、すべて同じ形状をしています。
1つのSTART、いくつかのWAIT、いくつかのDECISION、いくつかのACTION、1つのEXIT。スタンドアロンのトリガーが6つあっても、これはできません。1つのワークフローエンジンならできます。そこからリテンションの計算が積み重なります。
無料プランから始めると、1時間以内に最初のブループリントを出荷できます。
