ローンチ後に何を測るべきか

ローンチすると、信頼すべき情報源が変わります。ローンチ前のプロダクト判断は、市場知識、直接得た根拠、明示した仮説に大きく依存します。ローンチ後は、稼働するシステム自身が行動と事業のシグナルを生み始めます。

問題は、データが少なすぎることではありません。入手できるすべての数値を、同じ価値があるように扱うことです。

アクティビティは成果ではない

クリックは、操作が起きたことを示します。その人が理解した、価値を得た、その結果に対価を払う意思がある、という証明にはなりません。

訪問は、ある画面へ到達したことを示します。意図した人が来たことや、有望な顧客関係につながったことまでは示しません。

ユーザー数は、定義に基づいてIDや端末が記録されたことを示します。継続利用の証明ではありません。

売上は、お金が動いたことを示します。それでも解約、サポート費用、返金、顧客集中、拡張できない運用プロセスを隠すことがあります。

各シグナルは、その限界を理解したときに役立ちます。

運用上の成果から始める

計測は、そのプロダクトが生み出すべき変化から始めます。

ワークフロープロダクトなら、受け入れ可能な形で業務が完了することかもしれません。コンシューマーアプリなら、有用なセッションが繰り返されること。社内システムなら、手作業の例外が減ることや、依頼から判断までの時間が短くなることかもしれません。

成果を平易な言葉で書き、そこへ近づいていると示すイベントを特定します。

有用な順序は次のとおりです。

1. ユーザーが必要な状態へ到達する。
2. 中核となる操作を試みる。
3. システムが操作を正しく完了する。
4. その結果の状態が価値を生む。
5. 同じ必要が生じたとき、ユーザーやオペレーターが戻る。

これにより、ダッシュボード部品の集合ではなく、意思決定モデルができます。

クリックは操作行動を説明する

クリック、タップ、入力変更、ナビゲーションイベントは、人がどこで行動し、どこで止まるかを理解するのに役立ちます。

次の問いに答えられます。

• 意図した操作は見つけられるか。
• 同じ操作が何度も試されていないか。
• ワークフローのどこで離脱するか。
• どの復旧経路が使われているか。

補足情報がなければ、なぜその行動が起きたかは分かりません。クリックの多い操作は、価値があるのかもしれませんし、分かりにくい、あるいは壊れているのかもしれません。

意味のある操作と失敗条件を計測してください。分析ツールで記録できるという理由だけで、すべての動きを収集しないことが重要です。

訪問は流入と再訪を説明する

訪問は、流入元、対象者、意図とつながったときに役立ちます。

少なくとも次を区別できる必要があります。

• 初めてプロダクトを評価する人。
• 作業へ戻ってきた既存ユーザー。
• システムを管理するオペレーター。
• 自動化された、または無関係なトラフィック。
• 特定の市場チャネルから来た人。

この区別のない総トラフィックは、プロダクトを改善せず、注目だけを増やす作業へ誘導することがあります。

ユーザーには正確な定義が必要

「アクティブユーザー」は、単なるログインやアプリ起動ではなく、プロダクト価値を表すべきです。

適切な定義はプロダクトによって異なります。レポートの完了、項目の公開、業務タスクの解決、ガイド付きセッションの完了、保存済みワークフローへの再訪などが考えられます。

数値の横に定義を書いてください。定義を変えた場合は、その履歴を残し、推移を解釈できるようにします。

売上には運用の文脈が必要

売上は強い事業シグナルですが、内訳が必要です。

• 新規、継続、拡張、返金、リスク状態のどれか。
• 購入前にどのプロダクト行動があったか。
• 提供にどれだけの手作業が必要か。
• 一社または一つのセグメントに集中していないか。
• 最初の支払い後も価値が続くか。

売上増加は投資を正当化できます。一方で、需要がさらに増える前に直すべき運用上のボトルネックを示すこともあります。

システムの健全性も含める

顧客指標と事業指標だけでは、ソフトウェアの運用が難しくなっているか分かりません。

運用画面には、次のようなシグナルも含めます。

• 中核ワークフローの失敗や遅延。
• 重複リクエストと照合作業。
• サポート介入。
• バックグラウンドジョブの滞留。
• リリース失敗と復旧時間。
• 外部サービスのエラー。
• オペレーターによるデータ修正。

これらは、約束した成果を引き続き信頼できる形で提供できるかを示す、プロダクトシグナルです。

すべての指標に対応を結びつける

指標を置くなら、次を説明できるようにします。

• どの判断に使うか。
• どの程度の変化を意味あるものとするか。
• 他にどの根拠が必要か。
• 誰が確認するか。
• どの行動が可能になるか。

数値が変わっても次の判断が分からないなら、それは運用ではなく報告です。

ローンチ後の目標は、完璧なダッシュボードではありません。実利用が次のプロダクト判断を変え、同時にシステムを理解可能で責任の明確な状態に保つ、短いフィードバックループです。