指標と分析

「アクティブユーザー」「継続率」などの指標は、人によって定義が違いがちです。定義がずれたままだと、同じ会議で違う数字を見て議論することになります。指標は文章と SQL の両方で定義を残し、誰が見ても同じ数字になるようにします。

定義の書き方（項目の例）：

• 名前と目的：何を判断するための数字か
• 定義の文章：「その日に記事を1本以上開いたユーザーの数」
• 含めないもの：社内アカウント・テスト・ボット・退会者
• 期間と時刻：日の区切りは日本時間か UTC か、週は月曜始まりか
• 数え方：人数（重複を除く）か回数か
• データの出どころと SQL、責任者、変更した日と理由

-- DAU：その日（日本時間）に記事を1本以上開いたユーザー数。社内アカウントは除く
SELECT event_date_jst, COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_name = 'article_view'
  AND is_internal = FALSE
GROUP BY event_date_jst;

Data の「指標の定義をそろえる」

KPI ツリーは、売上のような大きな目標を、掛け算や足し算で分解して、チームが直接動かせる数字にしたものです。施策がどの数字を動かすのかがはっきりし、優先順位を比べやすくなります。North Star Metric は、ユーザーが価値を受け取ったことをいちばんよく表す1つの数字（例：音楽アプリなら「聴いた時間」）で、全員が向かう先として使います。

ダッシュボードの数字は、本番の DB（注文や会員の記録）と行動ログ（画面を開いた・ボタンを押した）を、分析用の倉庫である DWH（データウェアハウス）に写し、集計して作られます。分析のために本番の DB に重い問い合わせをすると、サービスが遅くなるので、分けているのです。

「昨日の数字が今朝と昼で違う」のは、ログが遅れて届いたり、集計が途中だったりすることがよくある原因です。

新しい機能の効果を測るには、出す前にどんな行動ログ（イベント）を取るかを決め、仕様に入れておきます。出してから「測れていなかった」と気づくと、取り直すまで判断ができません。

{ "event": "search_submitted",
  "user_id": 123, "time": "2026-11-12T10:05:00+09:00",
  "props": { "keyword_length": 4, "result_count": 12, "screen": "top" } }

計測の仕様は、指標の定義（どの式で何を数えるか）から逆算して決めます。名前の付け方をチームでそろえておくと、後で集計しやすくなります。

集計の SQL が読めると、ダッシュボードを待たずに自分で数字を確かめられます。基本は3つです。SELECT で出す列を選び、WHERE で行を絞り、GROUP BY でまとめて数えます。

-- 先月の、プランごとの注文数と売上
SELECT plan, COUNT(*) AS orders, SUM(amount) AS sales
FROM orders
WHERE ordered_at >= '2026-10-01' AND ordered_at < '2026-11-01'
GROUP BY plan;

ラボで実際に SQL を流して試せます。

JOIN で数字が膨らむ罠

注文（1行）と注文明細（商品ごとに複数行）を JOIN してから注文の金額を SUM すると、明細の行数だけ同じ金額が足され、売上が実際より大きくなります。ダッシュボードの売上が経理の数字より大きいときに、まず疑うところです。

コホートは「同じ時期に始めた人のまとまり」です。登録した月ごとに、何か月後まで使い続けているか（継続率）を並べると、改善が効いているか、どこで離れているかが分かります。全体の利用者数だけを見ると、新しく来た人の多さに隠れて、離れていく人に気づけません。