When the Scored Unit Is Not the Decision Unit
A predictive task can appear well specified because it names an outcome and produces a score for every row in a data set. But if the organization acts on a different entity from the one represented by each row, the score may not answer the decision-maker’s question. A model might score individual transactions while a business can contact only customers; it might score claims while an investigator opens one account-level case.
The distinction matters because several predictions for one entity do not automatically become a suitable prediction for that entity. A transaction-level probability is not, by itself, a customer-level probability. Nor is the highest transaction score necessarily the best basis for prioritizing customers. First define what is predicted for each unit; then specify the entity and outcome that the decision concerns.
State the Question at Both Levels
Suppose a hypothetical insurer estimates the probability that each submitted claim contains a material error. If each claim is independently investigated, the claim may be both the prediction unit and the decision unit. If an investigator instead reviews all claims associated with one policyholder as a single case, the decision unit is the policyholder or account. The claim scores still describe individual claims, but they do not directly state the probability that the account has at least one erroneous claim.
The reformulation should make four points explicit:
- Prediction unit: What does one score describe?
- Decision unit: Which entity receives the action?
- Decision-relevant outcome: What event or quantity matters at that entity level?
- Aggregation rule: How will the unit-level predictions be combined, if they can be combined, to answer that question?
The aggregation rule depends on the outcome. For an “at least one event” outcome, probabilities may be combined using a union calculation when the needed dependence assumptions are justified. For total expected cost, expected amounts can be added. A maximum score, an average score, or a sum of scores is not automatically correct: each summarizes something different.
Worked Example: Warranty Outreach by Customer
A hypothetical warranty administrator predicts whether each appliance registration will be followed by at least one repair request in the next year. The prediction unit is a registration, but outreach is sent once per customer. Customer A has two registrations with predicted repair probabilities 0.10 and 0.20. Customer B has three registrations with probabilities 0.15, 0.10, and 0.05. Customer C has one registration with probability 0.30. Assume, for this calculation, that repair events for different registrations belonging to the same customer are independent. The outreach rule is to contact a customer if the probability of at least one repair request is at least 0.25. Which customers qualify?
Method. Calculate the probability of at least one repair for each customer from the registration-level probabilities, then apply the threshold once per customer. This avoids treating a registration score as though it were already a customer-level probability.
For independent events, the probability of no repair on every registration is the product of the probabilities of no repair on each one. Thus, the probability of at least one repair is one minus that product.
For Customer A, the probabilities of no repair are \(1-0.10=0.90\) and \(1-0.20=0.80\). Therefore:
For Customer B, the no-repair probabilities are \(0.85\), \(0.90\), and \(0.95\). Their product is \(0.85\times0.90=0.765\), then \(0.765\times0.95=0.72675\). Hence:
For Customer C, there is one registration, so the customer-level probability is \(0.30\).
Comparing each result with the customer-level threshold of \(0.25\), Customer A qualifies because \(0.28\geq0.25\), Customer B qualifies because \(0.27325\geq0.25\), and Customer C qualifies because \(0.30\geq0.25\). The calculation is checked by noting that each customer’s at-least-one probability is at least as large as the largest individual registration probability, and is no greater than 1. Each result satisfies those bounds.
Common mistake avoided: Applying the threshold separately to registrations would mark only Customer C’s registration, since it is the only individual score at least 0.25. That answers which registrations exceed the threshold, not which customers meet the stated customer-level rule.
Why the “At Least One” Formula Works
For a customer with events \(E_1,\ldots,E_k\), the event “at least one event occurs” is the complement of “none of the events occurs.” Under independence, the probability that none occurs is the product of the individual no-event probabilities. Subtracting from 1 gives the desired probability:
The final equality requires independence among the events. If event probabilities are dependent, multiplying the no-event probabilities is not justified; the joint probability of no events must be obtained another way. For two events, for example, the general rule is \(P(E_1\cup E_2)=P(E_1)+P(E_2)-P(E_1\cap E_2)\). If the joint term is unknown, the individual probabilities alone may not determine the at-least-one probability. The right response is to state the limitation, obtain suitable dependence information, or define a different decision-relevant summary—not to silently assume independence.
Worked Example: Account-Level Investigation Priority
A hypothetical fraud team receives one investigation slot and investigates an account, not an individual claim. Three accounts have claim-level probabilities of at least one fraudulent payment as follows: Account K has two claims with probabilities 0.40 and 0.30; Account L has one claim with probability 0.55; Account M has three claims with probabilities 0.25, 0.20, and 0.20. Assume the claim events are independent within each account. Prioritize the account with the largest probability of at least one fraudulent claim.
Method. Translate the claim-level probabilities to an account-level “at least one” probability, then compare accounts. This avoids choosing an account solely because it has the single largest claim score.
For K, the no-fraud probabilities are \(1-0.40=0.60\) and \(1-0.30=0.70\). Their product is \(0.60\times0.70=0.42\), so the account probability is \(1-0.42=0.58\).
For L, there is one claim, so the account probability is \(0.55\).
For M, the no-fraud probabilities are \(0.75\), \(0.80\), and \(0.80\). Their product is \(0.75\times0.80=0.60\), then \(0.60\times0.80=0.48\). Thus M’s account probability is \(1-0.48=0.52\).
The account-level ranking is K at 0.58, L at 0.55, and M at 0.52. Therefore, with one available slot and the stated priority rule, investigate K. The arithmetic is checked by comparing each probability with its largest claim-level probability: K’s 0.58 exceeds 0.40, L remains 0.55, and M’s 0.52 exceeds 0.25, as expected for an “at least one” event.
Common mistake avoided: Selecting L because its largest individual claim score, 0.55, exceeds either individual claim score for K would compare a claim-level score with an account-level decision. After aggregation, K has the larger account-level probability.
Choose an Aggregation That Matches the Outcome
Not every entity-level question asks whether at least one event occurs. If the target is total expected monetary loss across an entity’s transactions, the relevant aggregation differs. Let \(L_j\) be the loss from transaction \(j\). The total loss is \(\sum_j L_j\), and, provided the expectations exist, linearity of expectation gives:
This equality does not require the losses to be independent. It follows from the linearity of expectation. If each transaction has an event probability \(p_j\) and a conditional mean loss \(m_j\) when the event occurs, with zero loss otherwise, then \(E[L_j]=p_jm_j\). The entity-level expected total is the sum of these transaction-level expected losses. It is not generally the same as the probability of at least one event, the largest event probability, or the average event probability.
Worked Example: Expected Annual Cost by Customer
A hypothetical service team ranks customers by predicted annual repair cost. For each repair opportunity, the model supplies an event probability and the expected cost conditional on a repair. Customer R has two opportunities: probability 0.08 with conditional mean cost $400, and probability 0.12 with conditional mean cost $600. Customer S has two: probability 0.20 with conditional mean cost $300, and probability 0.05 with conditional mean cost $500. Customer T has two: probability 0.04 with conditional mean cost $2,000, and probability 0.10 with conditional mean cost $300. Assume no repair has zero cost. Rank the customers by expected total annual cost.
Method. For each opportunity, multiply the event probability by its conditional mean cost to get expected cost; add the expected costs within each customer. This aligns the summary with a customer-level total-cost outcome.
For R, the first opportunity contributes \(0.08\times\$400=\$32\). The second contributes \(0.12\times\$600=\$72\). Thus R’s expected total is \(\$32+\$72=\$104\).
For S, the first contribution is \(0.20\times\$300=\$60\), and the second is \(0.05\times\$500=\$25\). Thus S’s expected total is \(\$60+\$25=\$85\).
For T, the first contribution is \(0.04\times\$2{,}000=\$80\), and the second is \(0.10\times\$300=\$30\). Thus T’s expected total is \(\$80+\$30=\$110\).
The ranking from largest to smallest expected annual cost is T at $110, R at $104, then S at $85. The calculation is checked by confirming that each component is probability times conditional cost and that the two component expectations sum to the customer total. Independence is not needed to calculate these expected totals.
Common mistake avoided: Ranking customers by the highest event probability would rank S first because 0.20 is its largest probability, even though T has the largest expected total cost. Probability alone ignores the different cost sizes.
Reformulate Before Comparing or Acting
A unit mismatch can affect more than the final action. A summary calculated over transactions gives more weight to entities with more transactions. A summary calculated over customers gives each customer one place in the comparison. Those summaries answer different questions. Likewise, a threshold defined for a customer-level event cannot be applied automatically to each transaction score.
A practical framing sequence is:
Write exactly what one prediction describes, such as the probability of a repair request for one registered appliance.
Specify whether the action is directed to a transaction, customer, account, or another entity.
State whether the decision uses an “at least one” probability, a total expected amount, or another explicitly defined summary.
State any assumptions required for aggregation, and confirm that the combined quantity corresponds to the intended outcome.
Use a customer threshold to classify customers, or an account capacity limit to rank accounts—not the underlying transactions unless the action is transaction-level.
If the translation cannot be justified, that is a framing issue to resolve before treating the scores as decision-ready. For example, individual event probabilities without dependence information may be insufficient for an entity-level “at least one” probability. The model’s scores may still be useful for a different task, such as choosing which individual transactions to review, but that is a different decision unit and should be stated as such.
For an actuarial analyst, this distinction is also important when explaining results. “The model scores claims” and “the team selects accounts for review” are not interchangeable descriptions. State what the score predicts, how it is converted to an account-level quantity, and which unit the resulting ranking or threshold applies to. This is aligned with the SOA Exam PA (Predictive Analytics) syllabus, where a defensible task definition must connect the prediction to the intended use.
Check Your Understanding
For each problem, identify the relevant decision-level quantity and check the unit of the final answer.
- A customer has two independent device registrations with event probabilities 0.12 and 0.08. Outreach is triggered when the probability of at least one event exceeds 0.18. Calculate the customer probability and state whether outreach is triggered. (Answer: \(1-(0.88)(0.92)=0.1904\); yes, outreach is triggered.)
- An account has three independent claims with event probabilities 0.30, 0.20, and 0.10. Find the account probability of at least one event and determine whether it meets an account threshold of 0.45. (Answer: \(1-(0.70)(0.80)(0.90)=0.4960\); it meets the threshold.)
- Customer A has two possible losses with event probabilities and conditional mean costs of (0.10, $400) and (0.05, $1,000). Customer B has (0.20, $300) and (0.10, $500). Calculate both expected total costs and identify the larger. (Answer: A is $90; B is $110; Customer B has the larger expected total.)
- One investigation slot is available. Account P has independent claim probabilities 0.20 and 0.20; account Q has one claim probability 0.50; account R has independent claim probabilities 0.25 and 0.20. Rank by probability of at least one event and name the account selected. (Answer: P = 0.3600, Q = 0.5000, R = 0.4000; select Q.)
- A customer has three event probabilities 0.20, 0.30, and 0.40, but their dependence is unspecified. What is the expected number of events, and can the probability of at least one event be determined from these values alone? (Answer: Expected number of events = 0.90; no, the probability of at least one event is not determined without dependence information.)