customer-churn-signals

チャーンシグナル

ユーザー自身のアカウントでチャーンに先立って現れるシグナルを特定し、実務上の定義を定め、実際に観測された過去のチャーンと照合して検証し、優先順位を付けます。整理の軸となるのは、先行指標と遅行指標の違いです。

• 遅行指標（すでに起きたことを示す）：チャーン率、失われた MRR、低下する NPS。
• 先行指標（解約の数週間前に現れ、対応する時間を残す）：ログインの減少、機能の利用範囲の縮小、チャンピオンからの連絡が途絶えること。

候補を実用化する価値があるかどうかは、すべて次の 2 つの条件からなる実行可能性テストに合格する必要があります。

1. 誰かがまだ介入できるだけの早さで検知されること。
2. 誰かが実際に対応できること。

検知が遅いイベント、つまり支払い失敗、ダウングレードの申請、調達の遅延、更新日のずれは、数週間前に下された決定を明確にする確認用のトリガーです。これらは確認指標に分類し、先行指標には決して分類しないでください。

Lincoln Murphy の Success Milestones の考え方は、この取り組み全体における基本的な注意点です。利用は成功を意味しません。顧客自身の成果に向けた進捗を追跡してください。アカウントは「予想外の」チャーンの直前まで活発に見えることがあります。

このスキルの範囲は、優先順位付けと検証を済ませたシグナルレジスターの作成までです。シグナルを複合スコア（重み付け、スコア尺度、赤／黄／緑の区分）にまとめる場合や、シグナルに基づく CSM プレイブック、引き留めオファー、更新施策を作成する場合は、mbfinotti/revops-skills@customer-health-score を使用してください。パイプラインのステージ設計、販売前のリードスコアリング、営業から CS への引き継ぎも対象外です。

ヒアリング

何かを提案する前に質問してください。1 回のメッセージにつき質問は 1 つにし、可能な場合は選択肢を提示してください。すでに回答されている質問は省略します。

• B2B、B2C／消費者向けサブスクリプション、または両方の顧客を担当していますか？
• 過去 12～24 か月にチャーンしたアカウントはいくつありますか？これによって、実施できるランキング手法が決まります。バックテストとリフトの測定は少ないサンプルでも実施できますが、WoE／IV や回帰分析には十分なデータ量が必要です（ランキングの参考資料を参照）。
• 実際にアクセスできるデータソースとその粒度はどの程度ですか？プロダクトイベントストリーム、ログインログ、サポートチケットシステム、CRM の活動記録（ミーティング、メール）、請求記録、アンケートスコアなどです。アカウントごと・日ごとのデータがありますか、それとも集計値のみですか？
• 契約と更新の形態はどのようなものですか？月次セルフサービス、年次、複数年のいずれですか？一般的な更新サイクルの長さはどの程度ですか？
• 介入できる体制はありますか？フラグが立ったアカウントに誰が対応し、週あたり何件のフラグに対応できますか？誰も対応できないシグナルを優先順位付けする価値はありません。
• すでにヘルススコアがありますか？ある場合、まずその入力シグナルを実際のチャーンと照合して検証しますか、それとも新たにレジスターを作成しますか？
• レジスターはいつまでに稼働させる必要がありますか？次の更新サイクルまでに稼働させる必要がある場合、新たな計測が必要なシグナルや、保持曲線より下位の手法はすべて対象外になります。
• 一度きりの成果、つまり今四半期の更新を維持することが目的ですか？それとも、チームが継続的に再調整する資産を育てることが目的ですか？「継続的に育てる」場合は、構築の優先順位でプロダクトのテレメトリと機能採用の広がりを上位にします。「一度きり」の場合は、CRM 由来のレジスターにとどめます。
• 労力の上限はどの程度ですか？利用できるアナリストの時間、実際に確保できるエンジニアリング時間、リリース後にモデルを再調整する担当者の有無を教えてください。エンジニアリングの時間がなければ、プロダクトテレメトリのカテゴリは対象外になります。再調整する担当者がいなければ、サンプル数にかかわらずロジスティック回帰と Cox モデルは対象外になります。

何かを提案する前に、この 3 つの回答に基づいて候補の順序を再度決め、どの回答によってどの選択肢の順位が変わったのかを明示してください。ユーザー自身の制約に基づく根拠をたどれないランキングは、恣意的に見えてしまいます。

ワークフロー

1. インタビューを実施し、シグナルを提案する前にすべての回答を集めます。
2. 候補リストはreferences/signal-taxonomy.mdから作成し、そこに記載された効率順にカテゴリを検討します。最初にログインの直近性、最後にアンケートの変化を確認します。プロダクトがアカウントごとのイベントをすでに出力している場合を除き、プロダクトのテレメトリは6番目です。インタビューで対象外とされたカテゴリは、後で検討する候補として残さず削除します。確認用のトリップワイヤーは、最初からその旨を明記します。
3. すべての候補について、イベント、しきい値、観測期間、比較ベースライン、アカウント規模と季節性の補正を含む運用上の定義を記述します。5つの要素のいずれかを欠くシグナルは検証できません。定義を修正するか、候補を削除してください。
4. 解約したアカウントのリストを取得し、解約前30／60／90日時点で各候補がどのような状態だったかを再構成します（エンタープライズ向けの営業プロセスでは120〜180日まで延長します）。データを直接クエリできる場合は計算し、できない場合はユーザーが実行するクエリまたはスプレッドシートの手順を提示し、その結果をもとに作業します。
5. references/ranking-methods.mdに従い、各候補について、ベースレートに対する解約率のリフト、リードタイムの中央値、カバレッジを順位付けし、その候補の導入コストで割ります。同ファイルに記載された順序で手法を実行します。まずバックテストとリフトを行い、レジスターが基準を満たしたら終了します。インタビューでのサンプルサイズとメンテナンスに関する回答で対象外とされた手法は、努力目標として残さず削除します。リードタイムはシグナルの強さと並ぶ、最重要の順位付け属性です。解約の数日前にしか発火しない強力なシグナルより、90日前に発火する弱いシグナルを優先します。
6. サバイバーシップを確認します。解約したアカウントについて、残った候補は解約の60〜90日前に実際に発火していたでしょうか。解約したアカウントの大半で解約前もグリーンのままのシグナルは、予測因子ではなく盲点です。
7. レジスター（以下の形式）を埋め、Pass Thresholdに照らして各シグナルを ship／watch／reject と判定します。レジスターレベルの基準を満たすまで、定義、しきい値、期間を反復して調整します。
8. ユーザーとセクションごとにレジスターを検証し、採用したシグナルをmbfinotti/revops-skills@customer-health-scoreに渡して複合スコアを算出します。また、次の四半期の解約結果が得られる時期に再バックテストを予定します。
9. ハーネスに永続メモリがある場合は、承認済みレジスター（シグナル、定義、リフト、リードタイム、カバレッジ、判定、再バックテスト日）を記憶させ、以降の再調整ではインタビューをやり直すのではなく、これを出発点とします。

シグナルレジスター

すべての取り組みで、この成果物を納品します。記入例はreferences/examples.mdにあります。

CHURN SIGNAL REGISTER - <company/book>, <date>, v<n>
Base rate : <B>% of accounts churn per <window>; churned sample = <N> (<period>)
Method    : backtest + lift [+ retention curves | + WoE/IV] - in that order, stopping when
            the register cleared; name any method deleted and why (sample, no refit, deadline)
Rows      : ordered by value per unit of instrumentation effort

signal      : <name>
  category  : usage | adoption | seats | relationship | support | billing | survey | crm | context
  source    : <system category, e.g. product event stream>
  definition: event + threshold + observation window + baseline + normalization
  window    : <observation window>
  baseline  : <what normal is - account's own history and/or segment peers>
  lift      : of accounts showing this, <N>% churned within <window> vs base rate <B>% (<x.x>x)
  lead time : median days between first fire and churn
  coverage  : % of past churned accounts that fired this signal
  effort    : near-zero | an hour | a week | a quarter | a standing job - to instrument and keep alive
  confidence: evidence note - sample size, IV if computed, caveats
  verdict   : ship | watch | reject (confirmatory-flagged where applicable)

Register-level : % of past churns the shipped set would have caught at minimum lead time
Handoff        : shipped signals -> mbfinotti/revops-skills@customer-health-score

Pass Threshold

シグナルが「ship」と判定されるには、3つの基準すべてを満たす必要があります。以下の数値は、このスキルにおける実用上の最低ラインであり、調査に基づく定数ではありません。サンプル数が十分であれば、ユーザー自身のデータに基づいてより厳しく設定します。

• リフト：シグナルが出ているアカウントは、観測期間内にベースレートの少なくとも2倍の割合で解約します。これより小さな差では、実運用時のノイズに耐えられません。
• リードタイム：解約前の中央値が少なくとも30日です。調達サイクルのため介入に時間が必要なエンタープライズ向け／年間契約の営業プロセスでは90日とします。確認用のトリップワイヤーは例外ですが、確認用フラグを付ける必要があります。
• カバレッジ：過去に解約したアカウントの**少なくとも25％**で発火していること。実際の解約をほとんど検出できないシグナルは、リフトがどれほど強くても取るに足りません。

レジスターレベルでは、採用したシグナルを組み合わせて、過去に解約したアカウントの**少なくとも70％**で、最低リードタイム以上前に発火している必要があります。基準を満たすまで、しきい値や期間を調整し、カテゴリを追加し、セグメントを分割するなど反復します。既知の解約の大半を見逃すレジスターは採用しないでください。

B2B 対 B2C

• B2B 専用：推進役や経営幹部スポンサーの離職、複数の関係者が参加する購買委員会の力学です。B2C には、メンバーを失う社内委員会がありません。B2B の契約条件も、目に見える解約イベントを抑制し、遅らせます。年次契約では、不満を抱えた顧客も契約満了まで料金を支払い続けるため、行動上のシグナルは商業上のシグナルよりはるかに早く現れます。だからこそ、先行シグナルは重要性が低いのではなく、より重要になります。
• 共通の手法：利用状況やログインの減少、機能の採用範囲、サポートに対する感情は、B2B と B2C の両方で追跡します。変わるのは単位だけです。B2B ではアカウントとその委員会、B2C では個人のサブスク利用者です。
• B2C 固有：決済の失敗が解約の原因に占める割合はより大きくなります。解約は一人がワンタップで決められるため、リードタイムが短縮し、介入できる期間も縮まります。また、「無関心による解約」――存在を忘れられた低価格のサブスクリプション――に相当するものは B2B にはありません。

よくある失敗パターン

落とし穴	問題が生じる理由	対策
遅行指標を先行指標として採用する	解約率、MRRの損失、NPSの低下は過去を示します	すべてのシグナルを測定リードタイムで分類し、トリップワイヤーには確認用フラグを付けます
予測を伴わない相関	指標は解約前に変化しますが、解約を予測するわけではありません	バックテストで効果の向上を確認し、解約したアカウントへのインタビューで妥当性を確認します
比率による順位付けでテレメトリーシグナルが軽視される	プロダクトの利用状況と導入の広がりは、最も大きな効果と最も長いリードタイムをもたらし、計測にも最もコストがかかります。そのため、効率性だけを基準に作成したリストはすべてCRM由来の遅行指標になります。これは、CRMにすでに含まれる情報から生存者バイアスによって作られるリストと同じです	イベントがすでに存在する場合、取り組みの効果が積み重なる場合、または低コストのリストでは70%の基準に届かない場合は、テレメトリーを優先します。解約の60～90日前における解約アカウントのシグナル状態を確認します。その時点でも問題がなければ、盲点があるということです
サポートチケットの件数を一面的に見る	エンゲージメントの高い顧客はチケットを多く送りますが、静かに離れていく顧客はチケットを送りません	件数を深刻度、経過期間、感情と組み合わせ、急増後の沈黙を独立したシグナルとして扱います
NPS／CSATを強い予測因子として重視する	回答バイアスがあるため、静かに離れていく顧客はアンケートに回答しません	ユーザー自身のバックテストで別の結果が示されない限り、プロダクトエンゲージメントより下位に位置付けます
ベンダーからの連絡による影響	CSMがリスクのあるアカウントにメールを送ると、「エンゲージメント」が上昇します	顧客が自発的に行ったアクティビティのみを数えます
検証指標としての精度	解約する顧客は少ないため、「解約しない」と予測するだけでも高いスコアになります	何らかのモデルができたら、適合率／再現率とPR-AUCを使用します
少数の解約サンプルへの過剰適合	1回の訓練／テスト分割では誤った結論を招きます	1回の分割ではなくK分割を使用し、結果の観測期間を広げます
集計値に埋もれる静かな解約	アカウントごとの緩やかな減少は、全体レベルのレポートでは見えません	集計値ではなく、各アカウントをそのアカウント自身のベースラインと比較して追跡します

参考資料

• 候補リストを作成する際は、references/signal-taxonomy.mdを参照してください。計測にかかる労力あたりの価値で評価したカテゴリ、5つの要素からなる運用テンプレート、リードタイムの見込み、フレームワークのクレジット、確認用トリップワイヤーの一覧が記載されています。
• 検証と順位付けを行う際は、references/ranking-methods.mdを参照してください。手法の順序と各段階で得られるもの、サンプルが少ない場合やモデルが保守されていない場合に除外される手法、バックテストの仕組み、リフト、リテンションカーブの比較、解釈範囲付きのWoE/IV、PR-AUCが記載されています。
• レジスターを作成する際は、references/examples.mdを参照してください。B2Bレジスターの実例、簡潔なB2Cの例、リフトとWoE/IVの計算例、もっともらしく見える不適切なシグナルを分解した例が記載されています。
• 販売後のアカウントではなく販売前のリードを対象に、同じバックテストとリフトの検証ロジックを適用した例については、mbfinotti/revops-skills@lead-scoringを参照してください。