“Revenue is flat” sounds like a clear finding. It may not be a useful one.
A company can report no overall change while two locations are improving and two are deteriorating. The total is accurate, but it does not tell a manager where to investigate, what to change, or whether the same pattern is likely to continue.
That is a unit-of-analysis problem. The unit of analysis is the thing each comparison, count, rate, or conclusion is about: a customer, order, account, product, store, employee, contract, or calendar period.
The right unit is not always the smallest available one. It is the level that preserves the variation needed for a decision.
Start with the decision, not the table
A practical test is to finish this sentence: “If this result is concerning, what exactly would we change?”
If the answer is a store, territory, product line, customer segment, or account, the analysis should usually retain evidence at that level before it rolls results into a total. If the answer is a companywide cash plan, a firm-level total may be the appropriate primary view.
This is the decision-locus test. It directs attention to where someone can reasonably observe a difference and take action.
For example, consider a retailer with four stores. In one month, two stores each gain $20,000 in sales and two each lose $20,000. At the company level, net change is zero.
For cash planning, zero net change is meaningful. For diagnosing execution, staffing, local demand, or inventory issues, it is incomplete. The store is the better primary unit because it reveals the variation that the decision needs.
Neither view disproves the other. They answer different questions.
Keep three units separate
Many errors begin when three different units are treated as if they were identical:
- Unit observed: what the source records, such as an order, website event, shift, or invoice.
- Unit analyzed: what the calculation treats as one case, such as a customer, location, or account.
- Unit acted on: who or what receives the decision, such as a store manager, sales territory, product team, or executive group.
They may align, but they do not have to.
An ecommerce system may record orders. That does not mean every question should be answered at the order level. If 100 orders came from 20 customers, order counts describe fulfillment volume and transaction demand. Customer-level analysis is needed for reach, repeat purchasing, concentration, retention, and exposure if a customer leaves.
An order-level conversion rate should not casually be described as a customer-level conversion rate. The numerator and denominator must describe compatible units.
The same distinction appears in sales data. Thirty engaged contacts may sound promising, but if those contacts belong to three accounts, pipeline concentration is an account-level question. Counting contacts as though they were independent accounts can overstate diversification.
Aggregation changes what you can see
Aggregation is not neutral. It can cancel opposite movements, change denominators, and hide repeated appearances by the same entity.
A monthly average may be mathematically sound yet too coarse for a staffing or incident-response decision. A product-family margin can be useful for portfolio planning while concealing a loss-making SKU that requires attention. A campaign total can look healthy even when most engagement comes from a narrow audience segment.
The reverse problem also matters. More detail is not automatically better. A daily rate for a small location may swing sharply because the denominator is thin. SKU-level results can become noisy when few units sell. Detail without enough evidence can create false precision.
A sound choice finds the highest level that still preserves decision-relevant variation, and the lowest level that the available data can support credibly.
Business statistics use different units on purpose
Official statistical programs make this distinction deliberately. U.S. statistical agencies distinguish establishments from firms because they answer different questions.
An establishment is generally a single physical location carrying out a predominant activity. A firm can consist of one or more establishments. A multi-location business may therefore be one firm and several establishments at the same time.
The Bureau of Labor Statistics and the Census Bureau use these levels differently in their business statistics. For example, establishment-level changes can show what is happening at individual locations, while firm-level size or age classifications can support a different view of the organization. The choice affects the interpretation of results, not merely the formatting of a table.
Private business reporting has similar distinctions. A legal entity, brand, parent company, tax identifier, operating unit, and physical location can coincide in a small business. In a larger organization, they often do not. Naming the unit explicitly prevents a report from implying more than it measures.
Five questions before calculating
Before selecting a metric or building a dashboard, ask:
1. What decision is this analysis meant to support? 2. Who or what can act on the result? 3. What entity actually experiences the outcome? 4. Can that entity appear more than once in the raw data? 5. Would rolling the data up hide meaningful differences or double-count repeat activity?
Add a time question when needed: does the decision require daily, weekly, monthly, or quarterly evidence? A budgeting decision and a same-day operational response do not need the same time unit.
A useful safeguard is to report one primary view and one nearby companion view when the difference could change action. Show company performance alongside location dispersion. Pair order totals with distinct customers. Present portfolio results with account-level concentration or a count of accounts below target.
The metric definition should state the choice plainly: what counts as one case, what period is included, and what repeats are handled. That small note can prevent a correct calculation from becoming the wrong business conclusion.
Morrow Creek Data Services handles paid research, cleanup, verification, and structured delivery projects.
Start a data project