初回購入・再購入・休眠顧客の復帰、どのキャンペーンから自動化すべきか

判断の出発点

登録者は増えたのに初回購入が少ない。購入した顧客が戻ってこないことも問題です。一方では、長くアクセスしていない顧客の名簿が蓄積しています。担当者がこれらを同時に運用できないなら、最初の自動化をどこに使うべきでしょうか。

現在の事業のボトルネックを対象とし、対象条件・データ・顧客に提供する価値・運用余力・効果検証の準備が整ったジャーニーを一つ選んで始めるのが適切です。 最大の名簿や作りやすいテンプレートを優先順位の代わりにしてはいけません。条件を満たす候補がなければ、対象を絞る、手動で仮説を確認する、自動化を延期するという選択もあります。

初回購入が目標でも、すぐに購入を促す必要はありません。登録者がサービスの価値をまだ体験していないなら、最初の利用を支援するジャーニーが先行候補です。反対に、初回購入の価値を確認した顧客が次の購入機会を逃しているなら再購入、過去に満足した顧客に新たな復帰理由を示せるなら休眠顧客の復帰が候補になります。以下では判断の枠組みと、異なる三つの組織の設計例を説明します。

名簿ではなく「今回案内できる顧客」を数えます

各候補に同じ質問をします。誰が、どのような理由で、今この案内を受けるべきでしょうか。 その問いに答えられるユニーク顧客数を比較します。累積登録者、インストール済み端末、過去の購入者全体をそのままキャンペーン規模として使いません。

ツールの集計単位も確認します。OneSignalでは一人のユーザーに複数の端末・チャネルのSubscriptionを紐付けられます。セグメント画面にはチャネル別の購読・受信拒否状態が表示され、一部の規模は推定値です。そのため、画面の数字を直ちに「メッセージを受け取る異なる顧客の人数」と解釈してはいけません。Users^[1]とSegments^[2]の文書がこの違いを説明しています。

実行対象を決める際は、顧客識別の重複を整理し、今回の対象条件とチャネル別の受信可能状態を確認したうえで、既に目標を達成した顧客や対応中の顧客を除外します。このとき、事業側で確認したマーケティング受信同意・撤回の記録と、ツール上の技術的な購読状態を別々に照合します。OneSignalのメールSubscriptionは、作成時に別途設定しなければSubscribedになります。その表示だけで同意記録の確認を代替しないようにします。Subscriptions^[3]

「購入イベントがない」という条件にも注意が必要です。実際の未購入とイベント欠落を区別できなければ、初回購入キャンペーンの対象資格自体が不確かです。同様に、アプリの記録が途絶えても別チャネルで購入を続ける顧客を休眠と分類してはいけません。この場合は配信規模を増やす前に、確認できるチャネル・商品・顧客へ範囲を絞ります。

実行できない候補を除き、ボトルネックに合う候補を選びます

次の表は予想収益の計算モデルではなく、編集部が提案する優先順位の判断枠組みです。点数を合算して順位を作るのではなく、対象条件やデータが不確かな候補を先に保留します。残る候補から、現在のボトルネックに直接作用し、チームが対応でき、結果を確認できるものを選びます。

判断が近い場合は、多くの人に送れる候補より、少ない仮定で始められる候補を先に検討できます。ただし、データが整っているという理由だけで事業の小さな問題に集中してはいけません。重要なボトルネックが明確でも自動化の準備が不足しているなら、その問題に関する小規模な手動検証とデータ補完を最初の仕事にできます。

同じ問いでも三つの組織の最初の選択は異なります

以下の組織・人数・状況はすべて設計例です。IXCの顧客事例、業界平均、実験に十分な標本数を意味しません。

登録が多い学習サービス：初回購入より初回の価値体験から

架空の学習サービスには、今回の検討期間に5,000人の登録者がいます。そのうち顧客識別と受信条件を確認でき、体験課題も決済も完了していない顧客は1,200人です。この例では、顧客インタビューで「何から試せばよいか分からない」という問題を確認したと仮定します。一方、再購入の対象は少なく、過去の離脱理由は分かっていません。

このチームの最初の選択は、体験課題を一度完了するための初期活性化ジャーニーです。有料商品の価値を判断する材料が足りない顧客に割引を示す代わりに、課題を始めるリンクと、つまずきやすい手順の案内を提供します。主目標は課題完了であり、初回決済は後続指標として分けます。活性化の増加を売上増加と解釈しません。

条件が変われば結論も変わります。始められない理由がログインエラーなら、キャンペーンより製品修正が先です。課題を完了した顧客も商品の価値を説明できないなら、案内を増やすより価値提案と製品体験を見直します。

初回注文が正常に履行されるコマース：狭い商品群の再購入から

架空のコマースには、初回注文の商品を正常に受け取り使用した後、次の購入をしていない顧客が800人います。受信条件を確認し、未解決の配送・返品問い合わせがある顧客を除いた人数です。この例では、特定の商品群の実際の使用・購入記録と顧客回答から、後続購入の機会を説明できると仮定します。休眠名簿全体はもっと大きいものの、古い商品コードと顧客識別が整合していません。

このチームはその商品群の再購入案内を先に選びます。案内時期は「配送後30日」のような業界共通ルールではなく、この事業が確認した使用場面と顧客が選んだ通知時期に基づいて決めます。在庫があり、次に提供する商品が適切かも確認します。

二回目の注文が発生しただけで成功とはしません。キャンセル・返金の反映方法を決め、特典費用と追加対応の負荷も確認します。後続購入の必要性を説明しにくい商品なら、再購入の自動化を保留して使用体験を確認する方が適切な場合があります。

戻る理由が生まれた予約サービス：休眠名簿全体ではなく特定の顧客から

架空の趣味教室の予約サービスには、過去の利用者10,000人の名簿があります。今回は、希望時間帯の授業がなくなってから予約をやめた顧客のうち、過去の反復参加と関心の記録があり、現在予約がなく、受信条件を確認できた300人を選びました。ちょうど希望の時間帯の授業が再開したと仮定します。

このチームの最初の選択は、新しい日程に合う顧客の復帰ジャーニーです。「長く来ていないのでクーポンを差し上げます」ではなく、「希望の時間帯にまた参加できます」という理由があります。目標は再アクセスではなく、実際の予約と参加の再開です。

ここで休眠を一律の未アクセス日数で定義しません。最後にどのような価値を得て、なぜ利用機会が途絶え、現在ほかの予約や利用があるかを併せて見ます。授業の供給が依然不安定で、過去の不満が解消されていないなら、このキャンペーンは始めません。

三つの例の最初の選択は、活性化、再購入、休眠顧客の復帰です。順番が異なる理由は名簿の大きさではなく、今変えられる問題と確認済みの根拠が異なるためです。

配信後の仕事に対応できてこそ自動化です

メッセージを自動配信しても、返信、例外処理、返金の問い合わせ、受信拒否の反映まで自動的に解決するわけではありません。最初のジャーニーを選ぶときは、「構築に何日かかるか」とともに「反応が来たら誰が何を処理するか」を決めます。

運用負荷計算の設計例：一回に500人へ配信し、問い合わせ率4%、一件の処理時間8分と仮定すると、想定される問い合わせ対応量は500人 × 0.04件/人 × 8分/件 = 160分、つまり2時間40分です。これは仮定に基づく作業量であり、実際の問い合わせ率の予測ではありません。配信前の検査、例外確認、状態修正、結果レビューの時間は別途必要です。担当者に余力がなければ、配信回を分けるか対象を減らします。

キャンペーン同士の衝突も考慮します。OneSignalのPush frequency cappingは一部の有料プランで提供されるプッシュ専用の制限です。メール・SMS・アプリ内メッセージを含む総接触回数の制限ではありません。制限されたプッシュが後で自動再送される待ち行列に入るわけでもありません。チャネルが増えるほど、事業で定めた総接触ポリシーと実際にツールが制御する範囲を別々に確認します。Push frequency capping^[4]

再エントリーと受信拒否も、機能名だけで判断しません。OneSignalのCustom Eventで始まるジャーニーでは同一ユーザーの同時エントリーが可能で、セグメント型の再エントリー設定とは適用方法が異なります。また、一つのチャネルを受信拒否しても、ジャーニーのほかのチャネルがすべて終了するとは限りません。運用担当者は、反復エントリーとチャネル別受信状態、事業が受けた撤回依頼の範囲を確認できる必要があります。Journey settings^[5]、Journeys overview^[6]

配信を止める担当者と権限も指定します。一人で運用する場合でも、問い合わせ対応と受信状態の確認ができない時間には新規エントリーを制限するなど、不在時の方針が必要です。

これらの確認が難しければ、最初から複数チャネルと多数の分岐をつながない方が合理的です。確認済みの対象、一つの目的、管理できる経路に絞ってから拡張します。手動検証も受信条件を迂回する方法ではなく、確認済みの対象に適切な提案を行えるかを確かめる段階です。

開始前に成功・停止・観察期間をまとめて決めます

「自動配信が正常に動いた」と「顧客行動が改善した」は異なる成功です。前者は運用検証、後者は効果検証です。クリック率は経路が機能するかを見る補助指標とし、最初のジャーニーの目的に合う行動完了を主要指標に選びます。

効果を区別するため、案内を受けない比較集団、つまりホールドアウトを設けられるか検討できます。Customer.ioのHoldout tests^[7]は、文面同士の比較と未配信集団との比較を区別し、ホールドアウトでは開封・クリックではなくコンバージョンを見るよう案内しています。OneSignalでもSplit Branchのメッセージを置かない経路を比較に使えます。ただし、同じ顧客の再エントリー時に再度ランダム割り当てするかなど、実際の設定を確認します。Journey actions^[8]

優先順位を決める段階で複雑な実験設計を完了させる必要はありません。ただし、目標行動を記録できるか、比較対象を維持できるか、判断に足る期間を観察できるかには答えられる必要があります。難しければ、最初の実行目的を「効果の実証」ではなく「対象・提案・運用可能性の確認」に限定します。

先ほどのコマースのチームが次のように決めたと仮定します。以下の期間としきい値はすべて設計例であり、推奨標準ではありません。

観察期間は、顧客に目標行動の機会が生じる時間、必要な対象者が集まる時間、キャンセル・返金とイベントの反映時間を併せて決めます。すべてを同じ日付で終了すると、遅く入った顧客には行動する時間が足りない場合があります。一方、結果が良く見えるまで恣意的に延長することも避けます。

注文数に少し差が見えたという理由だけで成功を宣言しません。標本が少なく不確実性が大きいなら、「運用は可能だが効果はまだ判断できない」と残せます。反対に、対象資格が誤っている、対応負荷が過大である場合は、購入が発生しても拡大しない選択ができます。Customer.ioの文書も、明確な勝者を判断できない結果があることを説明しています。

最初のジャーニーの目的は、次の判断を可能にすることです

最初の自動化候補を決めたら、一文で説明します。「この顧客にこの案内をすれば、今滞っているこの行動を支援でき、結果と副作用をチームで確認できる」。文を完成できない箇所が、データ補完、顧客確認、運用準備のどれを先にすべきか示します。

対象が少なく状態を直接確認できれば、既存ツールと手動検査だけで最初の仮説を確認できる場合もあります。顧客識別と注文データが複数システムに散在し、除外・対応・停止の責任者が不明確なら、キャンペーン数を増やす前にその接続を整理します。最初のジャーニーは、次を選ぶ根拠が残る程度に小さく明確であれば十分です。

最初のジャーニーを選んだら、OneSignal顧客ジャーニー設計ワークブックで、エントリー・除外・終了条件と検証項目を具体化できます。

現在のデータと目標に合う最初のジャーニーの検討が必要なら、IXCのCRMコンサルティング支援範囲を確認できます。