Defining the Unit of Analysis

Why the Unit of Analysis Matters

A prediction is made about something: perhaps a person, an insurance policy, a claim, a transaction, or a service location. That “something” is the unit of analysis. Choosing it is not a technical detail to settle after the data are assembled. It determines what one prediction means, what one row should represent, and how an outcome is counted.

The right unit follows from the decision. If an insurer makes a separate decision for each policy, a prediction about each policy is usually more directly useful than one score per policyholder. If a claims team prioritizes individual claims, a policy-level score may hide which claim needs attention. A well-chosen unit makes the prediction and the intended action refer to the same kind of entity.

Definition: The unit of analysis is the entity about which one prediction is produced and to which the prediction is intended to apply. A data record should correspond to that entity, or there should be a clear, consistent rule for constructing the record and its outcome at that level.

The unit of analysis is related to, but not always identical to, the unit of observation. A data source might contain one row per claim, while the task is to make one prediction per policyholder. In that case, claim records must be combined or summarized to create a person-level record. Simply treating every claim row as a separate person-level prediction would not change the source data into person-level data.

Start With the Decision-Making Entity

A practical way to select the unit is to ask: What entity can receive a distinct action as a result of this prediction? State the decision in concrete terms, then name the entity to which the action applies. This uses the connection between predictions and intended actions established by the earlier material on decision framing.

Name the action.
Describe what the decision-maker may do, such as review a claim, price a policy, or contact a customer.

Name the recipient.
Determine whether that action applies to a person, a contract, a claim, a transaction, or another entity.

Align one prediction with one recipient.
Define the unit so that each prediction can be interpreted and used for the stated decision.

Check the records and outcome.
Confirm that the data can identify the chosen entity and that the target is defined for that same entity.

The same underlying business activity can support different units, depending on the decision. A policyholder may own several policies and make several claims. A single claim may contain several payment transactions. These entities are related, but they are not interchangeable. Choosing one level over another changes what counts as one case.

Worked Example: Choosing Between a Policyholder and a Policy

A hypothetical insurer is considering a review process in which an underwriter makes a separate pricing decision for every policy contract. The available extract contains records for three policyholders: Rowan has two contracts, Casey has one, and Morgan has three. A project team proposes one prediction record per person. Choose the more suitable unit and show how many records each choice produces.

Method: match the prediction to the action recipient. The underwriter’s action is a pricing decision on an individual contract. Therefore, the policy—not the person—is the natural unit for this task.

Step 1: Count the entities at each level. There are three policyholders. The number of policies is $2+1+3=6$. Thus, a person-level file would contain three records, while a policy-level file would contain six records.

Step 2: Check whether a person-level prediction can distinguish the decisions. Rowan has two policies. One person-level score would have to be used for both contracts, even though the underwriting decision is made separately for each. The same mismatch applies to Morgan’s three policies. A person-level score would not, by itself, provide six distinct policy-level predictions.

Step 3: State the appropriate interpretation. With the policy as the unit, each prediction refers to one of the six contracts that may receive its own pricing decision. The data design must retain a policy identifier so that each record and prediction can be connected to the correct contract.

A person-level model could be appropriate for a different decision, such as deciding whether to send one communication to each policyholder. The entity is determined by the action, not just by which identifiers happen to be present in the data. Common mistake avoided: treating the policyholder and policy as synonyms because the same person owns the contracts.

Changing the Unit Changes What Is Counted

A target must be defined at the chosen level. For example, “this claim is severe” is a claim-level outcome, while “this policy has at least one severe claim” is a policy-level outcome. These statements use different denominators and answer different questions.

Let $N_j$ be the number of claims for policy $j$, and let $Y_{jk}$ equal 1 if claim $k$ on policy $j$ is severe and 0 otherwise. For policies with at least one claim, a claim-level severe-claim proportion is the number of severe claims divided by the total number of claims. A policy-level proportion with any severe claim counts each policy once, regardless of its number of claims.

\text{Claim-level proportion} = \frac{\sum_j\sum_{k=1}^{N_j}Y_{jk}}{\sum_j N_j}, \qquad \text{Policy-level proportion with any severe claim} = \frac{\sum_j \mathbf{1}\left(\sum_{k=1}^{N_j}Y_{jk}>0\right)}{\text{number of policies}}.

Here, $\mathbf{1}(A)$ is 1 when statement $A$ is true and 0 otherwise. The policy-level quantity counts a policy with two severe claims once, not twice. The two proportions need not be equal because their numerators and denominators count different entities.

The reason is direct: the claim-level calculation gives each claim one place in its denominator, while the policy-level calculation gives each policy one place. A policy with several claims therefore contributes several times to the first denominator but only once to the second. Aggregating outcomes changes the question; it is not just a change in formatting.

Worked Example: Converting Claim Outcomes to Policy Outcomes

A hypothetical insurer reviews four policies. Policy A has two claims, one severe and one not severe. Policy B has one non-severe claim. Policy C has no claims. Policy D has two non-severe claims. A team is asked to report both the proportion of claims that are severe and the proportion of policies with at least one severe claim.

Method: calculate at each unit separately. First count claims and severe claims. Then construct one “any severe claim” indicator for each policy, including policies with no claims.

Step 1: Count claims. The total number of claims is $2+1+0+2=5$. There is one severe claim, on Policy A. Thus the claim-level severe proportion is $1/5=0.20$.

Step 2: Determine the policy-level indicator. Policy A has at least one severe claim, so its indicator is 1. Policies B, C, and D have no severe claims, so each has indicator 0. The sum of the four indicators is $1+0+0+0=1$.

Step 3: Calculate the policy-level proportion. There are four policies, including Policy C, which had no claims. The proportion with at least one severe claim is $1/4=0.25$.

Check. The claim-level answer is 0.20 and the policy-level answer is 0.25. These values differ because one counts claims and the other counts policies. Common mistake avoided: dividing the one severe claim by the four policies to report a claim-level proportion, or excluding Policy C from the policy denominator without defining a different question.

Unit Choice Also Determines Weighting

When the same information can be summarized at more than one level, the resulting average may give entities different influence. A transaction-level average gives each transaction equal weight. An average of customer-level averages gives each customer equal weight. Neither is automatically preferable; each answers a distinct question.

For customers $j=1,\ldots,J$, let $n_j$ be customer $j$'s number of transactions and $x_{jk}$ the amount of transaction $k$. The transaction-level mean is the total transaction amount divided by the total number of transactions. The mean of customer-level averages first calculates a mean for each customer, then gives those customer means equal weight. These are generally different if customers have different transaction counts.

Worked Example: Transaction Average Versus Customer Average

A hypothetical service has two customers. Customer A makes three transactions of $12, $18, and $30. Customer B makes one transaction of $80. The analyst must report (i) the average amount per transaction and (ii) the average of the two customers’ average transaction amounts.

Method: use the denominator named by each question. There are four transactions in total, but only two customers.

Step 1: Calculate the transaction-level average. The total amount is $12+18+30+80=140$ dollars. The number of transactions is $3+1=4$. The average per transaction is $140/4=35$ dollars.

Step 2: Calculate each customer’s average. Customer A’s average is $(12+18+30)/3=60/3=20$ dollars. Customer B’s average is $80/1=80$ dollars.

Step 3: Give each customer equal weight. The average of the customer averages is $(20+80)/2=50$ dollars.

Check. The transaction-level average is $35.00, while the average customer-level average is $50.00. Customer A contributes three of the four transactions to the first calculation but only one of the two customer averages to the second. Common mistake avoided: reporting one result as “the average” without specifying whether it is per transaction or an average across customers.

Common Unit-of-Analysis Traps

A unit mismatch can produce a result that is arithmetically correct but unsuitable for the decision. Check the entity at every stage: what the model predicts, what each record represents, how the target is counted, and what receives the resulting action.

Using a convenient identifier instead of the decision entity. A data extract may be organized by person even when decisions are made separately for each policy.
Counting lower-level records as if they were larger entities. Several claims from one policy are several claims, but they still belong to one policy.
Duplicating a larger-entity outcome across its lower-level rows without considering the target. Repeating “policy has a severe claim” on every claim row does not make the outcome claim-specific.
Ignoring implicit weighting. An average over transactions gives more influence to customers with more transactions than an average that gives each customer equal weight.
Failing to state the unit in the result. “The rate is 20%” is ambiguous unless it says, for example, 20% of claims or 20% of policies.

Key takeaway: Define one prediction per entity that can receive the intended decision. Then make the record, target, denominator, and interpretation consistent with that entity. If the task changes from claims to policies, or transactions to customers, explicitly redefine what is counted.

Careful unit selection is a basic part of predictive problem framing and is aligned with the SOA Exam PA (Predictive Analytics) syllabus. The key is not to choose the most detailed data level by default, but to choose the level that makes the prediction meaningful for the stated decision.

Check Your Understanding

For each problem, identify the unit that best matches the stated decision and check any requested count or rate.

A hypothetical insurer makes a separate review decision for each reported claim. One policy has three claims and another has one. What is the natural unit for predictions, and how many prediction records are needed? (Answer: Claim; 4 records.)
A hypothetical health plan wants to identify members who had at least one hospital admission. Among 20 members, 6 had one admission and 2 had two admissions; the remaining members had none. How many members had an admission, and what proportion is that? (Answer: 8 members; $8/20=0.4000$, or 40%.)
A hypothetical payment service has customer K with two transactions of $20 and $40, and customer L with one transaction of $90. Find the transaction-level average and the average of the two customer averages. (Answer: Transaction average $=\$150/3=\$50.00$; customer averages are $30 and $90, so their average is $60.00.)
A hypothetical insurer observes six claims across three policies. Exactly two claims are severe, and both belong to the same policy. What is the claim-level severe proportion, and what is the policy-level proportion with any severe claim? (Answer: Claim-level $2/6=0.3333$; policy-level $1/3=0.3333$. The numerical equality here does not make the units interchangeable.)
A hypothetical retailer takes one action per customer, but its source data has five transaction rows for Customer M and one for Customer N. If the modeling file is intended to contain one row for each decision recipient, how many rows should it have, and what must happen to the transaction data? (Answer: 2 rows; transaction information must be summarized or otherwise combined consistently to create one customer-level record for each customer.)

What You'll Learn