計測は実装と同時に入れる

前のレッスンで、続ける条件と止める条件を3行で書きました。その条件を判定日に確かめるには、数字が要ります。ここで計測を入れます。

後付けのイベント設計は、必ず穴が開く

機能を作り終えてから「計測もついでに入れよう」とすると、たいてい失敗します。どの画面で何が起きたかを一番よく覚えているのは、作った瞬間の自分だけだからです。

だから計測は、機能のプルリクエストにイベント送信のコードを同梱します。ボタンを実装したら、そのクリックイベントも同じコミットに入れる。この順番を守れば、後から穴を探す作業が消えます。

イベントは増やしすぎないことも大事です。全部のクリックを取ろうとするとダッシュボードが情報の山になり、誰も見なくなります。最初に置くのは6個だけです。

手順1: North Starを1本決める

「このプロダクトは機能しているか」を、1つの数字で言えるようにします。売上でも登録者数でもなく、ユーザーが価値を受け取った回数です。

学習系なら「週あたり、演習セッションを最後まで終えた人数」。情報参照系なら「週あたり、記事を読み終えて次の行動に進んだ回数」。開いた回数ではなく使い切った回数を数えます。

North Starは1本に絞ってください。複数持つと優先順位が割れます。

手順2: activationを定義する

計測設計の中で、一番重要な1行です。

activationの定義: 初回◯◯日以内に、△△をN回した

「初めて開いた人が、価値に到達したと言えるのはどの時点か」を観測できる形で書きます。「なんとなく使ってくれた」ではなく「初回セッションで演習を1問解いた」のように、数えられる条件にします。

この定義がないと、次のレッスンで扱う無料枠の設計ができません。無料枠は活性化に必要な最小回数から逆算するからです。推測で埋めず、初期ユーザーの実データで確定させてください。

手順3: コアイベント6個

命名は object_action の形でスネークケースに統一します。

signupからsubscribeまでを1本のファネルとして見ると、どの段階で人が離れているかが分かります。

加えて、原価ログを別系統で持ちます。input_tokens output_tokens model action user_id を、分析ツールではなく自前のDBかログに記録します。次のレッスンで原価から値をつけるとき、この記録が要ります。分析SaaSにトークン数まで送る必要はありません。

医療プロダクトの追加規律: PHIをイベントに乗せない

minaton・pedia・愛育系のように医療に触れるプロダクトは、ここで1段階、規律が厳しくなります。イベントプロパティに入れてはいけないものがあります。

分析SaaSの多くは海外サーバーにデータを保存します。「患者情報を扱わない」という前提が崩れると、医療機器該当性や3省2ガイドラインの適用外という立て付けが揺らぎます。計測の便利さで、この一線を越えてはいけません。

実装の基準と、置いた後の確認

AMPLの基準実装はminatonです。PostHogでプロダクト分析、GAで流入と検索を追っています。両方必須ではなく、プロダクト分析が要るならPostHog、集客の可視化だけならGAで十分です。

イベントを置いたら、次の3点を確認するまで「計測を入れた」とは言いません。

いまのAMPLで、計測が揃っているものと空いているもの

同じ会社の中でも、計測の状態はプロダクトごとにばらばらです。

計測を実装と同時に入れるべきだった、で終わる話ではありません。気づいた時点で次の機能から入れ始めれば追いつけます。

今日のまとめ

• North Starを1本、activationを観測できる形で定義してから、コアイベント6個を機能と同じコミットで入れる
• 原価ログは分析ツールと別系統で持ち、医療プロダクトのイベントには症状・検査値・自由入力テキストを乗せない
• 計測は「入れた」で終わりではなく、本番で1回ずつ踏んでファネルとペイロードを目で確かめるまでが工程

次のレッスンでは、この計測とログをもとに、原価の裾から値をつける手順に進みます。