ログインやクリックの回数は、誰かがプロダクトを操作していることを示す場合があります。しかし、それだけでは機能が問題を解決しているとは証明できません。改善の優先順位を決めるには、SaaSの利用指標を観察可能な行動とプロダクトに関する問いに結び付ける必要があります。つまり、誰が機能を使っているのか、どのくらいの頻度か、どのような状況か、どこでフローを離脱するのかを把握します。
有用な計測は、コードを書く前から始まります。イベントが意思決定に役立たないのであれば、おそらくノイズです。目的は、記録できるあらゆる操作を記録することではありません。導入状況を理解し、摩擦を検出し、施策によって期待した行動が変化したかを確認できる、一貫したシグナルを構築することです。
イベントではなく意思決定から始める
まず、何を明らかにしたいのかを問いとして定義します。たとえば、「最初の14日間にインテグレーションを設定したアカウントの割合は？」は、「インテグレーションのボタンは何回クリックされたか？」よりも具体的な行動につながります。前者は対象集団、行動、期間を定義しますが、後者が示すのは活動量だけです。
各指標について、次の内容を記録します。
- 意思決定：シグナルが上昇、低下、または横ばいの場合に、チームが何を変更する可能性があるか。
- 対象集団：どのユーザー、アカウント、プランを含め、何を除外するか。
- 行動：意味のある利用として数える観察可能な操作は何か。
- 期間：観測期間はいつ始まり、いつ終わるか。
- 限界：その指標から何を結論づけることはできないか。
結果を見ても優先順位、仮説、調査内容が変わらないのであれば、今すぐ計測する必要はありません。一方、離脱に関する問いに答えるには、全般的な活動カウンターではなく、フローの開始イベントと完了イベントが必要になる場合があります。
安定したスキーマでイベントを定義する
イベント名は理解しやすく、プロダクトと開発の間で定義が共有されている必要があります。実用的な構成には、名前、実行主体、関連するアカウント、発生時点、最低限のコンテキストが含まれます。たとえば、report_export_completedは、エクスポートが正常に完了したことを意味するべきです。ボタンが表示されたことや、リクエストが始まったことを意味してはいけません。
許可するプロパティとその型も記録します。例として、アカウントの内部ID、エクスポートの種類、結果などがあります。actionのような曖昧な名前や、異なる概念が混在する自由入力値は避けてください。イベントの意味が変わる場合は、変更を記録するか、スキーマのバージョンを導入します。そうしないと、レポートからは分からないまま、異なる行動が過去の時系列データに混在する可能性があります。
イベントを発生させるタイミングを正確に定義します。完了を測定する場合は、処理を実行する前ではなく、結果を確認した後にイベントを送信してください。非同期処理では、開始、成功、失敗の各段階が異なる問いに答えるのであれば、それぞれを分けます。キューに登録しただけの処理を「完了」と呼んではいけません。
ユーザー、アカウント、フローを分ける
B2B SaaSでは、個人と企業アカウントは同じ分析単位ではありません。ユーザーは組織に所属でき、複数のユーザーがそのアカウントから機能を利用できます。アカウント単位の導入状況は、機能を取り入れた組織の数を示します。個人単位の活動状況は、誰がどの程度の頻度で利用しているかを示します。どちらも有効な視点ですが、同じ分母に混在させてはいけません。
たとえば、コラボレーション機能を評価する場合、対象となるアカウントのうち、有効な操作を1回以上行ったアカウントの割合と、各アカウントで参加したユーザーの実人数を別々に測定できます。「対象となる」の定義も明確にしてください。その機能を利用できないアカウントは、未導入として扱うべきではありません。また、複数のワークスペースを持つアカウントや、所属組織が変わるユーザーをどう扱うかも決めておきます。
フローを理解するには、開始、検証、完了など、観察可能なステップを定義します。一貫した識別方法を用いて、各段階に到達したエンティティ数を比較してください。フローに入った対象集団、完了までどのくらい待つか、再試行や未完了の処理をどう扱うかが分からなければ、離脱率を正しく解釈できません。
重複や利用を表さない活動を防ぐ
ブラウザーがリクエストを再試行した場合、キューがメッセージを再処理した場合、またはクライアントが確認応答を受け取らないまま呼び出しが終了した場合、同じ行動が二重に記録されることがあります。必要に応じて冪等性キーまたは操作の一意な識別子を使い、分析システムでどのイベントを集計対象となる業務上の操作とするかを定義してください。
人による操作と自動タスクを分けます。スケジュールされた同期、メンテナンスジョブ、内部呼び出しによって、ユーザーに帰属する利用量が増えてはなりません。自動処理の活動も測定する必要がある場合は、実行主体または発生元の種類を別にラベル付けし、人による導入指標から除外してください。
招待、退会、ユーザーの統合、アカウントの移行など、IDの変更にも対処する必要があります。メールアドレスを恒久的な識別子として使うのは避け、分析上のIDに一貫したルールを定めてください。通常、内部の仮名化されたIDのほうが安定しており、個人データの露出も抑えられます。
ビジネスロジックと分析を疎結合にしてPHPで計測する
操作を許可するかどうか、またその結果がどうなるかは、ビジネスロジックが決定する必要があります。分析は結果を記録しますが、結果を左右してはいけません。分析プロバイダーへの呼び出しに失敗しても、通常はユーザーがエクスポートを完了したり、変更を保存したりする処理を妨げるべきではありません。
PHPアプリケーションでは、関連する操作の完了を確認した後にアプリケーションサービスからイベントを発行し、信頼性が求められる場合はキューなどの疎結合な仕組みを通じて送信できます。業務トランザクションと記録の整合性が重要であれば、outboxパターンを検討してください。変更とともに未送信イベントを保存し、その後に公開する方法です。適切な選択は、損失のリスク、ボリューム、アーキテクチャによって異なります。すべてのプロダクトで同じ複雑さが必要なわけではありません。
コントローラーごとに異なるプロパティを持つイベントをばらばらに作るのではなく、スキーマと規約を一元化します。制限と検証を適用し、機微なペイロードをそのまま出力せずに配信エラーを記録し、ビジネスルールが分析の応答に依存しないようにしてください。
データを最小限に抑え、計測を検証する
定義した問いに答えるために必要なデータだけを収集してください。パスワード、文書の内容、トークン、決済データ、自由入力テキストを分析システムに送信してはいけません。個人情報を明らかにする可能性のある識別子やプロパティを確認し、役割に応じてアクセスを制限するとともに、目的や適用される義務に沿った保持ポリシーを定めてください。
指標を信頼する前に、成功、検証エラー、再試行、二重送信、権限のないユーザー、自動処理などの具体的なシナリオでイベントをテストします。イベントが1回だけ記録されること、想定した実行主体とアカウントが含まれること、正しいタイミングで発生することを確認してください。ボリュームの急激な減少、プロパティの欠落、エラー率の変化を検出する運用上のチェックも追加します。
コードをデプロイしたら検証が終わるわけではありません。サンプルの記録と実際の操作を照合し、レポートのフィルターや分母を検証し、スキーマの変更を確認してください。数値の急増は、導入状況の改善ではなく、新しいインテグレーション、重複記録のバグ、IDの変更が原因かもしれません。
シグナルを解釈し、検証につなげる
トレンドやコホートを使うと、登録日や機能の初回利用など、共通条件で定義したグループを比較できます。期間、グループの規模、対象条件を必ず明記してください。変更後にコンバージョン率が改善しても、それは調査すべきシグナルであり、変更が改善を引き起こしたという自動的な証明ではありません。季節性、顧客構成、キャンペーン、同時に行われた変更が影響した可能性もあります。
観察結果を検証可能な仮説に変えます。たとえば、「接続を完了できないアカウントは、認可の段階で止まっている。具体的な手順を表示すれば、有効な接続が増えるはずだ」という仮説です。主要指標、エラーやサポートへの問い合わせなどのガードレール指標、評価期間をあらかじめ定義してください。可能であれば統制された比較を行います。難しい場合は、相関関係に基づく証拠を因果関係として示すことなく、トレンドをインタビュー、セッションの確認、インシデント分析と組み合わせます。
有用な指標は、何が起きたかを報告するだけでなく、次に何をするかを判断するのに役立ちます。各イベントの定義が明確なままか、実際の意思決定に引き続き役立つかを定期的に見直してください。そうすれば、分析はプロダクトとともに機能します。信頼できるシグナルを提供し、その限界を明示し、仮説を支持または反証できる検証を導きます。
