Observational unit

An observational unit answers a deceptively practical question: what does one row stand for? In Juniper's settlement extract, one row is one qualifying invoice. days_to_settlement is a variable recorded about that invoice; the number 31 is one observed value. Neither the column nor the value is the unit.

Grain changes the question

An accounting system may contain invoice headers, invoice lines, payments, cash-application events, customer accounts, and reporting periods. Joining those tables can produce several rows for one invoice. If an analyst averages the joined rows as though each were a separate invoice, invoices with more lines or payments receive more weight. Correct arithmetic then answers a different question.

A finance file has the same problem. One row might be a security, one daily return for a security, one portfolio-date position, or one trade. “Average return per row” has no stable meaning until the unit and weighting rule are known.

Audit the row before the statistic

Name the intended unit, identify its stable key, count duplicate keys, and ask whether any unit can generate multiple records. Then inspect whether the file mixes units—for example, invoice rows with customer-level credit limits or monthly balances. Aggregation may be appropriate, but it must be explicit.

Juniper's opaque invoice ID identifies the unit; it is not a quantitative measurement. If two rows share that ID, the source needs reconciliation before either row is counted. A clean mean cannot repair a duplicated case.