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

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

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

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

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

もう一つ、イベントは増やしすぎないことです。全部のクリックを取ろうとすると、ダッシュボードが情報の山になり、誰も見なくなります。最初に置くのは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段階、規律が厳しくなります。イベントプロパティに入れてはいけないものがあります。

症状名・疾患名・検査値・服薬内容。記事のスラッグが疾患名を含む場合も同じ扱いで、スラッグをそのまま送らず、IDに変換してから送ります。年齢は実数や生年月日ではなく年代のバケットにします。自由入力テキスト、つまりチャット本文や検索クエリの生の文字列も送りません。施設名と診療科の組み合わせのように、個人と結びつく可能性がある情報も避けます。

送ってよいのは、画面ID・機能ID・カテゴリの大分類・滞在時間・到達フラグです。

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

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

AMPLの基準実装はminatonです。PostHogでプロダクト分析(ファネル・リテンション・イベント)を取り、GAで流入と検索の見え方を追っています。両方が必須なわけではありません。プロダクト分析が要るならPostHog、集客の可視化だけで足りるならGAだけで十分です。

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

• 各イベントが実際に飛んでいるか、本番で1回ずつ自分の手で踏んで確かめる
• signupからsubscribeまでのファネルが1画面で見えるか
• 医療プロダクトなら、送信されるペイロードを実際に開いて、禁止したプロパティが紛れていないか目で見る

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

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

minatonはPostHog・GA・web_vitalsが入った基準実装で、⑪計測まで到達しています。値付けだけが空です。pediaは第三者の分析SDKではなく自社計装(lib/analytics.tsからSupabaseのeventsテーブルへ)で持つ方式を選び、決済ファネルのイベントを追加した段階です。tokyo-speedはPlausibleを使う宣言だけがコードにあり、実際には接続されていません。課金を再開する前に、ここを埋める必要があります。

計測を実装と同時に入れるべきだった、で終わる話ではありません。入れていないことに気づいた時点で、次の機能から入れ始めれば追いつけます。止まっていた時間を悔やむより、次のプルリクエストにイベントを1つ同梱することの方が意味があります。

今日のまとめ

3行で振り返ります。

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

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