ML Interview Q Series: How would you design an occupancy forecasting model, gather training data, and evaluate its performance?
📚 Browse the full ML Interview series here.
Comprehensive Explanation
Building a model that predicts hotel occupancy for a particular date involves treating occupancy rate as a continuous target. In practice, occupancy rates typically range from 0 to 1 if interpreted as a fraction, or from 0% to 100%. A suitable strategy is to collect relevant features (including historical occupancy data, seasonal patterns, local events, pricing fluctuations, and marketing information) and train a supervised regression model that forecasts occupancy on future dates. Another approach is to treat it as a time-series forecasting problem, leveraging either classical or deep learning methods.
Data Requirements
Data is central to creating a reliable forecast. For occupancy prediction, common data sources include historical occupancy rates, the total number of bookings made each day, cancellations, events or holidays, room availability, pricing schemes, and external factors such as weather. Integrating promotional campaigns, competitor actions, and traveler demand trends can further improve prediction accuracy.
Historical occupancy data for each hotel date pair is particularly important because it captures recurrent temporal patterns and demand cycles. Many hotels exhibit significant seasonality due to vacation periods, holidays, or local festivals. Incorporating these aspects helps the model detect and quantify the impact of recurring spikes or dips in occupancy. Data that reflects booking lead times, especially the distribution of how far in advance guests book, can also enhance the model’s ability to predict occupancy for future dates.
Modeling Approaches
A typical way to formulate the problem is via a regression model, with occupancy as a continuous variable. When dealing with time-varying data, a time-series forecasting model, such as ARIMA or LSTM (Long Short-Term Memory) networks, can be employed. In more complex settings, ensembles of tree-based regressors (like Random Forest or Gradient Boosting) can yield robust performance if fed with the right time-dependent features.
Including features that capture temporal aspects (e.g., the day of the week, holiday flags, special events) and deriving lag features (e.g., occupancy from the previous day, week, or month) are common feature engineering steps. If deep learning architectures such as an LSTM or a Temporal Convolutional Network (TCN) are used, they can learn long-term dependencies automatically, although they may require larger amounts of data.
Example of a Regression Loss Function
One of the most common objective functions for regression-based occupancy forecasting is Mean Squared Error (MSE). A well-known measure derived from MSE is Root Mean Squared Error (RMSE). The formula for MSE can be expressed as follows:
where n is the number of samples, y_i is the actual occupancy rate on the i-th sample, and \hat{y}_i is the predicted occupancy rate on the i-th sample. Minimizing MSE pushes the model to reduce the squared difference between the forecasted and actual values.
RMSE is simply the square root of MSE, which keeps it in the same unit as the original target:
Model Evaluation Strategy
Predictive accuracy on unseen future dates is critical. To evaluate time-series predictions, it is recommended to use a rolling or sliding window approach that respects temporal ordering rather than random shuffling, ensuring that training is always performed on data preceding the test set. Common error metrics for occupancy forecasting include RMSE, Mean Absolute Error (MAE), and Mean Absolute Percentage Error (MAPE). In some hotel management scenarios, MAPE can be especially intuitive, because management might care about percentage deviations in predicted occupancy.
Potential Implementation Outline
Training a regression or time-series model in Python might follow these steps:
import pandas as pd
import numpy as np
from sklearn.model_selection import TimeSeriesSplit
from sklearn.ensemble import RandomForestRegressor
from sklearn.metrics import mean_squared_error
# Assume we have a DataFrame df with columns:
# 'date', 'occupancy_rate', 'day_of_week', 'is_holiday', 'average_daily_rate', etc.
# Sort by date
df = df.sort_values('date')
# Create features and labels
features = ['day_of_week', 'is_holiday', 'average_daily_rate', 'lead_time', 'event_indicator']
X = df[features]
y = df['occupancy_rate']
# Time-based split
tscv = TimeSeriesSplit(n_splits=3)
for train_index, test_index in tscv.split(X):
X_train, X_test = X.iloc[train_index], X.iloc[test_index]
y_train, y_test = y.iloc[train_index], y.iloc[test_index]
model = RandomForestRegressor(n_estimators=100)
model.fit(X_train, y_train)
predictions = model.predict(X_test)
rmse = mean_squared_error(y_test, predictions, squared=False)
print("Fold RMSE:", rmse)
The approach above uses a Random Forest regressor, but the same idea could be implemented with an LSTM or a gradient boosting model, where the primary difference would lie in how time-series features are fed or how the network is shaped.
Practical Considerations
A variety of real-world considerations can arise. In hotels, occupancy is influenced by unexpected events, major citywide conferences, and changes in marketing strategy. Data might also have missing values or outliers from partial system outages or measurement errors. Ensuring data quality and maintaining model retraining procedures are essential.
Since occupancy has an upper bound (the number of total rooms), advanced techniques like quantile regression or hierarchical forecasting might be explored to account for the maximum capacity constraints. Proper hyperparameter tuning and regular model updates can help maintain accuracy over time.
How to Handle Edge Cases
One subtlety arises in cases of limited historical data for a newly opened hotel. Bootstrapping methods or transferring knowledge from similar hotels in the same region can help. Another edge scenario involves abrupt shifts in external conditions, such as global travel restrictions. In that context, model performance heavily depends on how quickly retraining is performed or how effectively the model can adapt to distribution shifts.
Follow-up Questions
How would you incorporate external data such as local events or promotions into the model?
Such external variables can be encoded as additional features (e.g., event_indicator=1 if a major event is in town). Depending on data granularity, one might also create numerical features capturing expected event attendance or promotional campaign intensity, which could then be fed into a regression or time-series model. In a deep learning setup, one could add this information as separate input channels or embedding vectors. The goal is for the model to correlate these external factors with changes in occupancy.
Why might you prefer a time-series model like ARIMA over a standard regression model, or vice versa?
A purely time-series approach like ARIMA can capture autocorrelation and seasonality in the data with minimal domain knowledge. However, if you have many diverse covariates (pricing, competitor moves, campaigns, external data), a regression or a machine learning method that handles multiple features might be more suitable. Complex time-series architectures like LSTM can combine the best of both worlds by learning from both temporal patterns and exogenous features.
What strategies would you use to mitigate cold start issues for newly opened hotels?
When a hotel has insufficient booking history, transfer learning can be employed by training a global model across multiple hotels. Parameters learned from established hotels, especially those in a similar market, can be fine-tuned for the new hotel. Alternatively, one could rely more on externally sourced signals (like market-level demand trends or competitor occupancy if available) until sufficient data for the new hotel is accumulated.
How do you ensure your model remains accurate over time?
Regular model retraining is essential to address distribution shifts in the data. If the hotel changes its pricing drastically, or if economic conditions fluctuate, existing historical patterns might no longer apply. Monitoring forecast errors and implementing automated retraining pipelines can keep the model aligned with recent changes. Incorporating rolling windows or an expanding window training approach are also viable ways to adapt the model continuously.
How would you handle scenario-based forecasting?
Scenario-based forecasting might be needed if management wants to see how occupancy would respond to hypothetical strategies such as a 10% price cut or a new marketing campaign. This could be achieved by retraining or re-running inference with modified feature inputs that reflect the hypothetical condition (price=price*0.9 for the 10% discount case) and observing how the predicted occupancy changes. Advanced techniques like counterfactual analysis can also be integrated to estimate causal impact.
What if there is an upper limit on occupancy?
Since occupancy cannot exceed 100% (or 1.0 if it is expressed as a fraction), some practitioners might train the model on a logit-transformed version of the occupancy rate. This ensures predictions remain within feasible bounds once inverted back. Another approach is to clamp predictions at the maximum possible occupancy level, though a transformation-based approach is often more mathematically consistent.
All of these considerations highlight how building a robust occupancy prediction system requires careful feature engineering, thoughtful model selection, appropriate evaluation strategies, and a plan for continual maintenance to address real-world complexities.
Below are additional follow-up questions
How do you handle situations where the ratio of out-of-date features to live features becomes large over time, leading to potential data leakage?
When a model leverages features that indirectly reveal future information, it can lead to data leakage. For instance, if an external dataset is not properly synchronized (e.g., a pricing feature updated after the booking date), it might inadvertently leak “future” knowledge. To mitigate this, you should:
Strictly Align Feature Timestamps: Ensure that each feature represents only the information available at the moment the prediction is made. If you are predicting occupancy for a date a month out, do not include any data captured after that date.
Maintain a Consistent Feature Update Process: The same pipeline that runs in production to feed real-time or near real-time features must be reflected in your historical data preparation. This avoids introducing signals in your training dataset that the model would not have at inference time.
Periodic Audits: Conduct regular audits on your data engineering pipeline. Validate that the time-based dependencies are logically correct and that you are not mixing past and future data in a way that the model gains unfair foresight.
Potential Pitfalls or Edge Cases:
Calendar Data Overlaps: If you are pulling external data related to events or promotions, confirm that you only use those events labeled before or on the day your forecast is generated. If an event was announced last minute, historically, you might inadvertently assign knowledge of that event to earlier forecast time windows.
Delayed Updates: If the booking data for certain hotels is updated with a delay, you might risk feeding partial or inconsistent snapshots of occupancy. Having proper time-window filtering for each data source helps manage this challenge.
How would you deal with the complexity of combining multiple data sources, such as flight arrivals data, competitor pricing data, and local event data, into a single model?
Combining many data sources can significantly improve model accuracy, but it poses several challenges:
Data Engineering Complexity: Each data source might come at different levels of granularity, update times, and reliability. For example, flight arrivals data may be daily aggregated counts, competitor pricing might be scraped multiple times a day, and local event data might come from an external third-party calendar. You need a well-designed data pipeline that aligns these sources with a shared timeline.
Feature Selection and Dimensionality: When appending multiple sources, the number of potential features can grow rapidly. Feature selection techniques—like regularization-based methods (L1 penalty) in linear models or feature importance metrics in tree-based models—help highlight which data sources genuinely contribute predictive power.
Model Architecture:
Classical Approaches: A gradient boosting regressor (like XGBoost or LightGBM) can handle many numeric and categorical features.
Deep Learning: Multi-branch neural networks can learn specialized representations from each data source before combining them in a final layer. This approach can capture complex interactions among flight data, competitor prices, and historical occupancy.
Potential Pitfalls or Edge Cases:
Data Latency: If flight data or competitor prices are only updated weekly, but your occupancy predictions need to be daily, mismatched frequencies might generate stale signals or partial updates. Align the refresh intervals so your model always operates on the best available data.
Overfitting Risk: With a large volume of features, it’s easier for models to memorize quirks in the training set. Proper cross-validation (especially time-series aware) and careful hyperparameter tuning are critical to avoid overfitting.
Integration Errors: Merging multiple sources can lead to subtle merging errors (duplicate keys, missing records), so robust data auditing is essential.
How would you approach the problem of interpretable predictions, given that many stakeholders (managers, revenue teams) may want a clear explanation for occupancy forecasts?
Interpretability can be crucial in environments where decisions have significant financial implications and stakeholders want a rationale for trusting the forecast:
Tree-Based Models and Feature Importances: Methods like Random Forest or Gradient Boosting produce global measures of feature importance. You can also employ SHAP (SHapley Additive exPlanations) to compute local attributions that explain each prediction.
Partial Dependence Plots (PDPs): For a given feature (e.g., price), a partial dependence plot reveals how changes in that feature typically affect the predicted occupancy. This helps hotel managers understand how price changes could shift demand.
Surrogate Models: If you use a complex ensemble or deep neural network, you can train a simpler, more interpretable surrogate model on the same inputs and predictions, then use it to approximate decision boundaries. While not perfect, it offers stakeholders a conceptual explanation.
Potential Pitfalls or Edge Cases:
Oversimplified Explanations: Even with SHAP, explanations might be misinterpreted if the stakeholder does not grasp that these are conditional associations rather than guaranteed causation.
Model Updates: When you retrain or update the model regularly, the interpretation might shift. You need a version-control system for both the model and its explanation artifacts to ensure consistency in communication.
Conflict with Business Heuristics: If your interpretable results clash with established business heuristics (e.g., “summer is always busy”), you need to demonstrate data-driven evidence to gain stakeholder trust.
How do you adapt or update your forecasting model when the hotel changes its pricing strategy drastically or there is a significant shift in market demand?
Significant shifts in the environment can cause the model to produce inaccurate forecasts unless it is adapted:
Incremental Learning or Online Learning: Some algorithms (like online versions of gradient boosting or neural networks with partial re-training) can accommodate new data as it arrives, allowing the model to capture shifts faster.
Frequent Retraining: For bigger changes in distribution, it might be more reliable to completely retrain the model every certain interval (e.g., weekly or monthly) using the most recent data window. Ensure hyperparameter tuning is part of this retraining process to account for major distribution changes.
Model Monitoring: Set up real-time or near real-time monitoring of forecast error (e.g., MAPE, RMSE). If errors exceed a threshold, trigger an alert or an automated retraining pipeline.
Potential Pitfalls or Edge Cases:
Over-Reacting to Noise: While frequent retraining is beneficial, it can also cause the model to overfit transient fluctuations if the model is updated too often without proper smoothing or robust cross-validation.
Simultaneous Changes: Market shifts and internal policy changes might coincide, making it difficult to isolate causes of forecast errors. You might need advanced tracking or A/B testing to disentangle the impact of each factor.
How do you handle situations where occupancy predictions need to be combined with dynamic pricing decisions to maximize revenue?
When occupancy forecasts inform dynamic pricing, the system becomes more complex, because the model’s predictions can directly alter the data it sees in the future:
Closed-Loop System: Recognize that your forecast influences price adjustments, which in turn change booking behaviors. Consider a reinforcement learning approach, or at least a feedback-aware solution, where the model anticipates that a price change might shift demand.
Separate Forecasting and Optimization Steps: Many revenue management systems first forecast demand under different hypothetical prices, then select the price that maximizes expected revenue. This “two-layer approach” helps maintain some interpretability and modularity.
Business Constraints: There may be rules, such as not pricing below a certain threshold or not exceeding a set limit. Ensure your pricing strategy respects these constraints, and adapt your forecasting approach to handle the resulting demand patterns.
Potential Pitfalls or Edge Cases:
Cyclic Feedback: If the forecast incorrectly predicts high demand, the system might raise prices excessively, deterring customers, and leading to lower occupancy. This negative feedback loop must be carefully monitored.
Lag in Behavioral Change: Travelers might react to price shifts with a delay, especially if bookings happen weeks or months in advance. Modeling leads and lags is essential in capturing the real effect of price changes.
Ethical and Regulatory Issues: Some regions have restrictions on surge pricing or anti-gouging laws. Ensure that the dynamic pricing logic complies with local regulations and fairness considerations.
How do you handle special cases where the hotel has multiple room types and each has a different demand pattern?
When the hotel offers multiple room categories (e.g., standard rooms, suites, deluxe suites), each may have distinct booking behaviors:
Multi-Output Forecasting: Instead of predicting overall occupancy, forecast occupancy per room type. This can be approached either by fitting separate models or a single multi-output model that predicts multiple occupancy rates simultaneously.
Aggregated vs. Granular Approach: While aggregated forecasts provide a broad overview, demand for a suite might differ from demand for a standard room, especially for premium events. Granularity can significantly improve operational decisions, like when to close out cheaper rooms or run promotions.
Cross-Category Interactions: Sometimes standard rooms sell out first, pushing late customers to book premium rooms. Incorporating cross-influence between categories can capture substitution effects and lead to better global accuracy.
Potential Pitfalls or Edge Cases:
Sparse Data in Premium Categories: Suites or specialized room types might have fewer bookings, leading to a scarcity of training data. Transfer learning from more popular categories or grouping similar room types might help.
Pricing Differences: If each room type can be priced independently, the complexity increases further. A multi-dimensional dynamic pricing approach may be needed, which can complicate both the modeling and the interpretability.
How do you measure success beyond just forecast error? Are there other metrics or considerations you would evaluate?
While statistical metrics such as RMSE, MAE, and MAPE are standard, real-world performance can also be measured by:
Revenue Impact: Compare expected revenue vs. actual revenue over certain time windows to see if improved forecasts translate into better financial outcomes.
Occupancy Variance: Even if the average forecast is accurate, large daily variability could cause operational issues. Tracking the day-by-day volatility of errors helps detect such issues.
Operational Efficiency: Hotels may need to staff housekeeping, front desk, or restaurants based on forecasted occupancy. Monitoring whether staff scheduling aligns with actual occupancy is crucial for assessing operational success.
Customer Satisfaction: Overbooking or last-minute changes due to forecast errors can negatively affect the guest experience. Monitoring complaints or rebooking incidents can be an indirect but important success indicator.
Potential Pitfalls or Edge Cases:
Conflict Among Metrics: Maximizing revenue might conflict with stable staffing. A model could consistently underestimate occupancy, leading to more employees called in last-minute, while revenue might remain relatively stable. A balanced approach with multiple KPIs is necessary.
Lagging Indicators: Metrics such as customer satisfaction or total revenue can manifest over longer periods. An abrupt model change might not reveal improvements (or detrimental effects) immediately.
How do you handle transfer learning across multiple hotels owned by the same chain, each in different geographic markets?
Transfer learning can enhance forecasting when certain hotels have limited historical data:
Global Model: Train a single model on data from multiple hotels, allowing it to learn shared patterns (e.g., day-of-week or holiday effects) while also incorporating hotel-specific features like location or brand category.
Fine-Tuning: Start with a global model, then fine-tune for each hotel’s local data. This approach can quickly adapt the model to the nuances of each property (e.g., a coastal resort vs. a city hotel).
Meta-Learning: Sometimes you can train a meta-learner that selects or weights the forecast from different base models specialized in different contexts. This might help handle edge cases like hotels in high tourist areas vs. those catering to business travel.
Potential Pitfalls or Edge Cases:
Data Heterogeneity: Hotels in vastly different climates or cultures may have drastically different seasonality patterns. A single global model might obscure these differences unless it includes the correct location-related features or segmentation.
Over-Generalization: If one large hotel chain in a popular city has a big portion of the dataset, the model could overfit to that city’s booking patterns, performing poorly on smaller hotels in less popular regions.
Privacy and Data Sharing: Even within the same company, there might be regulatory or contractual constraints about combining data. Ensure compliance before pooling or transferring data across jurisdictions.
How would you adjust the training process if there is high seasonality but also a constant influx of last-minute bookings?
Seasonality refers to predictable fluctuations (e.g., weekends, holidays, summer breaks), while last-minute bookings add additional randomness:
Seasonality Features: Incorporate explicit cyclical features (e.g., day-of-year, day-of-week, month) and holiday/event flags to help the model capture regular patterns.
Booking Curve Modeling: In many forecasting systems, you track occupancy as a function of time-to-arrival (the “booking curve”). For instance, you might forecast occupancy 30 days out, 29 days out, etc. This helps capture last-minute influx as the date approaches.
Advanced Time-Series Models: Techniques like Prophet or LSTM networks can combine seasonality decomposition with dynamic patterns for last-minute surges.
Potential Pitfalls or Edge Cases:
Sudden Demand Spikes: If an airline strike forces many travelers to book alternative accommodations at the last minute, the historical pattern may not replicate. Real-time anomaly detection can alert revenue managers to manually override the forecast.
Data Granularity: If you only keep daily snapshots of occupancy data, you might lose sub-day booking curve granularity. More frequent snapshots or streaming data can better capture last-minute reservations.
How would you integrate confidence intervals into occupancy forecasts to help hotel managers plan for uncertainty?
Providing a point estimate (e.g., expected occupancy = 80%) is helpful, but a confidence interval can guide risk mitigation strategies:
Statistical Methods: Classical time-series models (e.g., ARIMA) often produce confidence bands by assuming a specific error distribution. You can transform these into occupancy intervals.
Ensemble or Bootstrapping: In tree-based or neural methods, you can create an ensemble of models with slightly varied training data or hyperparameters. The distribution of predictions across the ensemble yields a plausible range for occupancy.
Probabilistic Forecasting: Consider models that directly model the distribution of the forecast (e.g., Gaussian Processes, quantile regression, or neural networks with probabilistic outputs). Hotel managers can see a p50 or p90 forecast to prepare for worse or best-case demand.
Potential Pitfalls or Edge Cases:
Overconfident Intervals: If the underlying assumptions (like normal residuals) are wrong or if your model does not capture heavy tails, intervals might be systematically too narrow.
Event-Driven Spikes: Confidence intervals can fail if large events cause outlier behavior not present in training data. In such cases, scenario-based forecasting might be more appropriate, where you create separate forecasts for event and non-event scenarios.
How do you manage missing data or inconsistent records that arise from different hotel management systems?
Missing data can occur if some hotels fail to report occupancy on certain dates or if system upgrades cause partial data collection:
Data Imputation: Techniques like forward fill, backward fill, or interpolation can be used for continuous data. If entire days are missing, you might use an average of neighboring days, but be cautious about introducing bias.
Feature Engineering: Create a missing indicator feature that flags whether data for a particular field is missing. This can help the model learn patterns about when data might be less reliable.
Data Quality Checks: Have automated checks to flag anomalies in real-time. For instance, if occupancy is reported as 120% for a day, that likely indicates an error or a data synchronization problem.
Potential Pitfalls or Edge Cases:
System Migrations: Moving to a new property management system might lead to a shift in how occupancy is recorded. Ensuring old and new records align properly is critical.
Biased Imputations: Forward-filling holiday occupancy into non-holiday periods can distort the training distribution. Always keep track of context, such as weekends or peak seasons, when imputing values.
How do you handle partial cancellations and no-shows, which create discrepancies between forecasted and actual occupancy?
Cancellations and no-shows can drastically alter the final occupancy, especially if the model only has data on initial bookings:
Cancellation Probability Model: Build a sub-model that estimates the probability of a given booking being canceled or resulting in a no-show, factoring in variables like cancellation policies, booking channel, and lead time. Multiply predicted occupancy by (1 - expected cancellation rate).
Booking Curve Adjustment: Occupancy can be predicted by combining “booked units” minus expected cancellations at each lead time. As you get closer to the arrival date, your estimates become more accurate.
Real-Time Updates: If you observe last-minute cancellations, it might be too late to resell rooms at certain times. A short-horizon forecast that updates daily or multiple times a day can mitigate these fluctuations.
Potential Pitfalls or Edge Cases:
Clustering of Cancellations: In scenarios where group bookings are canceled en masse or inclement weather leads to widespread no-shows, standard cancellation models might underestimate the scale of the impact.
Policy Changes: If cancellation fees or booking deposit policies change, the historical cancellation rates may no longer apply. The model must be re-evaluated post-policy change.
How would you ensure the forecast remains robust if a new competitor enters the market or if the hotel expands its capacity?
Major structural changes can shift both supply and demand:
Capacity Expansion: If the hotel adds new rooms, historical occupancy rates may not directly translate to the new capacity. You might transform occupancy counts into a demand measure and then relate them back to the new capacity.
New Competitor: Integrate competitor data if available. If it is not, monitor changes in occupancy error over time. A sudden increase in forecast error could indicate the competitor is siphoning demand. In such a case, you may need to refine your features to include competitor presence as a new factor.
Regularly Updated Baseline: Have a baseline “market demand” model, tracking total demand in the region (occupancy across all hotels or aggregated booking volumes if possible). Compare the hotel’s share of that market to determine if shifts are due to new competition or internal factors.
Potential Pitfalls or Edge Cases:
Short Historical Window: Right after capacity expansion, data on how the market reacts to the larger number of rooms is minimal. Hybrid or transitional models that rely partly on historical occupancy (with older capacity) and partly on external market trends can help bridge the gap.
Hidden Competitors: Startups or short-term rental platforms (like Airbnb) might not have easily visible pricing or capacity data. The model might become inaccurate if significant market share suddenly diverts to such platforms.
How do you handle real-time data ingestion and near real-time forecasting if the hotel wants updated predictions throughout the day?
Many modern revenue management systems update demand forecasts multiple times a day:
Streaming Data Pipelines: Use platforms like Apache Kafka or AWS Kinesis to capture booking changes, cancellations, and external data feeds (e.g., flight info, competitor rates) in real time.
Micro-Batch Processing: A practical approach is to re-run the forecast pipeline every few hours in a micro-batch manner. This ensures you capture the most recent changes without overburdening the system.
Incremental Model Updates: If your model supports incremental learning (online learning), you might incorporate the new data as soon as it arrives, continuously refining the forecasts.
Potential Pitfalls or Edge Cases:
Latency and Throughput Constraints: Real-time systems must maintain fast processing speeds. A complex deep learning model might become computationally expensive if updated too frequently. You might use lighter-weight models for real-time inference and heavier models for a daily retrain cycle.
Data Consistency: Real-time data can arrive out of order or with delays. Implement robust checks to ensure you do not produce forecasts based on incomplete or mis-ordered data streams.
Frequent Retraining Overfitting: Updating the model every few hours can cause overfitting to transient anomalies, like a spike in bookings due to an isolated event. Introduce smoothing mechanisms or aggregate updates over longer windows to filter noise.