「アクティブ」の定義：ログイン記録か、機能利用か

「DAU は何を見ているか？」と聞かれて即答できる人は意外に少ない。ログイン？ ページビュー 1 件？ コア機能を 1 回でも使った人？── 定義が違うと、同じプロダクトで DAU が 2〜5 倍違うことが普通にあります。本記事では、DAU（Daily Active Users） の分母を決める作法を共有します。

「アクティブ」の 3 段階

業種別の推奨 active イベント

実装：active_event テーブルにマテリアライズ

全 KPI 計算で「active の定義」を都度書くと、定義のブレや SQL（Structured Query Language） の重複が発生します。`active_event` を 1 つのマテリアライズドテーブルにし、全 KPI クエリはこれを参照するパターンを推奨。

-- models/marts/active_event.sql{{ config(materialized='incremental', unique_key='id') }}
SELECT  CONCAT(user_id, ':', DATE(event_timestamp)) AS id,  user_id,  DATE(event_timestamp) AS active_date,  MIN(event_timestamp) AS first_active_at,  COUNT(*) AS event_countFROM {{ ref('events') }}-- ↓ ここがプロダクト固有の active 定義WHERE event_name IN ('message_sent', 'post_created', 'reaction_added'){% if is_incremental() %}  AND DATE(event_timestamp) >= (SELECT MAX(active_date) FROM {{ this }}) - 1{% endif %}GROUP BY user_id, DATE(event_timestamp)

「定義変更」の取り扱い

ふくふくの進め方

「DAU の定義をチームで揃えたい」というご相談には、プロダクト分析（1 週間）→ active イベント候補の特定 → SQL 実装と全 KPI への展開 → ドキュメント化を 2〜3 週間で。「同じ指標が部署ごとに違う数字」状態を解消するだけで、議論の質が劇的に上がります。

次回予告

EP.04 は継続率と コホート 分析。新規ユーザーの何 % が翌日 / 7 日後 / 30 日後に戻ってくるか、Cohort で割って見ることで打ち手の効果が見える話。