粒度は、データをどの単位で1行（1レコード）として扱うかを示す考え方です。たとえば「1注文」「1注文明細」「1ユーザー×1日」「1セッション」「1イベント（クリック）」のように、集計や結合の前提になる最小単位を決めます。粒度がズレると重複カウントや欠損が起きやすく、指標の解釈もぶれやすいでしょう。
粒度設計は、分析や運用で必要な判断を起点に、最適な単位を決めてデータモデルへ落とし込む作業です。まず「誰が何を判断するためのデータか」と「KPIの分母・分子が何の単位か」を固定し、ファクトテーブルの粒度を決めます。次に、その粒度を一意にするキー（例：注文ID＋明細番号、ユーザーID＋日付、イベントID）と、時刻の基準（イベント時刻か処理時刻か）を明文化しておくと再現性が上がります。ログやイベントは後から用途が増えがちなので、最初から過度に粗くせず、下流で集計できる形を残す設計が堅実でしょう。
運用で詰まりやすいのは、粒度が粗すぎて原因分析に必要な切り口が出せないケースと、粒度が細かすぎてコストやクエリ性能が破綻するケースです。粒度が混ざったまま結合すると多重化で数値が膨らむため、結合前に集計単位をそろえる、ブリッジテーブルを置くなどの対策が必要になります。スナップショット（ある時点の状態）とイベント（発生ログ）は混同しやすく、同じKPIでも「いつの状態で計算するか」が変わる点に注意が要ります。粒度、キー、集計ルールをメタデータとして残し、テストで重複や欠損を検知できる状態にすると、数字の信頼性が落ちにくいでしょう。
