Define the prediction moment
Suppose a lender predicts default when an application is submitted on 10 March at 10:00. The target might be whether the account defaults during the next 90 days; the input features must be available to the prediction system at 10:00. A payment missed in April may be highly predictive, but including it in the March feature vector reveals the outcome window. A historical dataset built using current account balances has the same problem if those balances incorporate later activity.
For a delivery-delay model, write down the prediction moment, the outcome window, and one feature that is unavailable at that moment. Compare a model run at order placement with one run when the package leaves the warehouse.
Event time is not always availability time
An event can occur before a prediction but arrive in the warehouse after it. For example, a purchase occurs at 09:55 but is ingested at 10:15. A 10:00 decision could not have used it if the serving system had no other way to access it. Reconstruct each example using only records available by its decision time. Where late arrivals or corrections matter, retain both event and ingestion or publication timestamps and preserve historical versions. A single timestamp is insufficient if it does not reflect when a value was actually available.
An event occurs at 09:55, is ingested at 10:15, and is corrected at 11:00. Which version is available for a decision at 10:00, 10:30, and 11:30? State your assumption about which system serves the feature.
Split first, then learn transformations
For future-facing predictions, a chronological split often matches deployment better than a random split. Choose training, validation, and final test periods, and allow the outcome window to mature before labeling examples. Fit imputation values, scaling parameters, category encoders, and feature selection using training data only; apply the fitted transformations to later periods. If examples share an entity, also decide whether the intended use case requires testing on unseen entities. A random split can otherwise let the same customer’s future behavior influence the past.
You predict default within 90 days for applications submitted through 31 March. What is the earliest date on which all outcomes in that cohort can mature, assuming no reporting delay? Answer: 29 June in a non-leap year. Explain why a real pipeline may need additional time for reporting and corrections.
Use point-in-time lookups carefully
BigQuery provides ML.FEATURES_AT_TIME for a shared cutoff and ML.ENTITY_FEATURES_AT_TIME for lookups across entities and timestamps. A timestamp cutoff only prevents leakage if the stored timestamp and retained history represent information available at the decision time. Check late-arriving updates, correction semantics, missing feature values, and online/offline consistency. Document the feature definition, owner, freshness requirement, and behavior when no eligible historical value exists.
For two customers scored at different times, explain why a single shared cutoff may give the wrong historical feature values. Choose the per-entity, per-time lookup and verify what happens when no earlier feature record exists in your design.
A transaction occurred before a historical prediction but was first available to the serving system afterward. Should it be included in that prediction’s reconstructed feature vector?
Keep exploring
- Practice: offline point-in-time feature lab ↗
- Practice: BigQuery ML time-split lab ↗
- BigQuery feature serving and point-in-time correctness ↗
- ML.FEATURES_AT_TIME reference ↗
- Tabular training data best practices ↗
Use the official certification page and its linked resources to validate your coverage. For guided labs, explore the Google Skills learning path. Revisit the practical exercise and explain your decision in your own words before moving on.