ある日曜日、GMV2000万ドルのWooCommerceホームグッズストアでは、リテンションマネージャーがGoogleアナリティクスで先週のファネルを読んでいました。商品詳細ページビュー：180,000。カート追加：18,000。購入：1,800。Klaviyoダッシュボードタブには、先週のカート放棄から回収された3,200ドルが表示されています。
同じダッシュボードの閲覧放棄の線はゼロを示しています。なぜなら、Klaviyoは閲覧放棄者に到達できないからです。彼らのメールアドレスはキャプチャされていません。彼らは商品詳細ページを訪問しましたが、カートに追加せず、離脱しました。今週、162,000人の訪問者はメールでは見えません。
これは、WooCommerceの閲覧放棄プッシュ通知が作成されたオーディエンスです。ウェブプッシュのオプトインは、カート段階でのメールキャプチャではなく、最初の適格な訪問時にトリガーされます。この単一のタイミングの違いは、メールアドレスを入力しなかった閲覧放棄者にもまだリーチできることを意味します。
適切な離脱ロジックを備えた3通のメッセージワークフローは、これらのうち8〜14％をカート追加に転換させることができます。これは、訪問者数162,000人の週では、リテンションチームが次の損益計算書レビューで擁護できる項目です。この記事の残りの部分では、そのワークフロー、WooCommerceスタックでの正確なイベントインストルメンテーション、および3つのリストサイズでのリテンション計算について説明します。
閲覧放棄とカート放棄とセッション放棄は異なる
定義の明確化を簡潔に。SERPが3つを混同するため。閲覧放棄とは、30分以内にカートに追加されなかった商品詳細ページビューのことです。カート放棄とは、チェックアウトが完了しなかったカート追加のことです。セッション放棄とは、商品詳細ページに全く到達しなかった訪問のことです。それぞれに異なるトリガー、異なるオーディエンスサイズ、異なるワークフローがあります。
サイズの差がヘッドラインです。典型的な中規模WooCommerceストアでは、カート放棄者1人に対して閲覧放棄者は5〜8人います。カート放棄ファネルは、顧客がチェックアウト試行時にアドレスをキャプチャするため、メールで十分にカバーされています。閲覧放棄ファネルは、メールがキャプチャされなかったため、メールでは全くカバーされていません。これが、商品ページ放棄の回復がほとんどのリテンションスタックの静かで非経済的な部分であった理由です。プッシュは、オプトインイベントが最初の適格な訪問時にトリガーされるブラウザネイティブダイアログであるため、アドレス可能性の問題を解決します。
| ファネルステージ | トリガーイベント | GMV2000万ドルのストアでの典型的な週次ボリューム | ワークフローの継承 |
|---|---|---|---|
| セッション放棄 | page_view（いずれかのページ） | 非常に高い、ノイズが多い | 推奨なし |
| 閲覧放棄 | 30分以内にadd_to_cartがないpage_view（商品詳細） | 144,000 | この記事の閲覧ワークフロー |
| カート放棄 | 60分以内にpurchaseがないadd_to_cart | 18,000 | カート放棄ワークフロー |
ブラウズワークフローは、ブラウズ放棄者がカートに追加した瞬間にカートワークフローに移行します。この引き継ぎは重要ですが、ほとんどのブラウズコンテンツでは無視されています。2つのワークフローはイベント分類を共有し、3回目のタッチが発生すると、カートワークフローはブラウズワークフローから部分的に修飾された購読者を継承します。
なぜプッシュが閲覧放棄の唯一の実用的なチャネルなのか
Eメールにはメールアドレスが必要です。WooCommerceストアフロントのブラウズ放棄者には、まだメールアドレスがありません。PushEngageオプトインダイアログは、2回目のページビューまたは設定可能なエンゲージメントシグナルの後に表示され、承諾されると、アドレスを提供することなく、デバイスの寿命の間、購読者に連絡できるようになります。これが、ブラウズリカバリー自動化を経済的に実行可能にする運用上の前提です。WooCommerceプッシュ通知は、他のどのチャネルよりも、許容可能なコストで匿名訪問者にリーチします。
他の選択肢は、ブラウズ放棄の量で損益計算書レビューを乗り越えられない経済性を持っています。MetaおよびGoogle広告での有料リマーケティングは、CPMごとのインプレッション課金であり、コンバージョンしたかどうかに関わらず、再アプローチするすべてのブラウズ放棄者に対してCAC予算を消費します。SMSは電話番号を必要としますが、ブラウズ段階ではメールよりもさらに可能性が低いです。
EメールにはEメールが必要です。プッシュは、単一のオプトインの後、送信あたりのコストはほぼゼロです。200,000人の購読者のWooCommerceリストでは、ブラウズ放棄送信のマージナルコストは、メッセージごとの従量課金ではなく、プッシュサービスプロバイダーが配信インフラストラクチャに請求する数セントの断片に実質的に相当します。
リテンション/CACの計算はそこから導かれます。回収された収益が同じであれば、プッシュでのブラウズリカバリー自動化は、有料リマーケティングの代替手段のわずかな割合のコストで済みます。これがこの品目の根拠であり、WooCommerceストアは製品詳細ページが標準でpage_view追跡用に十分に計測されている傾向があるため、WooCommerceスタック上に存在します。
3通のメッセージによる閲覧放棄ワークフロー
ここに完全なワークフローがあります。トリガー：PushEngageカスタムイベントpage_view、製品詳細ページ（is_product = true）にフィルタリングされ、かつ30分以内にadd_to_cartが発生しなかった購読者。実行タイプ：複数並列、これにより、セッション中に5つの異なる製品を閲覧した購読者は、それぞれ正しい製品を対象とした5つの同時ワークフローインスタンスを持つことができます。終了基準：目標add_to_cart（カートワークフローが継承）、またはpurchase（それ以上のメッセージングは不要）。
ブループリント — 3通のメッセージによる閲覧放棄ワークフロー
- 開始：カスタムイベント
page_view、フィルタis_product = true、かつ同じ購読者からのadd_to_cartが30分以内にないこと - 待機：30分
- 決定1：購読者は現在サイトでアクティブですか（
session_activityフラグが過去5分以内に設定されていますか）？- YESパス：終了（アクティブなセッションを中断しないでください。ワークフローは新しいトリガーで再評価されます）
- NOパス：続行
- ACTION (メッセージ1): 表示された特定の商品をリマインドするウェブプッシュを送信します。タイトル：「まだ{{event.data.product_title}}を検討中ですか？」本文：「あなたが残した場所にあります。タップして受け取ってください。」URL：商品ページのURL。画像：
{{event.data.product_image}}。 - WAIT: 4時間
- DECISION 2: 購読者は商品をカートに追加しましたか？
- YESパス: EXIT (カート放棄ワークフローが引き継がれます)
- NOパス：続行
- ACTION (メッセージ2): 関連商品をウェブプッシュで送信します。タイトル：「当社の{{event.data.category}}コレクションから、こちらもいかがですか？」本文：「{{event.data.product_title}}に似た3つのピック。」URL：WooCommerceのカテゴリアーカイブページ。画像：最初の関連商品の画像。
- WAIT: 48時間
- ACTION (メッセージ3): ディスカウント発見のフレームワークでウェブプッシュを送信します。タイトル：「これに目を留めていましたね。」本文：「10%オフで取っておきました。コード：BROWSE10。」URL：割引コードが事前適用された商品ページのURL。
- 終了
これがブラウズ放棄ワークフローのすべてです。3つのメッセージ、2つの待機と決定、1つのサイレント終了分岐、2つの目標ベースの終了。メッセージ1とメッセージ3の商品閲覧通知は、それぞれ表示されたオリジナル商品をプッシュします。メッセージ2は関連商品に切り替わります。なぜなら、閲覧から4時間後にはリマインダー疲れが現実になり、発見がコンバージョンを促進するレバーになるからです。次の2つのH2は、まだ閲覧中の終了分岐と関連商品レバーについて詳しく説明します。なぜなら、それらはどちらもSERP上で最も大きな未解決の詳細だからです。
実行タイプに関する注記。ブラウズ放棄では複数の並列実行が正しいです。なぜなら、単一の購読者は40分間のセッションで5つの商品をブラウズ放棄する可能性があり、それぞれが独自のワークフローインスタンスと独自の製品コンテキストを持つからです。PushEngageワークフローエンジンは、インスタンスごとにentry_flagタイムスタンプを追跡するため、5つのインスタンスは衝突しません。このワークフローをシングルに設定した場合、5つの商品のうち1つだけがリカバリタッチを受け、残りの4つはサイレントになります。
「まだ閲覧中」の終了分岐
これは、キーワードのすべてのページ1の結果の中で最も見落とされがちな詳細です。ほとんどのブラウズ放棄記事では、30分後にメッセージを送信するように指示しています。そのアドバイスはアクティブな買い物客にノイズを生成し、チャネルを損ないます。31分時点でまだサイトにいる購読者は、現在見ている商品に関する通知を必要としません。セッションを完了させるために放っておく必要があります。
30分待機のDECISIONノードがこれを解決します。購読者プロファイルのsession_activityハートビート属性を読み取ります。属性のタイムスタンプが過去5分以内にある場合、ワークフローはサイレントに終了します。購読者はサイトにいることでペナルティを受けません。次にサイトを離れるとき、次の商品詳細ページビューがトリガーを再起動し、最新のコンテキストで新しいワークフローインスタンスを開始します。これは、ほとんどのチームが実装せずにリリースする、ブラウズ放棄ワークフローに追加すべき最も重要なことです。
実装は軽量です。PushEngage JavaScript SDKは、ページがフォアグラウンドにある間、5分ごとにハートビートカスタムイベントをトリガーできます。これは、WorkflowsエンジンのUpdateAttributeアクションを介してサブスクライバー属性に書き込まれます。DECISIONノードのオーディエンスフィルターは、次にsubscriber.attributes.session_active_atを読み取り、now() - 5minと比較します。オーディエンスフィルターは、PushEngage Workflowsのdecision-logicリファレンスに記載されています。
閲覧中の離脱に対するリテンションケースは直接的です。サイトにまだいる匿名ブラウズ放棄者は、アクティブな意図を持つユーザーであり、プッシュ通知は間違ったツールです。セッションを完了させることで、チャネルの配信可能性スコアを維持し、購読解除率を低く抑え、プッシュが実際に効果を発揮するセグメントにワークフローの送信を集中させることができます。ブラウズリカバリ自動化は、この規律によって成否が決まります。
関連商品レバー（メッセージ2）
メッセージ2は、サブスクライバーがすでに表示したのと同じ製品をプッシュしません。関連製品のキュレーションされたリストをプッシュします。なぜなら、元の閲覧から4時間後には、リマインダー疲れが生じており、顧客はすでに戻ってきたか、その特定のアイテムのために戻ってくるつもりがないからです。4時間マークでのレバーはリマインダーではなく、ディスカバリーです。
WooCommerceはこれを簡単にします。プラットフォームは、製品の分類に紐づいた組み込み関数としてwc_get_related_productsを提供しています。この関数は、アップセル、クロスセル、および表示された製品に関連するカテゴリ類似製品を返します。PushEngage WooCommerce統合プラグインは、これらをワークフローにイベントデータ変数として渡すことができるため、メッセージ2の通知は、別のAPI呼び出しなしで関連製品のタイトル、画像、URLをレンダリングできます。典型的なメッセージ2のコピーライン：「私たちの{{event.data.category}}コレクションから、こちらもどうぞ。」
これはWooCommerce固有の利点です。組み込みの関連製品分類を持たないプラットフォームのストアは、ワークフロートリガー時に関連性を計算する必要があります。これはカスタムレコメンダーサービスを意味します。WooCommerceストアはプラットフォームからこれを無料で取得できます。広範なSKUカタログを持つミッドマーケットのWooCommerceストアは、メッセージ2から最大の効果を得ます。なぜなら、関連製品のサーフェスが、サブスクライバーが実際に欲しい2番目の製品を見つけるのに十分広いためです。狭いカタログを持つストアは、ここでは効果が少なく、メッセージ2と3を24時間後の単一の割引ディスカバリータッチに統合する可能性があります。
リマインダーのみのブラウズ放棄はSERPのデフォルトであり、コンバージョン上限が低いため、パターンが重要です。ディスカバリータッチを追加すると、関連製品分類がすでに設定されているストアでは、ワークフローの回収カート率が30〜50％向上します。これは、ほとんどのWooCommerceのインストールで、マーチャンダイザーが知っているかどうかにかかわらず、そうなっています。
WooCommerceスタック上の閲覧放棄データ
3つのイベント入力がワークフローを強化します。それぞれがどこから来るのか、そしてゼロから始める場合のインストール順序を以下に示します。
イベント1、page_view と product_id。 PushEngage JavaScript SDK から、すべての商品詳細ページで発生します。最小ペイロードは { event_name: 'page_view', product_id: '...' } です。推奨ペイロードには product_title、product_image、category も含まれるため、ワークフローはこれらをメッセージ1、2、3で2回目のAPI呼び出しなしでレンダリングできます。ブラウズワークフローのトリガーがこれに依存するため、まずこれをインストールしてください。
イベント2、add_to_cart。 WooCommerce-PushEngage連携プラグインから発生します。これは woocommerce_add_to_cart WordPressアクションをフックします。ワークフローのDECISION 2（およびワークフローの終了基準）がこのイベントを読み取るため、2番目にインストールしてください。連携プラグインのインストールを遅らせても、ブラウズワークフローは実行されます。ただし、カートワークフローにスムーズに引き継ぐことができなくなります。
イベント3、session_activity ハートビート。 ページがフォアグラウンドにある間、5分ごとにPushEngage SDKによって発生するカスタムイベント。サブスクライバー属性 session_active_at を更新します。3番目にインストールしてください。ブラウズワークフローはこれなしでも正常に機能します。30分の待機時間は引き続き適用され、メッセージ1も引き続き発生しますが、閲覧中の終了分岐は発生せず、アクティブな買い物客がセッション中に通知を受け取る場合があります。これはオプションの仕上げステップです。
PushEngageプラグインがインストールされているほとんどのWooCommerceストアでは、オンボーディング中にイベント1と2を無料で取得できます。session_activityハートビートは、ワークフローを「良い」から「SERPで最高」に変えるオプションの3番目のイベントです。エンジニアリング作業を延期しているストアは、1週目にイベント1と2でワークフローをリリースし、3週目にハートビートを追加できます。
ワークフローごとの分析：ファネルを読む
PushEngageワークフローは、各ノードでキューに入れられた、完了した、および離脱したユーザーを追跡します。200,000人のサブスクライバーを持つWooCommerceストアで、週に約30,000件の商品詳細ページビューがある（例示的な数値）場合のブラウズ放棄のファネルは次のようになります。
| ノード | キューに入れられた | 完了 | 離脱 | メモ |
|---|---|---|---|---|
| 開始（page_viewフィルター） | 0 | 28,000 | 0 | 今週ワークフローに入ったサブスクライバー |
| 30分待機 | 850 | 27,150 | 0 | 通常のキュー深度 |
| 決定1（まだ閲覧中か？） | 0 | 21,800 | 5,350 | 5,350のアクティブセッションがサイレントに終了 |
| アクション メッセージ1 | 0 | 21,800 | 0 | リマインダー送信済み |
| 4時間待機 | 280 | 18,520 | 3,000 | 3,000人のサブスクライバーがカートに追加（カートワークフローが引き継ぐ） |
| 決定2（カートに追加されたか？） | 0 | 18,520 | 0 | 残りはすべて閲覧中のみ |
| アクション メッセージ2 | 0 | 18,520 | 0 | 関連商品送信済み |
| 48時間待機 | 600 | 16,300 | 2,220 | 今後2日間で2,220件がカートに追加 |
| アクション メッセージ3 | 0 | 16,300 | 0 | 割引発見送信済み |
| 終了 | 該当なし | 16,300 | 該当なし | カートに追加されなかった |
このファネルでは、ブラウズワークフロー中に5,220人の購読者（3,000人 + 2,220人）がカートに追加しました。これは、参加した28,000人に対するブラウズからカートへのコンバージョン率18.6%です。これらのカート追加のうち、カート放棄ワークフローはさらに一部を回復して購入につなげます。離脱率の高いノードは2つの待機ノードであり、これは予想されるパターンです。意思決定までの時間は、アクションウィンドウではなく、待機ウィンドウで発生します。DECISION 1での「まだ閲覧中」の離脱は、さらに5,350件のサイレント離脱したアクティブセッションをもたらします。この分岐がない場合、これらの購読者はセッション中にメッセージ1を受け取ることになり、チャネルの価値を損なうでしょう。
回収された収益の計算は、リストサイズに応じてスケールします。50,000人の購読者リストでの同じワークフローは、これらの数値の約4分の1を生成します。1,000,000人の購読者リストでは、約5倍を生成します。送信あたりのコストは全体を通してほぼゼロのままですが、これがチャネルの構造的な利点です。
| リストサイズ | 週ごとの商品詳細ビュー | 週ごとのブラウズ放棄者がワークフローに入る数 | 週ごとのカート追加回収数（18.6%） | 推定回収収益（AOV $85 × クローズ率15%） |
|---|---|---|---|---|
| 50,000 | 7,500 | 7,000 | 1,300 | $16,600 |
| 200,000 | 30,000 | 28,000 | 5,220 | $66,500 |
| 1,000,000 | 150,000 | 140,000 | 26,000 | $331,500 |
これらは方向性のある数値です。ストアでの実際の効果は、AOV、カテゴリミックス、および回収されたカート追加のクローズ率によって異なります。重要なのは、送信あたりのコストが増加しないまま、リストサイズとともに計算が複利で増加することです。
PushEngageワークフローで構築する
ブラウズ放棄ワークフローは、PushEngage Workflowsのコンポーネントに直接マッピングされます。マッピングは次のとおりです。
| ワークフローコンポーネント | 使用ノードタイプ | 使用アクションタイプ | ワークフローオプション |
|---|---|---|---|
| 3通のメッセージによる閲覧放棄ワークフロー | 開始、待機、決定、アクション、終了、完了 | SendPushNotification | 実行タイプ：複数並列；ゴールadd_to_cartまたはpurchaseで終了 |
Workflowsエンジンには、ブラウズやカート放棄を含むeコマースフローをカバーする60以上の出荷済みテンプレートが付属しています。ブラウズ放棄テンプレートは適切な出発点です。それをクローンし、WooCommerceのカテゴリと商品の変数を入れ替えれば、PushEngage Workflowsビルダー内で1時間以内にワークフローがライブになります。
これが変えること
このワークフローが完全なWooCommerceリテンションプログラムにどのように適合するかについてのより広範なコンテキストについては、eコマースプッシュ通知ハブがこのワークフローが実装するキャンペーンタイプをカバーしており、既存のブラウズ放棄キャンペーンの投稿は、より広範なトピックの戦略調査を提供します。兄弟のWooCommerceカート放棄ワークフローは、メッセージ1またはメッセージ2がカート追加を促進した瞬間に購読者を継承するため、ブラウズがライブになった後の自然な次のステップです。PushEngageカート放棄リカバリーシーケンスは、そこでのプレイブックの詳細をカバーしています。プッシュとメールを並行して実行するマルチチャネルチームの場合、マルチチャネルプッシュとメールの投稿は、オーケストレーションの問題に対処します。
この記事から1つの数字を挙げるなら、162,000です。これは、単一の2000万ドルGMVのWooCommerceストアにおける週次の閲覧放棄オーディエンスであり、そのほとんどは連絡可能なメールアドレスを持っていません。メールとSMSはこのオーディエンスには効果がありません。有料リマーケティングは、リテンションに対して複利でかかるCACコストで効果があります。WooCommerceの閲覧放棄プッシュ通知は、ほぼゼロの送信コストで同じオーディエンスにリーチし、午後に発送できるワークフローと、チャネルの配信可能性を維持する閲覧中のまま離脱する分岐を備えています。
リテンションの計算が、この項目を正当化するものです。上記のワークフローを持つ20万人の購読者リストの場合、典型的なミッドマーケットAOVsでの週次の回収収益は66,500ドル程度と予想されます。この数値はリストサイズに比例して増加し、送信あたりのコストはほぼゼロのままです。まず閲覧放棄ワークフロー、次にそれから引き継ぐカート放棄ワークフロー、そしてその2つを中心に構成されるWooCommerceリテンションスタックの残りの部分です。
無料プランでは、初日から200人の購読者、すべてのチャネル、および完全なワークフローエンジンを利用できます。これは、page_viewイベントを計測し、ワークフローを発送し、予算項目を要求する前に1週間ファネルを監視するのに十分です。このワークフローのメッセージ1を金曜日までに発送するために、無料プランから始めましょう。
