Determining a Dataset’s Observation Grain

Hello! In the last lesson, you defined a purchase-rate KPI by specifying which sessions belong in its numerator and denominator. Before calculating that rate, you need to know what each row of the source data represents. Is it a session, a page view, an order, or something else? Confusing those units can produce a plausible-looking but incorrect KPI.

Today you’ll learn to state a table’s observation grain in one sentence and check that the rows support your claim. We’ll use storefront examples and two short work-alongs. Allow about 40 minutes.

The question to ask of every table

A table’s grain—also called its granularity or level of detail—is what one row represents. A useful grain statement starts, “One row per…” and finishes with the full unit being recorded.

For example, “one row per order” differs from “one row per product on an order.” An order containing three products occupies one row in the first table but may occupy three rows in the second. Neither structure is inherently wrong; they support different calculations.

Read the brief explanation in Tableau’s Structure Data for Analysis. Focus on its question about what a row represents, rather than on Tableau-specific features.

The grain is a business description, not merely a column name. A column called OrderID does not prove that each row is an order: the same ID could appear on several product lines. Conversely, a table can have a clear grain even when it lacks a convenient single-column identifier.

Watch the examples in Data Modeling Grain Explained by Data with Baraa. The first segment compares product lines, whole orders, and monthly totals. The later segments show what can go wrong when a calculation ignores the row’s unit.

Work-along: two storefront tables, two grains

The image below contains a small Customers table and an Orders table. Spend about 8 minutes inspecting them before reading the interpretation beneath it. Write a “one row per…” statement for each table, then check what repeats and what remains unique.

In Customers, each row describes a customer. CustomerID values 1 and 2 occur once each, supporting the statement one row per customer.

In Orders, each row describes an order. OrderID values 101, 102, and 103 occur once each, supporting one row per order. CustomerID 1 appears twice, but those are not duplicate order rows: customer 1 placed orders 101 and 102. The shared CustomerID tells us whose orders they are; it does not define the Orders table’s grain.

That distinction affects even basic totals. This image shows two customers and three orders. Counting distinct customer IDs in Orders gives two customers represented in that table, not three orders. Counting its rows gives three orders because the stated grain is one row per order. Its order amounts total $50+75+30=155$. You could not safely treat each Orders row as a separate customer signup.

Now imagine receiving an export called OrderProducts with these rows:

The grain is one row per product line on an order. OrderID 101 repeats for a legitimate reason, and there are three lines but only two orders represented. The pair of order ID and product happens to distinguish these sample rows, but it might not do so in a real export—for example, the same product could appear on two lines. Use the business description first; test candidate identifiers against the actual data second.

The video’s shipping example adds one more caution. A table can be at product-line grain while containing a value, such as total shipping cost, that applies to the whole order and is repeated on its lines. Establish what that value describes before adding it up.

Work-along: the banner KPI needs sessions, not event rows

Return to the previous lesson’s US mobile product-page session purchase rate. Suppose an analytics export records one row per tracked event. For this small example, assume every row falls within the agreed reporting week and US mobile scope:

Take about 10 minutes to trace the records with a sheet of paper or a spreadsheet. First label the export’s grain. Next, make one note per SessionID: whether the session viewed a product page and whether it contained an order. Use those notes to apply the KPI definition from the last lesson.

Here is the check:

The export’s grain is one row per event, not one row per session. E01 and E02 are separate page-view events, not necessarily bad duplicate records. For this example, the KPI has three eligible sessions and two eligible sessions with an order:

Counting product-view rows would give four views, not three eligible sessions. Counting all order rows would incorrectly include S13. To calculate the defined KPI, you must reason at session grain, using the event records to establish what happened within each session.

This is why a KPI card and a dataset need to be examined together. The card states the intended counting unit; the dataset grain reveals whether a row count supplies that unit directly or whether multiple rows must first be considered together.

A reliable grain check for new datasets

For a final 5-minute audit, apply this short sequence whenever you open an unfamiliar table:

1. Describe a row in business terms. Try “one row per customer,” “one row per order line,” or “one row per campaign per day.” Include all parts needed to make the statement precise.
2. Inspect several rows and repeated values. A repeated customer ID in an orders table is expected. A repeated order ID in an order-level table needs investigation; in a product-line table, it may be expected.
3. Check the time unit. A table with two channels for each month has one row per month per channel, not one row per month. Several dates in a row do not, by themselves, tell you its grain.
4. Test the statement against the source’s meaning. A unique-looking column in a small sample is evidence, not proof. If documentation and records disagree, mark the grain as unconfirmed rather than silently assuming it.

An aggregated table has a different grain from the detail that produced it. Monthly sales by channel can answer “How much did each channel sell in January?” It cannot reveal which individual orders made up that total unless the underlying order records are also available. Filtering rows does not itself change what an individual row represents; producing a new summary does.

Key takeaways

Observation grain is the business meaning of one row. State it precisely, then use repeated values and source documentation to check it. In particular, distinguish row counts from counts of the customers, orders, or sessions represented by those rows. That habit protects the KPI definitions you developed in the previous lesson from being applied to the wrong unit.

Next, we’ll look at the columns within a table and distinguish identifiers, descriptive dimensions, and numeric measures.