ML Interview Q Series: How would you design a dynamic pricing system for Airbnb, considering demand and available listings?

📚 Browse the full ML Interview series here.

Comprehensive Explanation

Building a dynamic pricing system involves predicting fluctuations in demand and setting prices that optimize for revenue, occupancy rate, or some combination of business objectives. Below is a thorough exploration of each major component needed to develop such a model:

Demand Forecasting and Feature Engineering

The core challenge is to accurately forecast demand for each listing or group of listings. You could model demand as the expected number of bookings given a particular price and set of features that reflect market conditions. Typical demand-influencing variables include:

• Calendar-based factors, such as time of year, day of the week, or upcoming holidays.

• Competition metrics, e.g., prices of nearby similar listings.

• Past occupancy rates, booking lead times, and host-specific rules.

• Macroeconomic indicators, like local events, conferences, or economic trends.

• Historical data on search queries, listing views, or user engagement.

For each listing, the goal is to extract relevant features that help predict how many bookings you will receive at various price points.

Price Elasticity and Revenue Function

A central concept in dynamic pricing is price elasticity of demand, reflecting how demand changes in response to price changes. In general, when the price of a listing goes up, the demand tends to go down. One way to capture this quantitatively is to define a function for expected revenue as the product of price and expected bookings.

A simplified version of the revenue function can be expressed as a function R of price p and input features x (which encapsulate demand signals like seasonality or local events). Let D(p, x) represent the demand function (expected number of bookings) at price p.

Where:

• R(p, x) is the revenue at price p and contextual feature vector x.

• p is the nightly rate you decide to set.

• D(p, x) is the predicted demand (expected bookings) for the listing at price p under features x (e.g., time of year, competition, etc.).

Your system aims to find a price p that maximizes the predicted revenue, subject to constraints (like ensuring minimum occupancy or adhering to host’s maximum/minimum price boundaries).

Modeling Approaches

Regression-Based Methods

A straightforward strategy is to build a regression model that forecasts demand at different price levels:

• One approach is to structure data as (features, price) → bookings. Then you choose the price that maximizes p * predicted_bookings.

• You might discretize price into buckets (like $100, $105, $110, …) and train a model that estimates demand for each bucket. Then you select the bucket leading to the highest expected revenue.

This approach requires careful collection of training data: you need varying price points for each listing over time to learn how demand changes as a function of price and other contextual signals.

Time Series Forecasting

If seasonal or temporal patterns are strong, you can employ time series methods that capture time dependencies. Common approaches include:

• ARIMA-like methods with exogenous regressors.

• LSTM or Transformer-based models in deep learning contexts.

• Temporal fusion transformers that incorporate multiple correlated time series.

Using time series forecasting, you generate a forecast of overall demand or occupancy rates for each price bracket and pick the one that offers the highest predicted revenue.

Reinforcement Learning

An alternative is to frame dynamic pricing as a sequential decision-making task. You can have an agent that sets a price each day (or hour), observes occupancy, and gets a reward (revenue). Over many episodes, the agent learns a pricing policy that maximizes cumulative revenue. This approach is powerful but typically requires a large volume of experimentation data and can be more complex to implement in a production environment.

Real-Time Updates

Your model should adapt in near-real-time to sudden changes in demand. For instance, if a big conference is announced in the city, you want your model to rapidly detect the demand spike and raise prices accordingly (while still balancing user satisfaction).

Constraints and Practical Considerations

• Minimum and Maximum Price: Hosts might specify bounds on the price.

• User Satisfaction: Excessive price spikes might hurt reputation or future demand.

• Localized Competition: If competitors drop their prices, you might need to respond to maintain attractiveness.

• Regulatory Constraints: Certain regions may limit how aggressively you can change prices.

• Seasonality: Demand in certain vacation hotspots may be extremely sensitive to seasonal effects.

• Cold Start Problem: For new listings with no historical data, you may rely on similar listings (in terms of location and amenities) to approximate demand.

Evaluation and Metrics

Common ways to measure a dynamic pricing system’s success:

• Revenue per available night: total revenue / total nights listed.

• Occupancy rate: fraction of nights that got booked.

• Booking lead time: how far in advance are guests booking relative to the check-in date.

• Profit margin: might be relevant if you have cost considerations in the model.

Example Implementation in Python

Below is a simplistic illustration of how one might approach modeling. In practice, you would have a more complex pipeline and richer feature set.

import numpy as np
from sklearn.ensemble import RandomForestRegressor

# Suppose we have training data with the following columns:
# X: Feature matrix containing variables like day_of_week, season, event, competition_price, etc.
# y: The observed bookings (demand) at a given price p_i
# prices: The actual price set for that row in the dataset

# Step 1: Train a demand regression model
model = RandomForestRegressor(n_estimators=100)
model.fit(np.hstack([X, prices.reshape(-1,1)]), y)

# Step 2: Predict demand for each price in a discrete set
possible_prices = np.arange(50, 301, 10)  # from $50 to $300 in $10 increments

def predict_optimal_price(features):
    # For each candidate price, predict demand
    demands = []
    for p in possible_prices:
        input_features = np.hstack([features, [p]])
        d = model.predict(input_features.reshape(1, -1))[0]
        demands.append(d)
    # Compute revenues for each candidate price
    revenues = [p * d for p, d in zip(possible_prices, demands)]
    max_revenue_index = np.argmax(revenues)
    return possible_prices[max_revenue_index], revenues[max_revenue_index]

# Example usage for a single day
sample_features = np.array([3, 1, 200])  # e.g., day_of_week=3, season=1, competitor_price=200
best_price, predicted_revenue = predict_optimal_price(sample_features)
print("Best price for today's listing:", best_price)
print("Predicted revenue:", predicted_revenue)

This naive method uses a random forest regression to capture the relationship between features, price, and resulting demand. Then, it exhaustively checks multiple prices and picks the one that maximizes predicted revenue. In production, you might refine this with more advanced models, continuous retraining, or reinforcement learning strategies.

Potential Follow-Up Questions

How would you deal with cold-start listings that lack historical data?

You could leverage metadata from similar listings to bootstrap predictions. For example, if a new listing is in the same neighborhood and has similar amenities as an existing, well-known property, you can transfer knowledge from the established property to the new one. Another approach is building a shared representation model (e.g., embeddings for listings) that capture location, property type, and capacity. This “similar listing” strategy alleviates the cold-start challenge by initializing the model with meaningful prior information before real data accumulates.

How do you prevent large price fluctuations from alienating users?

Sudden spikes might cause user dissatisfaction or distrust. You can impose “smoothness constraints” on price changes. For example, limit daily or weekly price changes to a certain percentage. Another method is using robust optimization techniques that account for uncertainty in demand estimates, ensuring that prices don’t overshoot if the model is not confident. Additionally, letting the user (host or property owner) set a range or specify a maximum nightly rate can keep prices within acceptable bounds for both hosts and guests.

What if the model’s optimal price leads to very low occupancy?

Your objective might need to balance both revenue and occupancy. One solution is to define a multi-objective optimization: for instance, maximize alpha * (revenue) + (1 - alpha) * (occupancy), where alpha is a chosen trade-off parameter. Alternatively, incorporate a lower bound on occupancy (like requiring 80% occupancy) to ensure the system never sets extremely high prices that drastically limit bookings.

How do you incorporate real-time signals, like an unexpected conference announcement?

If you have systems monitoring external signals (e.g., local event APIs, spikes in search volume, last-minute booking surges), feed these in as features to the model or to a specialized “override” mechanism that detects sudden demand shocks. The dynamic pricing logic can then recalculate or adjust the price more frequently. In practice, this might mean retraining or updating certain model components or applying a short-term heuristic boost to the price until the spike subsides.

Can you integrate competitor data without risking a price war?

Yes. The model can incorporate competitor prices as one of the input features but in a stabilized manner (e.g., smoothing competitor price changes over time). A full-blown price war arises when everyone’s system automatically undercuts each other in a loop. To mitigate that, you might limit the magnitude of price changes in response to competitor actions or apply game-theoretic considerations to estimate an equilibrium price level rather than reactively undercutting competition.

How would you evaluate the success of the dynamic pricing system in production?

You should run controlled experiments (A/B tests) by segmenting listings: some remain at their old pricing approach, while others adopt the new dynamic pricing algorithm. Compare revenue per available night, occupancy, and guest satisfaction (ratings, complaints, host feedback). If the new approach shows a statistically significant improvement over the baseline system, you can proceed with broader deployment.

Below are additional follow-up questions

How do you handle multiple listings for the same host who wants to manage aggregate goals, such as a total monthly revenue target?

A single host might own multiple properties, each with unique characteristics. The host may have overarching revenue or occupancy goals across all listings combined, rather than treating each property independently. One strategy is to develop an aggregated optimization layer on top of individual listing forecasts. For example, each listing can still have its own demand forecast model that predicts booking probabilities at various price points. However, an additional module can dynamically adjust target prices for each property to meet the overall host-level objective (e.g., total revenue or an even occupancy distribution across listings).

Pitfalls and edge cases include:

• Interaction Effects: If two listings are in the same neighborhood and cater to the same demographics, overpricing one might increase bookings for the other. These substitution effects need to be modeled so the overall system doesn’t skew demand unintentionally.

• Budget or Constraint Violations: The host might have constraints like “never go below a certain total monthly revenue.” If these constraints aren’t handled properly, you might violate a host’s business rules by setting suboptimal or extremely low prices.

• Computational Complexity: Combining constraints across multiple listings can balloon the search space. You may need approximate methods or heuristics (like greedy or dynamic programming) to handle the complexity.

How do you incorporate guest cancellation rates or refund policies into dynamic pricing decisions?

Dynamic pricing focuses primarily on forecasted demand, but if cancellation rates are significant, a large portion of the predicted bookings may not convert to real stays. One approach is to integrate expected cancellations into the demand function: instead of purely forecasting the probability of a booking, you forecast the probability of a booking that does not cancel. Then, your model’s revenue estimate becomes the price multiplied by the probability of a completed stay.

Key points and pitfalls:

• Refund Policy Variability: Hosts can have different cancellation policies (flexible, moderate, strict). These need to be factored in, as listings with lenient refund policies might see higher cancellation rates.

• Seasonal or Event-Based Cancellations: Travelers might be more likely to cancel off-season reservations if they find cheaper alternatives or if weather conditions worsen. Incorporating these patterns is essential to avoid overestimating realized revenue.

• Overbooking Strategies: Hotels often use overbooking strategies to hedge against cancellations. While it’s less common for individual hosts, a system that tries to overbook inadvertently might violate platform policies and anger hosts or guests. This requires a carefully balanced approach.

How do you ensure fairness and prevent biases in the pricing algorithm, especially across different neighborhoods or host demographics?

Machine learning models can inadvertently reflect historical biases if certain neighborhoods or property types historically received less demand or faced discriminatory pricing. Fairness considerations might dictate that dynamic pricing cannot deviate too drastically across neighborhoods with similar property characteristics.

Potential issues and approaches:

• Detecting Biased Predictions: Regularly analyze pricing outputs segmented by neighborhood, property attributes, or host demographics. Look for systematic underpricing or overpricing in certain regions or property types that share socio-economic attributes.

• Bias Mitigation: In post-processing steps, you can implement fairness constraints that adjust final recommended prices, ensuring equitable treatment across listings. For instance, you might ensure that price differences are explainable by legitimate factors like location or property size, rather than extraneous demographic signals.

• Explainability and Regulatory Constraints: In some jurisdictions, discrimination in pricing is illegal. Model transparency is crucial. You may need to prove that price differences are based on legitimate business factors rather than protected attributes like race or income level.

What steps would you take if significant portions of data are missing or unreliable for certain time windows or locations?

In practice, missing data can arise from system outages, delayed data logging, or new regions that only recently began collecting data. Handling data sparsity is critical.

Detailed strategies:

• Data Imputation: For numeric fields (e.g., competitor prices, occupancy rates), simple statistical methods (mean/median) or more advanced techniques (KNN imputation, autoencoders) can fill gaps. However, you must be cautious about introducing artificial correlations.

• Leverage External Signals: If internal booking data is sparse, incorporate external signals such as web traffic, local hotel booking indexes, or flight searches that might reflect travel interest in the area. These can serve as proxy indicators of demand.

• Robust Model Architectures: Employ models like tree-based methods or neural networks that can handle missing values more gracefully. In some frameworks, you can code missingness as a special category, letting the model learn that missingness itself may be informative.

• Active Learning or Targeted Data Collection: Where large gaps exist, you might deliberately experiment with different price points or run short-term promotional campaigns to gather reliable demand data. This approach helps fill blind spots and refine your model.

How do you handle model interpretability to build trust with hosts who are skeptical of dynamic pricing decisions?

Some hosts may push back against algorithmic pricing if they don’t understand how the final price is determined. Interpretable or explainable approaches can ease these concerns.

Possible strategies:

• Feature Importance: Even black-box models like random forests or gradient boosting machines can produce global or local feature importance measures. These highlight which factors (like upcoming local events or seasonal demand) most heavily influenced a price recommendation.

• Rule-Based Simplifications: In certain cases, you can pair a complex ML model with a simpler rule-based system that approximates the final decision. For example, “Your price is high because your competitor’s average rate rose by X%, and your listing’s occupancy is Y% below target.”

• Explanatory Dashboards: Provide an interface where hosts can see historical price movements, the predicted demand at each price, and the external factors (e.g., event presence or competitor changes) that led to the final recommended price. Visual transparency can reduce pushback and confusion.

How do you detect and correct systematic bias or drift in the demand model over time?

A model trained on historical data might degrade if user behavior shifts (model drift) or new competitors alter the market. Continuous monitoring is essential.

Key details:

• Performance Tracking: Collect real-time metrics such as actual occupancy vs. forecasted occupancy, average predicted revenue vs. realized revenue, and distribution of errors. Monitor these metrics over time to detect trends indicating systematic bias.

• Retraining and Incremental Learning: Frequent mini-batch retraining or online learning methods can keep the model in sync with evolving user behaviors. Alternatively, a scheduled retraining pipeline (e.g., weekly or monthly) might be sufficient if the market changes relatively slowly.

• Data Drift Detection: Tools exist to detect distributional changes in input features or target variables (e.g., you might see a sudden shift in booking lead times). When a drift threshold is crossed, re-examine or retrain the model.

How do you handle diminishing returns during peak events or holiday seasons where demand is already high?

During peak periods, demand may be so robust that a small incremental price increase might yield outsized gains in revenue, at least initially. However, demand may reach a saturation point where further price increases yield little additional revenue or risk hurting occupancy significantly.

Considerations:

• Nonlinear Demand Models: Instead of a simple linear relationship, capture potential saturation effects. For instance, demand may be relatively inelastic for the initial price increase but then become very elastic (booking rates drop sharply) beyond a certain threshold. Using piecewise or nonlinear demand curves can model this effectively.

• Segmentation by Guest Type: Some guests are price-insensitive if they need a booking during a special event, while budget travelers are highly sensitive. By identifying these segments, you might tailor your price to target the price-insensitive segment more aggressively, provided you don’t alienate other potential guests.

• Event Forecast Uncertainty: Large events (concerts, sports championships) could have volatile demand. A robust approach might incorporate uncertainty estimates in the demand predictions, preventing overly aggressive pricing.

What if cost structures vary across hosts or regions, making the profit margin more relevant than absolute revenue?

Some hosts might have unique cleaning fees, local taxes, or service charges that significantly affect their bottom line. In such cases, setting the nightly rate purely to maximize booking-based revenue might be suboptimal if operational costs are high.

Detailed approach:

• Profit Function: Instead of maximizing p * D(p, x), you could maximize (p - c) * D(p, x), where c is the marginal cost of hosting a single booking. This cost might include cleaning fees, utility surcharges, or other variable expenses.

• Varying Costs by Region: If your platform serves multiple cities or countries, costs associated with hosting might vary due to different tax regimes or local wage rates. The model needs to be region-aware so that the dynamic pricing recommendation reflects the true net benefit for each host.

• Data Collection Challenge: Collecting accurate cost data can be tricky, as not all hosts track or report these costs precisely. Approximation or host-provided cost estimates might be necessary, which introduces potential inaccuracies. Rigorous data validation or host education about the benefits of providing accurate cost details can improve performance.