Why Policyholder History Needs Careful Construction
Renewal models often use information that accumulates over time: how long a customer has held coverage, whether the customer renewed before, how often claims occurred, and whether bills were paid on time. These predictors can be useful only if their meanings are consistent across records. A “claim count,” for example, is ambiguous unless its time period and unit of counting are specified. A “tenure” value is ambiguous unless its start date and treatment of coverage gaps are defined.
The prediction unit matters as well. A data set may have one row per policy, while a customer may hold several policies. If a predictor describes the whole customer and is copied onto every policy row, treating those rows as independent customer observations can duplicate the same history. The construction must match the renewal outcome being predicted.
For a renewal model, denote the prediction date for observation \(j\) by \(t_j\). A history predictor must use only information available by \(t_j\). If a feature summarizes the period \([t_j-12\text{ months},t_j)\), the endpoint is excluded: an event on or after the prediction date does not belong in that feature. The exact convention for events on a boundary should be fixed and applied consistently.
Define the Unit, Date, and Window First
Before calculating a summary, specify three things: what entity the feature describes, the date at which it is measured, and the period or event history it covers. These choices prevent a feature name from concealing different calculations in different records.
| Feature family | Possible definition | Important specification |
|---|---|---|
| Renewal history | Number of completed prior renewal opportunities accepted | Define which opportunities count and exclude the current decision |
| Claims | Claim count or paid amount in the prior 12 months | Define claim unit, date basis, and treatment of reopened claims |
| Payment behavior | Share of bills paid by the due date over the prior 12 months | Define eligible bills and distinguish missing records from no late payments |
| Tenure | Elapsed time from policy inception to renewal date | Define coverage gaps, cancellations, rewrites, and date units |
A rolling window, such as the 12 months immediately before each renewal date, gives each observation a comparable recent period. A fixed calendar-year window is also possible, but observations at different renewal dates then cover different amounts of recent history. Use the window that matches the modeling purpose and state it explicitly.
Event counts can be misleading when records have different amounts of observed exposure. If \(N\) is the number of claims in a window and \(E\) is the policy-years of exposure observed during that window, the observed claim frequency is \(N/E\), when \(E>0\). Counts and exposure should generally be retained or considered together: a count of two means something different over one policy-year than over ten. This ratio describes observed experience; it does not by itself establish that a customer’s future claim frequency will equal the observed rate.
Constructing Tenure and Renewal History
Tenure is elapsed time, not simply the number of renewal records. Under uninterrupted coverage, policy tenure in years can be calculated as elapsed days between inception and prediction dates divided by the chosen day-count convention, such as 365.25. For clean anniversary-based examples, elapsed calendar years may be used directly. Production definitions should specify how partial years are represented.
Policyholder tenure needs an explicit relationship definition. One possible rule is elapsed time since the earliest continuously active policy with the insurer. Another is time since the first policy inception regardless of later gaps. These answer different questions. If an account has a material lapse and later returns, a “continuous relationship” tenure may restart, while “ever with insurer” tenure may not. The data definition should not silently mix the two.
Prior renewal count is another distinct feature. It counts completed renewal opportunities before the current prediction, not the current renewal itself. It is not interchangeable with tenure: a policy may have a long tenure but few recorded renewal opportunities because records are incomplete, while a shorter policy may have several short-term renewals.
This share is defined only when at least one eligible bill is observed. If the denominator is zero, the share is undefined; it should not automatically be coded as zero, because zero would mean that no eligible bill was paid on time. A separate indicator for “no eligible bill observed” can preserve this distinction.
Worked Example: Building a One-Year History Summary
A hypothetical personal-lines policy is due for renewal on July 1, 2026. Use the half-open lookback window from July 1, 2025, up to but not including July 1, 2026. The available claim records are three distinct claims with loss dates August 12, 2025, November 3, 2025, and March 18, 2026. Their paid amounts by the prediction date are $900, $0, and $2,100. There are 12 eligible bills in the window; 10 were paid by their due dates and two were late. The policy began October 1, 2023, and has remained continuously in force. Construct the requested features.
Method. Apply the stated window and prediction date to each record, count distinct claims rather than payment transactions, and calculate tenure from policy inception. Assume all listed claim information and bill records were available by July 1, 2026.
Claim count. Each of the three loss dates falls on or after July 1, 2025, and before July 1, 2026. Thus the count is \(3\), including the claim with no paid amount.
Paid amount. Add the amounts available by the prediction date: \(900+0+2{,}100=\$3{,}000\). This is a paid-to-date summary, not an ultimate loss estimate.
Payment timeliness. The numerator is 10 and the denominator is 12, so \(10/12=0.8333\) to four decimal places, or 83.33% to two decimal places.
Policy tenure. From October 1, 2023, to October 1, 2025, is two years; from October 1, 2025, to July 1, 2026, is nine months. Therefore tenure is \(2+9/12=2.75\) years under the anniversary-based convention.
Check. The feature vector is claim count 3, paid-to-date amount $3,000, payment timeliness 0.8333, and policy tenure 2.75 years. The zero-paid claim remains in the claim count, and no event at or after the renewal date has been included. A common mistake is to count only claims with positive payments; that would produce a count of 2 and would not match the defined claim-count feature.
Multiple Policies and Duplicate History
A customer with multiple policies creates a choice of prediction unit. If the model predicts renewal separately for each policy, policy-specific features should remain attached to their respective policy observations. Customer-level history may also be added, but it must be calculated once for that customer and prediction date, then joined in a way that does not turn a single customer-level outcome into several independent outcomes.
If the outcome is defined at the customer level, the input data should ordinarily have one row per customer at that prediction date. If the outcome is policy-level, there may be one row per policy, but inference and evaluation must account for dependence among policies belonging to the same customer where relevant. Simply copying a customer’s shared history onto multiple policy rows does not create new independent histories.
Here \(N_k\) is the claim count for policy \(k\) in the chosen window and \(E_k\) is its exposure in policy-years. The pooled ratio weights each policy by its exposure. It is not generally equal to the unweighted average of policy-level frequencies, because policies can have different exposure amounts.
Worked Example: Combining Two Policies Without Doubling History
A hypothetical customer holds an auto policy and a home policy. For a customer-level renewal prediction dated January 1, 2026, each policy has one full policy-year of exposure in the prior 12-month window. The auto policy has two distinct claims and the home policy has one. The customer has paid 21 of 24 eligible bills on time across the two policies. Construct customer-level summaries and identify the duplication trap.
Method. First aggregate policy-specific claim counts and exposures over the same window. Then calculate payment behavior from eligible bills, using bills—not policy rows—as the denominator.
Claim count. Total distinct claims are \(2+1=3\). Total exposure is \(1+1=2\) policy-years. The pooled frequency is \(3/2=1.5\) claims per policy-year.
Payment behavior. The customer-level on-time share is \(21/24=0.8750\), or 87.50%. It is not the number of on-time bills divided by a duplicated count of bills.
Duplicate-history check. If the customer-level feature row is joined to both policy rows, each row may correctly display the customer’s total claim count of 3 and payment share of 0.8750 as shared customer-level predictors. But summing those repeated values across the two rows gives 6 claims and repeats the same payment history twice. For a customer-level analysis, retain one customer row. For a policy-level analysis, preserve the repeated shared features as attributes, but do not interpret their row-wise sum as customer experience.
Check. The aggregate frequency is 1.5 claims per policy-year and the payment share is 0.8750. The common mistake is to add the duplicated customer-level claim count after joining it to each policy, reporting 6 instead of the actual 3. Aggregation must occur at the intended unit before joining shared summaries.
Derivation: Why Exposure Belongs in a Rate
Suppose policy \(k\) contributes exposure \(E_k\) policy-years and claim count \(N_k\). Its observed frequency is \(N_k/E_k\) when \(E_k>0\). To combine policies into a portfolio rate, total claims are \(\sum_k N_k\) and total exposure is \(\sum_k E_k\). Therefore the combined rate is
The equality follows by multiplying each policy’s rate by its exposure weight: \((E_k/\sum_j E_j)(N_k/E_k)=N_k/\sum_j E_j\); summing gives the left-hand ratio. Thus the pooled frequency is an exposure-weighted average of policy frequencies, not generally their simple average. The expression assumes positive exposure for each policy whose rate is used and consistent claim and exposure definitions across policies. It is not appropriate to calculate a rate from a zero-exposure record.
Worked Example: Tenure, Prior Renewals, and Incomplete Records
A hypothetical policy is predicted on January 1, 2026. Its inception date is January 1, 2022, and it remained continuously active. The record contains three completed prior renewals, on January 1, 2023, 2024, and 2025. The system migration occurred January 1, 2024, so claim records are complete only from that date onward. In the 24 months from January 1, 2024, through December 31, 2025, the policy had two claims over 2.0 policy-years. Construct tenure and history features, and state what the incomplete claim history permits.
Method. Calculate tenure from known inception, count only prior completed renewals, and distinguish the complete 24-month claim window from any claim history before the migration.
Policy tenure. The dates are exactly four years apart, so policy tenure is 4.00 years.
Prior renewal count. The three listed renewal decisions all precede January 1, 2026. The count is therefore 3; the current renewal decision is not yet known and is excluded.
Claim frequency in the complete window. The count is 2 and exposure is 2.0 policy-years, giving \(2/2.0=1.0\) claim per policy-year. The system does not support a claim summary for the full four-year tenure because the first two years are not observed.
Check. The valid features are tenure 4.00 years, prior renewal count 3, and observed-window frequency 1.0 claim per policy-year for the stated 24-month period. Do not label the two claims as the policy’s complete four-year count. A common mistake is to treat a missing pre-migration history as a period with zero claims; the data establish incomplete observation, not absence of claims.
Practical Checks and Common Traps
History features should be reproducible from a written definition. A reviewer should be able to identify the unit, cutoff date, lookback period, event basis, denominator, and missing-data rule without guessing. In particular, distinguish the following cases:
- No event observed in a complete window: a valid zero count, if the event data are known to be complete.
- History not available: missing or incomplete information, not necessarily a zero count.
- No eligible denominator: a rate or share may be undefined rather than zero.
- Repeated customer summary on policy rows: a copied feature, not a separate history for every row.
A further trap is using a value that was updated after the prediction date. For example, a final claim payment or a bill’s eventual status may not have been known at renewal. Reconstruct features “as of” each prediction date using the information available then. Otherwise, the model can use future information and give an unrealistically favorable account of what could have been predicted.
Check Your Understanding
For each problem, define the requested history carefully and check that the unit and time window are consistent.
- A policy renews October 1, 2026. In the preceding 12-month window there are four distinct claims, with paid amounts $0, $500, $1,200, and $300. What are the claim count and paid-to-date total? (Answer: 4 claims and $2,000.)
- A customer has two policies, each with 0.5 policy-years of exposure in a common window. They have one and two claims, respectively. Calculate pooled frequency. (Answer: \(3/1.0=3.0\) claims per policy-year.)
- There are 15 eligible bills in a lookback window, of which 12 were paid by their due dates. What is the timeliness share to four decimal places, and what does it mean? (Answer: \(12/15=0.8000\), meaning 80.00% of eligible bills were on time.)
- A continuously active policy began April 1, 2021, and is predicted at its renewal on April 1, 2026. Four prior renewal opportunities have been completed. State tenure and prior renewal count, excluding the current decision. (Answer: 5.00 years of tenure and 4 completed prior renewals.)
- A customer-level claim count of 5 is copied onto three policy rows. What is the customer’s total count, and why is summing the three displayed values wrong? (Answer: 5 claims; the rows repeat one customer-level summary, so their sum of 15 double-counts the same claims.)