Granularity is the level of detail represented by each record or result. It answers: what does one row stand for? A row might represent a customer, a purchase event, a product, a city, or a traffic measurement at a particular location and time. Choose the level that directly supports the analytical question, then make every transformation consistent with that choice. section 3.1.1 section 8.3
Treat granularity as a design decision rather than a property to discover only at the end. Define the intended output first: a customer-counting model needs one row per customer, while product metrics need one row per product. Data at a more detailed level can be summarized; mixing detailed records into a higher-level model without aggregation can make the result unsuitable for its purpose. section 3.3.1 section 4.4.2
A practical approach to selecting and validating granularity:
- State the decision or metric to be produced and describe its required row unit, such as one row per city, customer, product, or day. section 3.3.1 section 2.2.1
- Inspect the raw data to establish its actual row unit and the columns that should identify a unique record. section 8.3 section 8.4.1
- Aggregate detailed data only with definitions that match the metric: counts, sums, and unique-user counts answer different questions. section 4.4.2
- Check whether gaps, inconsistent intervals, duplication, or missing coverage limit the analysis at the chosen level. section 8.1.2 section 8.4.1
- Revisit the level when stakeholder needs change; city, borough, regional, street, hourly, daily, and annual views can support different decisions. section 2.2.3 section 9.3.1
From purchase events to product metrics
Purchase data may contain one row per event, but a product comparison requires one row per product. Group purchase events by product ID and product name, then calculate volume as event count, revenue as price sum, and popularity as unique buyers. The aggregation rules matter: repeated cart events can alter a conversion denominator, so the chosen definition and any deduplication decision must be explicit. section 4.4.2
Time-series row units
For traffic counts, establish whether a row is unique by location, date, hour, direction of travel, and other relevant fields. This determines how records can be deduplicated and aggregated. Hourly observations may be summarized into a higher-level series, but the available granularity also limits what patterns can be studied: monthly data cannot reveal daily patterns. section 8.4.1 section 8.5
Table 3.2 The same football results in a long format, one row per match participant
|
Match ID
|
Date
|
Competition
|
Round
|
Team
|
Home or away?
|
Goals scored
|
|---|---|---|---|---|---|---|
|
1
|
2014-07-04
|
World Cup 2014
|
Quarter-final
|
France
|
Home
|
0
|
|
1
|
2014-07-04
|
World Cup 2014
|
Quarter-final
|
Germany
|
Away
|
1
|
|
2
|
2014-07-04
|
World Cup 2014
|
Quarter-final
|
Brazil
|
Home
|
2
|
|
2
|
2014-07-04
|
World Cup 2014
|
Quarter-final
|
Colombia
|
Away
|
1
|
|
3
|
2014-07-05
|
World Cup 2014
|
Quarter-final
|
Argentina
|
Home
|
1
|
|
3
|
2014-07-05
|
World Cup 2014
|
Quarter-final
|
Belgium
|
Away
|
0
|
Compare the row unit directly: the long football table changes from one row per match to one row per match participant, enabling participant-level analysis. section 3.1.1
Granularity involves trade-offs. More detailed raw data preserves options for later aggregation, whereas high-level summaries may prevent lower-level questions from being answered. Yet the most detailed level is not automatically best: noisy hourly series can be harder to forecast than smoother daily data, and stakeholder use determines the required detail and acceptable compromise. section 8.2.1 section 8.1.2
