KPIは目標の追跡に選んだ指標です。数字だけでは原因、事業価値、安全性を証明できません。
計測の取り決めを記す
目的、式、単位、分子、分母、対象集団、期間を記録します。責任者と判断を明確にします。見込み客当たり費用と新規顧客獲得費用は異なり、費用の範囲と成果の定義が必要です。
変化を確認してから行動する
範囲、重複、利用可能になるまでの遅延、定義変更を確認します。率の平均が全体の率とは限らず、対応する件数を使います。閾値は調査のきっかけであり原因の説明ではありません。ツールは収集品質を保証しません。
| 項目 | 記録する確認内容 |
|---|---|
| 定義 | 式、単位、範囲を記録 |
| 品質 | 範囲、重複、利用可能性を確認 |
| 判断 | 責任者、行動、限界を明示 |
出典と確認
各KPIを契約と意思決定に結び付けます。
有用な指標は、変更によって正当化されるべきアクションを明確に示します。目標を設定する前に、計算式、母集団、ソース、および数値が不完全になる条件を文書化します。ダッシュボードは定義に正しく従っていても、単位や範囲が異なるとビジネス上の疑問に答えられない場合があります。
- 分子、分母、および除外条件を記述します。
- イベントからチャートへの既知のケースを確認します。
- 最新の更新情報と、まだ不完全な期間を表示します。
一次資料：Google SRE — Data Processing Pipelines. 関連する方法：実践ガイドを読む.
KPIにコンテキストを与えます。
パーセンテージKPIには、単位、カウント、および期間が必要です。同じ値でも、実際には全く異なる量や不確実性を表す場合がある。
- 比率とともに分子と分母を公表すること。
- 解釈を行う前に、部分的なデータ収集と欠落している対象者について記録してください。
一次資料：NIST/SEMATECH — Confidence intervals for proportions. 関連する方法：実践ガイドを読む.
データ結合の整合性
結合による行の増加が合計値を歪める場合があります。
- 注文テーブルの1行は注文、明細の1行は注文内の商品を表します。結合前に重複キーとNULLキーを確認します。
- 明細を注文キーごとに集約します。その結果と結合すれば、商品ごとに注文金額が繰り返されません。元の注文テーブルの合計と照合します。
- LEFT JOINは明細のない注文を残しますが、右側テーブルへのWHERE条件はその注文を除外する場合があります。対応する行がないことと金額ゼロは別です。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"orders": [
{
"id": 1,
"total": 100
},
{
"id": 2,
"total": 200
}
],
"line_order_ids": [
1,
1,
2
],
"sum_before": 300,
"sum_after_raw_join": 400
}期待される判断
400は注文を二重計上しています。注文ごとに明細を集約し、合計300に戻します。 追加で、各100の架空の注文を2件試します。合計は200です。SUM(DISTINCT total)では100となり、正しい値が消えます。金額の重複排除ではなく、識別子と結合の対応件数を確認します。
再現できるSQLクエリ
架空例：金額100と200の注文2件と、注文1、1、2に対応する明細3件。クエリはVALUESだけを使います。テスト環境で実行してください。
WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
SELECT order_id, COUNT(*) AS line_count
FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;直接結合すると3行で合計400になります。先に集約すれば2件の注文と合計300を得られます。
WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
SUM(DISTINCT total) AS distinct_total
FROM orders;金額が100と100の場合、正しい合計は200ですがSUM(DISTINCT total)は100です。
検証手順
- 注文と明細の粒度を定めます。
- 2明細の注文を結合します。
- キー、件数、照合済み合計を残します。
SUM(DISTINCT total)だけで直せますか？
いいえ。100の注文が2件あれば合計は200ですが、SUM(DISTINCT total)は100になります。金額の重複排除ではなく、キーの関係を修正します。
一次資料：PostgreSQL — Table expressions and joins. 関連する方法：実践ガイドを読む.