ログ設計は「後から細かくはできない、後から粗くはできる」という非対称性が支配する世界。3 年後の自分や後任を救う設計を、最初の 2 週間で固める価値があります。本記事では、命名規則・必須プロパティ・粒度の判断基準を共有します。
イベント名の命名規則
- snake_case：`item_acquired`, `payment_completed`
- verb_object 順：「動詞_目的語」が読みやすい（`acquired_item` ではなく `item_acquired`）
- 過去形で完了イベント：`item_acquired`（取った後の事実）
- 現在形で進行中イベント：`payment_initiating`（処理中）
- 特殊接頭辞は使わない：`evt_`, `track_` のような prefix は冗長
必須プロパティ（最低限の 5 セット）
| プロパティ | 型 | 用途 |
|---|---|---|
| user_id | string / null | 誰が（匿名なら null） |
| session_id | string | 1 セッション = 30 分無活動で区切る |
| event_id | uuid | 重複検出用、必ず一意 |
| timestamp_ms | int64 | ミリ秒精度のサーバー受信時刻 |
| app_version | string | v1.2.3 形式、バグ調査の起点 |
| device_id | string | プラットフォームによっては必須 |
| client_timestamp_ms | int64 | クライアント時刻、サーバーとの差分監視 |
粒度の決め方
クリック単位 vs 集約単位の判断は 「後から再現したい疑問の最小単位」で決める。例：「ボタンを連打したか」を見たいなら 1 クリック単位、「セッション内の総クリック数」だけ見たいなら集約 OK。
迷ったら「細かい方」
ストレージはタダ同然（ で 1TB あたり月 $20）。疑問が後から増えることは確実なので、最初は最小粒度で出して、必要なら集約。逆をやると詰む。
スキーマ進化のルール
- 新フィールド追加は OK：既存クエリは壊れない
- フィールド削除は NG：過去ログを再処理できなくなる、`deprecated` プロパティを付けて使わなくなるだけ
- 型変更は NG：string → int で過去データが壊れる、新フィールド作って移行
- イベント名変更は NG：旧名のまま残し、新名は別イベントとして並行
GA4 vs Mixpanel vs 直送
| 項目 | GA4 | Mixpanel | DWH 直送 |
|---|---|---|---|
| イベント数上限 | 500/プロジェクト | 無制限 | 無制限 |
| プロパティ数 | 25 / event | 100 | 無制限 |
| BigQuery 連携 | ネイティブ | 別途有料 | そのまま |
| 価格感 | 無料（GA4 360 で有料） | $1000/月〜 | BigQuery 利用料のみ |
| 向く規模 | 全規模（探索弱） | 中堅〜大手 | データチームが居る企業 |
ふくふくの進め方
「ログ設計を最初から固めたい」というご相談には、事業要件のヒアリング → イベント設計書 → 命名規則・必須プロパティ・粒度を 2 週間で。設計書はそのままエンジニアの実装仕様になり、後で揉めません。
次回予告
EP.11 はログ実装：GA4 / Mixpanel / 自社 DWH 直送の使い分け。ツール選定の判断基準と、フロント実装パターン。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。