Lookback Windows For Predictor History

Why Define a Lookback Window?

A predictor based on past activity is not fully defined by saying “use the customer’s history.” History could mean the last month, the last year, or all records that happen to be present in a database. Those choices can produce different values for the same person and prediction date. A lookback window specifies which portion of the past is used to construct a predictor.

The window is anchored to the prediction index date: the date and time at which the prediction is intended to be made. Its length should reflect the information the analysis is meant to capture. A short window emphasizes recent activity; a longer window includes older activity as well. The chosen window is a data-design decision, not just a coding detail.

The half-open interval makes the boundary rule explicit: an event exactly at the start is included, and an event at the prediction time is excluded. A project may use a different convention for date-only data, but it must define that convention and apply it consistently. When a prediction is made at a specific time, a record should be considered only if it was available by then; a lookback window does not make unavailable information usable.

Constructing a Historical Predictor

A window can be used to create a count, sum, average, indicator, or other summary of historical records. For example, an insurer might count recent service calls for a policy, total prior claim payments for an account, or flag whether a customer had any late payments in a defined period. These are different predictors, even when they use the same window.

For a count of events, write the predictor for record \(i\) as:

where \(s_{ij}\) is the timestamp of historical event \(j\) associated with prediction record \(i\), and \(I(\cdot)\) equals 1 when the condition is true and 0 otherwise. A sum of event amounts can be defined similarly by summing each event amount only when its timestamp falls in the window.

The same window rule must be applied separately to each prediction index date. If one customer has multiple prediction dates, the historical records selected for one prediction may differ from those selected for another. The window is attached to the prediction, not permanently to the customer.

What Changes When the Window Gets Longer?

For the same prediction time and the same underlying event records, a longer trailing window contains every event from a shorter window, plus any events in the additional earlier period. This gives a useful check for count and nonnegative amount predictors: their values cannot decrease as the window expands, provided the records are equally complete and are measured using the same rules.

The reason is set inclusion. Every event counted in the shorter interval also falls in the longer interval. The longer-window count adds the number of events in the earlier portion \([t_i-L_2,t_i-L_1)\), which cannot be negative. This reasoning applies to event counts and sums of nonnegative amounts; it does not automatically apply to averages, signed amounts, or predictors whose definition changes with the window.

A longer window does not simply provide “more accurate” information. It may capture persistent behavior, but it may also give substantial weight to activity that is no longer relevant to the current prediction. A short window may respond more quickly to recent changes but omit useful evidence about less frequent events. The appropriate choice depends on the prediction task and on a clear rationale for the history being summarized.

Window Length, Coverage, and Interpretation

A window definition includes more than a number. It should specify the anchor, the duration and its unit, the endpoint convention, the event being counted or summarized, and any eligibility rule for records. “Count contacts in the prior 90 days” is clearer than “count recent contacts,” but still needs an explicit rule when timestamps are rounded to dates or when records arrive late.

Also check whether the data source actually covers the full window for each prediction. If an account first appears in the records 45 days before the index date, a 90-day count from the available extract is not necessarily a true 90-day history. It could be a count from only the observed 45 days. Missing history should not silently be treated as zero activity. At minimum, distinguish a genuine zero in a fully observed window from a count based on partial observation.

When comparing windows, be precise about what the feature means. A raw count over 365 days will often exceed a raw count over 30 days simply because it covers more time. Those two counts answer different questions. Dividing by window length to create an average rate changes the predictor’s definition; it does not make the original counts directly interchangeable. Such choices should be stated explicitly rather than hidden in a data-processing step.

Common Exam Traps

• Using a calendar label instead of a duration. “Previous year” could mean the prior calendar year or the preceding 365 days. State which one is intended.
• Reversing a boundary rule. Under the convention here, the window start is included and the index time is excluded. Check records exactly on either boundary.
• Including information after the prediction. A record after the index time is not historical information for that prediction, even if it is present in the final data extract.
• Treating absent history as a zero count. A zero means no qualifying events in an observed window; missing coverage does not establish that no events occurred.
• Assuming a longer window is always better. Longer and shorter windows capture different time scales. Their merits depend on the intended predictor and task.