カウンターメトリクス

英語名 Counter Metric
読み方 カウンター メトリクス
難易度
所要時間 30分〜1時間
目次

ひとことで言うと
#

主要KPIを改善する施策が「別の大事な指標を悪化させていないか」を監視するために設定する対になる指標。施策の副作用を早期に検知し、片方だけ伸ばして全体が壊れる事態を防ぐ。

押さえておきたい用語
#

押さえておきたい用語
カウンターメトリクス(Counter Metric)
主要KPIとトレードオフの関係にある指標。主要KPIが改善するとき、意図せず悪化するリスクがある指標を指す。
プライマリメトリクス(Primary Metric)
施策やA/Bテストで直接改善を狙う指標のこと。カウンターメトリクスはこれとセットで設定する。
ガードレール指標
カウンターメトリクスの一種で、特に「この数値を下回ったら施策を止める」という閾値付きの安全指標である。
トレードオフ
一方を改善すると他方が悪化する関係。施策設計ではこのトレードオフを事前に想定し、許容範囲を決めておく必要がある。

カウンターメトリクスの全体像
#

カウンターメトリクス:主要KPIと対になる指標で施策の副作用を検知する
Primary Metric施策で直接改善を狙う指標トレードオフ関係Counter 1CVR↑を狙うと客単価↓のリスクCounter 2速度↑を狙うと品質↓のリスクCounter 3獲得数↑を狙うとLTV↓のリスク判定ルールCounterが閾値を超えたら施策を停止・見直す
カウンターメトリクスの設計フロー
1
Primary選定
施策で改善を狙う主要KPIを決める
2
Counter特定
悪化しうる対の指標を洗い出す
3
閾値設定
許容範囲と停止基準を数値で決める
同時モニタリング
PrimaryとCounterを並べてダッシュボード運用

こんな悩みに効く
#

  • A/BテストでCVRは上がったのに売上が下がった経験がある
  • 施策の成功を1つの指標だけで判断してしまっている
  • KPI改善を追うあまり顧客体験が悪化していないか不安

基本の使い方
#

施策のPrimary Metricを明確にする

「この施策で何の数字を上げたいのか」を1つに絞る。

  • A/Bテストなら検定対象の指標がPrimary
  • 複数のKPIを同時に狙うと、どの改善がどの施策由来か判別できなくなる
トレードオフになり得るCounter Metricを洗い出す

「Primaryが上がると、代わりに何が下がるか?」を問いかける。

  • CVR↑ → 客単価↓: 値引きでCVRを上げると単価が下がる
  • エンゲージメント↑ → 離脱率↑: 通知を増やすとアクティブ率は上がるが嫌われて退会が増える
  • リリース速度↑ → バグ率↑: 開発スピードを優先すると品質が落ちる
  • 1つのPrimaryに対してCounterは1〜3個が目安
閾値を決めてダッシュボードで同時監視する

Counterの許容範囲を事前に数値で決め、施策開始後はPrimaryと並べてモニタリングする。

  • 「解約率が現状の1.5%から2%を超えたらこの施策は停止」のように定量化する
  • 閾値を超えたら自動アラートが飛ぶ仕組みがあるとなお良い

具体例
#

例1:フードデリバリーアプリが注文数を追いかけてNPSを崩す

月間注文数を 15% 伸ばす目標を掲げたフードデリバリーアプリ(MAU 80万人)。クーポン頻度を週1回から週3回に増やし、注文数は前月比 +18% を達成した。

しかし、カウンターメトリクスとして設定していたNPSが 42 → 31 に急落。クーポン目当ての低単価注文が増え、配達員の稼働が逼迫して配達時間が平均38分から52分に悪化していた。

指標施策前施策後閾値
月間注文数120万件142万件
NPS423135以下で停止
平均配達時間38分52分45分以下維持

閾値を超えたためクーポン頻度を週1回に戻し、代わりに高単価注文へのインセンティブに切り替えた。NPS35以下で施策停止というルールがなければ、さらに悪化してからの対応になっていたはず。

例2:SaaSのオンボーディング高速化が解約率を押し上げる

トライアル開始から初回設定完了までの時間を短縮する施策を実施した業務管理SaaS(従業員60名、契約企業800社)。設定ウィザードを大幅に簡略化し、初回設定完了率は 45% → 72% に跳ね上がった。

ところがCounterに設定していた「3ヶ月後の解約率」が 8% → 14% に悪化。ウィザードを簡略化しすぎて、ユーザーが自社に合った設定をしないまま使い始め、「思ったのと違う」と早期離脱していた。

設定ウィザードに「おすすめ設定」と「カスタム設定」の2パターンを用意し、前者で手軽にスタートしつつ後者で調整できるように修正。3ヶ月後解約率は 10% に落ち着き、初回完了率も 65% を維持できた。

例3:製造業が生産効率を追いかけて不良品率が上がる

自動車部品メーカー(従業員350名)。生産ラインの稼働率を 85% → 92% に引き上げる目標を設定。段取り替え時間の短縮と休憩時間の圧縮で達成を目指した。

Counterとして不良品率と労災件数を設定。稼働率は目標の 92% に到達したが、不良品率が 0.8% → 1.4% に悪化。段取り替え時間を削りすぎて金型の微調整が不十分なまま生産を再開していたことが原因だった。

不良品1個あたりの損失コストを計算すると月間 約280万円 の増加。稼働率向上による増産効果(月間約350万円)を半分以上打ち消していた。段取り替えの最低確認時間を5分確保するルールを追加し、稼働率を 90% に落としたうえで不良品率を 0.9% に抑えた。トータルの利益改善額はこちらの方が大きかった。

やりがちな失敗パターン
#

  1. カウンターメトリクスを設定しない — Primaryだけ見て「施策成功」と判断し、裏で顧客体験や品質が崩壊しているケース。施策開始前にCounterを必ずセットで決める
  2. 閾値を決めずにモニタリングだけする — 「なんとなく悪化してるけどまだ大丈夫」と判断が遅れる。停止基準を事前に数値で合意しておく
  3. Counterを多く設定しすぎる — 5個も6個もCounterを置くとモニタリングが形骸化する。本当にトレードオフになる1〜3個に絞る
  4. 施策停止後にCounterを外す — 一度問題が起きた施策を修正して再投入する際、「もう大丈夫」とCounterのモニタリングを止めてしまう。再発防止のためCounterは継続する

まとめ
#

カウンターメトリクスは「この数字を上げたいなら、代わりに何が下がるか?」を事前に考えて監視する仕組み。KPIを1つだけ見て判断すると、気づかないうちに別の重要な指標が壊れていく。Primaryを決めたらCounterもセットで設計し、閾値を超えたら止めるルールを持っておくことが健全な意思決定の土台になる。