Data Analysis / Basic: Questions and Trustworthy Tables / Lesson 1

Questions, Grain, and Provenance

Translate a vague request into a measurable question and identify exactly what one row and one reported number represent.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Define population, observation unit, metric, and period.
Distinguish rows, events, and unique entities.
Record source and transformation assumptions.

Start with a decision and a defined question

An analysis begins with a question, not a convenient chart. Replace “how are orders doing?” with a defined quantity such as the total amount of completed synthetic orders in a stated period. Identify the intended population, inclusion rule, time zone, units, and comparison. Ask what decision a different answer could change before choosing a method.

An operational definition turns a familiar word into a reproducible calculation. “Customer” might mean an account, a person, or a device; “active” might mean one qualifying event within seven days. Those choices affect results even when every line of code is correct. Write them before inspecting favorable outcomes.

One row is not necessarily one entity

The grain states what a row represents: an order, line item, daily account summary, or another unit. A single customer can contribute several rows. Counting rows answers an event question only when that grain matches the definition. Identifiers establish relationships, but an identifier’s spelling does not prove uniqueness or completeness.

The first program has three orders but two customers. Its total is thirty-five under the stated order-level amount definition. If the table instead contained line items with an order total repeated on each line, summing that field would overcount. The code is simple so that the analytical unit remains the main lesson.

python Count the declared units

rows = [
    {"order": "o1", "customer": "c1", "amount": 10},
    {"order": "o2", "customer": "c1", "amount": 20},
    {"order": "o3", "customer": "c2", "amount": 5},
]
print("orders", len(rows))
print("customers", len({row["customer"] for row in rows}))
print("amount", sum(row["amount"] for row in rows))

Expected output

orders 3
customers 2
amount 35

Three order records belong to two unique customer identifiers; their order-level amounts sum to35.

Keep the eligible population visible

Filtering changes the population represented by a result. Record both the starting and retained counts and the reason for exclusion. A completed-order metric should not quietly include cancelled orders because their amount field is populated. Conversely, dropping every incomplete row can exclude a meaningful group and change the question.

The second program reports its eligibility count beside the total. This is a small reconciliation: three input records become two qualifying records. The rejected record is not erased from history. A production analysis should retain a source snapshot or an audit trail sufficient to explain the exclusion without exposing unnecessary personal data.

python Reconcile the inclusion rule

rows = [("complete", 10), ("cancelled", 50), ("complete", 20)]
eligible = [amount for status, amount in rows if status == "complete"]
print(f"eligible={len(eligible)}/{len(rows)} total={sum(eligible)}")

Expected output

eligible=2/3 total=30

Only complete records contribute, giving two eligible orders and a total of30.

Provenance explains how the table came to exist

Provenance records where data originated, when it was extracted, which version was used, and which transformations produced the analysis table. A filename alone does not capture changed source content. Preserve a data dictionary, extraction scope, transformation code, and meaningful checksums or version identifiers where appropriate.

Distinguish an observed field from a derived one. A recorded timestamp may mean event time, ingestion time, or last update. A displayed category may be an analyst’s mapping rather than a source fact. Keeping those layers separate makes later disagreements diagnosable and prevents a derived label from being mistaken for ground truth.

Write an analysis contract before the result

A compact plan can state the question, unit, eligible population, metric formula, expected checks, uncertainty limits, and intended audience. It should also say what the data cannot answer. An order table can describe recorded behavior without proving why behavior changed or representing customers absent from the system.

Keep exploratory questions separate from predeclared confirmatory ones. Exploration can reveal useful patterns, but choosing a favorable pattern after many attempts changes the evidential meaning. Later lessons develop this distinction. For now, prefer a transparent limited answer over a broad claim whose population and denominator are unknown.

Common errors and fixes

Row count is reported as customer count.

Why it happens: The table grain is an order rather than a customer.
How to fix it: Count distinct validated customer identifiers for that question.
Prevent it next time: State the row unit beside every metric.

A total changes after an undocumented filter.

Why it happens: The eligible population changed invisibly.
How to fix it: Report inclusion rules and before/after counts.
Prevent it next time: Keep an exclusion audit.

An analysis cannot be reproduced from its filename.

Why it happens: Source version and transformations are missing.
How to fix it: Record content identity, extraction scope, and code.
Prevent it next time: Treat provenance as an output requirement.

Check your understanding

1. A customer has four line items across two orders. Which counts answer line items, orders, and customers?

Show worked solution

There are four line items, two distinct order identifiers, and one distinct customer identifier. The three numbers are all correct for different units. Before aggregating an amount, determine whether it is line-level or an order total repeated on each line. A row-count shortcut cannot decide this from the values alone.

2. Rewrite “usage improved” as a checkable analytical question and identify one limitation.