Tutorials › Exam PA - Predictive Analytics › Repeated Decisions and the Unit of Prediction

Exam PA · Problem Framing and Decision Context · Tutorial 12 of 966

Repeated Decisions and the Unit of Prediction

Choose a prediction unit that matches the decision occasion, and understand how repeated records change the meaning of a target and its summary.

Beginner 10 min read

What You'll Learn

  • Distinguish a prediction instance from a person or account identifier
  • Match person-, policy-period-, and transaction-level predictions to the intended occasion
  • Define outcomes consistently across repeated decision occasions
  • Identify when a person-level outcome differs from repeated period-level outcomes
  • Recognize why repeated records are not automatically independent cases
  • Avoid interpreting a row-based rate as a person-based rate

Why the Unit of Prediction Matters

A data set may contain several records for the same person. Each record could represent a new policy period, a service request, or a purchase. The key question is not simply how many rows are available. It is what one prediction is meant to describe: a person, one period of coverage, or one transaction?

The choice changes the prediction task itself. A probability of a claim during a particular policy period is not the same target as a probability that a customer will ever make a claim. Likewise, a prediction for each transaction does not automatically answer a question about each customer. The unit should be explicit before repeated records are treated as separate prediction cases.

Definition: A prediction instance is one occasion for which a prediction is intended. Its unit of prediction identifies what that occasion represents, such as one person at a specified time, one policy period, or one transaction. A person or account identifier may occur in multiple prediction instances; repeated identifiers do not make those instances the same decision occasion.

The unit of prediction is related to, but not always identical to, the unit of analysis. A table may have one row per transaction, for example, while the practical decision is one outreach decision per customer. If so, the table's rows do not by themselves establish the correct prediction unit. Clarify the decision occasion, the target, and the outcome window together.

Three Common Units

UnitOne prediction describesExample of a clearly stated target
PersonA person, at a defined prediction timeWhether the person has at least one event during the next 12 months
Policy periodOne defined period of a particular policyWhether that policy has a claim during its next coverage year
TransactionOne specific transaction or service occasionWhether a claim is reported for this transaction within 30 days

These definitions require boundaries. For a policy-period prediction, specify which policy and which period. For a transaction prediction, identify the transaction and the window in which its outcome is counted. For a person-level prediction, state whether the target concerns any event, a count, or another outcome during the defined horizon. The target and measurement unit should follow the decision being supported, rather than the format in which the data happened to be collected.

Worked Example: Repeated Policy Periods

A hypothetical insurer wants to predict whether a claim will occur during the next 12 months when a policy comes up for renewal. Its historical file has five rows: customer A has two consecutive policy periods, customer B has one, and customer C has two. The recorded claim indicators for those periods are A: 0, 1; B: 0; C: 0, 0. Identify the prediction unit and calculate the observed claim proportion at that unit. Then explain why this is not the same as the proportion of customers who had any claim.

Method. Start with the decision occasion: a renewal for a particular policy period. Each row describes a distinct policy-period prediction instance, so there are five instances. The target is the indicator for at least one claim during the corresponding 12-month period.

The number of claim-positive periods is \(0+1+0+0+0=1\). Therefore, the observed proportion of claim-positive policy periods is \(1/5=0.20\), or 20%.

There are three distinct customers. Customer A had at least one claim, while B and C did not. Thus, the proportion of customers with at least one claim across the periods shown is \(1/3\), or approximately 33.3% when rounded to one decimal place. The two proportions answer different questions: one uses policy periods as its denominator, and the other uses customers.

Check. The five period indicators sum to one, and exactly one of the three customers has any positive period. The common mistake is to call \(1/5\) the proportion of customers with a claim; it is the proportion of policy periods with a claim.

Repeated Periods and Person-Level Outcomes

A person-level target can be formed from repeated period outcomes, but it must be defined deliberately. Suppose person \(i\) has \(T_i\) periods in the specified horizon, and \(Y_{it}=1\) if an event occurs for that person in period \(t\), with \(Y_{it}=0\) otherwise. A person-level “any event” target is \(Y_i=1\) if at least one of those period outcomes is 1, and \(Y_i=0\) otherwise. This is a different target from predicting each \(Y_{it}\) separately.

A useful probability relationship follows when the period events are conditionally independent and their probabilities \(p_{it}=P(Y_{it}=1)\) are known for the specified person and periods. These are substantive assumptions, not automatic properties of repeated records.

$$ P(Y_i=1)=1-\prod_{t=1}^{T_i}(1-p_{it}) $$

Why this holds. The event “at least one period has an event” is the complement of “no period has an event.” In period \(t\), the probability of no event is \(1-p_{it}\). Under the stated independence assumption, the probability of no event in every period is the product of those probabilities. Subtracting that probability from 1 gives the chance of at least one event. If the period outcomes are dependent, the product formula need not hold; the joint probability of no events, or an appropriate model for dependence, is needed instead.

Worked Example: From Period Risks to a Person-Level Target

For a hypothetical equipment owner, the probabilities of a service failure in the next three monthly periods are 0.10, 0.20, and 0.15. For this calculation only, assume the three period outcomes are independent. Find the probability of at least one failure over the three months, and distinguish it from the three separate monthly predictions.

Method. The requested target is a person-level “at least one failure” outcome over the three-month horizon. The monthly probabilities are \(p_1=0.10\), \(p_2=0.20\), and \(p_3=0.15\). The no-failure probabilities are \(0.90\), \(0.80\), and \(0.85\).

By independence, the probability of no failure in all three months is \(0.90 \times 0.80 \times 0.85 = 0.612\). Therefore, the probability of at least one failure is \(1-0.612=0.388\).

The person-level probability over the three-month horizon is 0.388, or 38.8%. The three period-level probabilities remain 10%, 20%, and 15%; none of them individually means “the chance of any failure over all three months.”

Check. The probability of no failure, 0.612, is between 0 and 1, and its complement is 0.388. A common mistake is to add the monthly probabilities and report 45%. That sum counts overlapping possibilities more than once; it is not the probability of at least one event. The product-of-complements calculation is valid here only because independence was specified.

Choosing the Unit for the Decision Occasion

1
Name the decision occasion.
State what will prompt a prediction: a customer review, a renewal, or an individual transaction. If there is no clear occasion, the prediction unit is not yet well defined.
2
Specify the target and its window.
Define the outcome for one instance, including its time horizon. “Any claim for this policy period” and “any claim for this person during the year” are different targets.
3
Map records to instances.
Determine whether a record represents a person, period, or transaction. Count distinct decision occasions as well as distinct identifiers; the counts may differ.
4
Check repeated identifiers.
Ask whether the same person or account appears again because another decision occasion occurred. Repeated rows may share characteristics or outcomes; they should not be described as separate people.

Worked Example: Transaction Outcomes Are Not Customer Outcomes

A hypothetical service center records six repair transactions for three customers. Customer A has three transactions with transaction outcomes \(1,0,0\); customer B has two with outcomes \(0,1\); customer C has one with outcome \(0\). Here an outcome of 1 means that the particular transaction required a repeat visit within 30 days. Calculate the positive transaction proportion and the proportion of customers with at least one positive transaction. Explain which result answers each question.

Method. For the transaction-level question, use transactions as the instances. There are six transactions and two positive outcomes, so the positive transaction proportion is \(2/6=1/3\), approximately 33.3% to one decimal place.

For the customer-level question, first group the transaction outcomes by customer. A has at least one positive outcome, B has at least one, and C has none. Thus, two of the three customers had at least one positive transaction, giving \(2/3\), approximately 66.7% to one decimal place.

The first proportion answers “What fraction of these transactions had a repeat visit?” The second answers “What fraction of these customers had at least one transaction with a repeat visit?” Neither should be substituted for the other. The customer result also depends on the observed transactions available for each customer; it does not, without a defined horizon and complete observation, establish a customer's future probability of a repeat visit.

Check. The transaction outcomes contain exactly two ones, and exactly two customers have at least one one. The common mistake is to use \(2/6\) as the proportion of customers with an event. That denominator counts transactions, not customers.

Repeated Records Require Careful Interpretation

Repeated records can make one unit appear more often than another. A customer with many transactions contributes many transaction-level instances, while a customer with one transaction contributes one. Consequently, a summary computed over rows describes the row-level population; it does not automatically describe a typical customer. The proper interpretation depends on the unit and the question, not just on the calculation.

Repeated records can also be related. A person's circumstances may persist across periods, and the outcome in one period may be associated with outcomes in other periods. It is therefore unsafe to assume that repeated rows are independent people or independent outcomes simply because they occupy separate rows. This tutorial does not require a particular modeling adjustment; the framing task is to identify and communicate the repeated structure before selecting an analysis.

For a policy-period prediction, each renewal may be a valid prediction instance if a prediction is genuinely needed at each renewal. For a customer-level prediction, those same rows may instead be inputs or history associated with one person-level instance. For a transaction prediction, each transaction may be the correct instance if the intended question concerns that transaction. These are distinct formulations, not competing ways of counting the same target.

Key takeaway: Define one prediction instance by the decision occasion, then state its target and outcome window. When identifiers repeat, keep the prediction unit and denominator explicit: a person, a policy period, and a transaction answer different questions.

Check Your Understanding

For each question, identify the relevant unit and interpret the requested quantity. Treat any independence condition as an assumption only when it is stated.

  1. A hypothetical insurer has eight policy-period records, two of which have a claim during their respective coverage year. Three of five customers had at least one claim among their recorded periods. What are the claim-positive period proportion and the customer proportion? (Answer: 2/8 = 25% of periods; 3/5 = 60% of customers.)
  2. A customer has two monthly event probabilities, 0.25 and 0.10. Assume independence. What is the probability of at least one event over the two months? (Answer: \(1-(0.75)(0.90)=0.325\), or 32.5%.)
  3. A delivery platform's file contains 12 completed deliveries, three with a specified issue. The deliveries belong to four couriers, and two couriers had at least one issue. What are the delivery-level and courier-level issue proportions? (Answer: 3/12 = 25% of deliveries; 2/4 = 50% of couriers.)
  4. A policyholder has period event probabilities 0.20 and 0.30, but no independence assumption is given. Can the probability of at least one event be calculated as \(1-(0.80)(0.70)\) from these values alone? (Answer: No; that product requires independence. The joint probability of no events is needed.)
  5. A service team makes one prediction for every new repair request, and the target is whether that request receives a repeat visit within 14 days. The same customer can submit several requests. State the unit and what a row-level positive proportion describes. (Answer: The unit is the repair transaction/request; the proportion describes requests with a repeat visit, not customers with at least one repeat visit.)
Clinical Biostats