Machine Learning Pipeline (core_v2)

Goal of this chapter: Understand how the machine learning model works in plain English, how features are selected, how future data leakage is prevented, and how we explain model predictions.

1. What Does the Model Actually Do?

At its heart, our machine learning model answers one practical question:

“Given everything we know about this restaurant up to last week, how much sales (GMV) should we expect it to make in the coming week?”

By comparing this expected baseline against recent marketing exposure, the system easily spots:

• Over-performers: Restaurants generating more sales than expected even without marketing (Great candidates for extra ad push!).
• Under-performers: Restaurants lagging behind their historical potential (May need menu adjustments or operational help).

2. Model Architecture: LightGBM Regressor (core_v2)

We use LightGBM (Light Gradient Boosting Machine).

Why LightGBM?

1. Speed & Efficiency: Trains on hundreds of thousands of weekly restaurant records in under 3 minutes.
2. Handles Non-Linear Trends: Easily captures seasonal dining spikes, holiday rushes, and abrupt momentum changes.
3. Robust to Outliers: Extreme banquet bookings or single massive corporate reservations do not distort the overall predictions.

Evolution to core_v2:

• Legacy Prototype (v1): Trained on raw unscaled revenue data from an early Bangkok sample. In that prototype, GMV was inflated by ~10x due to uncalibrated data fields, resulting in unrealistic predicted weekly sales (often exceeding ฿3,000,000/week).
• Current Production (core_v2): Retrained strictly on clean net GMV (total_price_v2_cents / 100.0). The output predictions now reflect realistic, actionable weekly GMV ranges (averaging ฿350,000 to ฿500,000 per active bookable restaurant).

3. The 80 Pruned Features

Rather than throwing hundreds of noisy columns into the model, the pipeline carefully engineers and prunes 80 high-signal features divided into 4 core buckets:

graph TD
    subgraph FeatureFamilies["80 Engineered Features"]
        F1["<b>1. Booking & Revenue Momentum (35)</b><br/>Rolling 4w/8w/12w averages, week-over-week % growth, guest cover velocity."]
        F2["<b>2. Marketing & Exposure History (20)</b><br/>Facebook ad spend, KOL visits, reach, app push sent count (4w & 8w lags)."]
        F3["<b>3. Customer Ratings & Sentiment (15)</b><br/>Average star rating, review volume trends, positive vs negative sentiment score."]
        F4["<b>4. Restaurant Attributes & Seasonality (10)</b><br/>Cuisine type, city/neighborhood, pricing tier, public holiday calendar flags."]
    end

Feature Selection & Noise Removal:

• Multicollinearity Elimination: Highly correlated duplicate features (Pearson correlation $r > 0.85$, such as redundant 7-day and 14-day booking counts) were removed to keep the model fast and stable.
• Low Variance Filter: Features that rarely change (e.g., historical fields with zero changes in 6 months) were discarded.

4. Preventing Data Leakage (The $(t-1)$ Lag Rule)

A common mistake in retail and restaurant data science is data leakage—accidentally letting tomorrow’s data influence today’s prediction.

       WEEK t-1 (Past Week)               WEEK t (Current Week)
  ┌───────────────────────────────┐     ┌───────────────────────┐
  │ • Valid Bookings from Week t-1│     │                       │
  │ • Ad Spend from Week t-1      │ ──► │  PREDICT:             │
  │ • Reviews from Week t-1       │     │  Expected GMV Week t  │
  └───────────────────────────────┘     └───────────────────────┘

Important

Strict $(t-1)$ Lag Rule:
When predicting sales for Week $t$, the model ONLY sees features from Week $t-1$ and older. Current-week reservations or in-flight ad spend are strictly excluded from the training input. This ensures the model learns true predictive foresight rather than memorizing current results.

5. Walk-Forward Temporal Validation

Standard random cross-validation (shuffling rows like a deck of cards) fails on time-series data because the model would cheat by looking into the future.

Instead, we use Walk-Forward Validation:

• Train Window: Past 52 weeks of historical data.
• Validation Window: The subsequent 4 weeks.
• The window rolls forward week by week, testing how well the model predicts genuinely unseen future weeks across various seasonal cycles.

Split 1: [ Weeks 1 to 52 (Train) ] ──► [ Weeks 53 to 56 (Test) ]
Split 2: [ Weeks 5 to 56 (Train) ] ──► [ Weeks 57 to 60 (Test) ]
Split 3: [ Weeks 9 to 60 (Train) ] ──► [ Weeks 61 to 64 (Test) ]

6. Model Explainability with SHAP

Machine learning shouldn’t be a black box. Marketers and account managers need to know why a restaurant received a high or low priority score.

We compute SHAP (SHapley Additive exPlanations) values for every prediction:

1. Global Importance (What matters overall?):
   • Rolling 4-week GMV momentum is the strongest predictor of future sales.
   • Recent customer review ratings provide the strongest quality safeguard.
   • Recent ad spend provides short-term promotional lift.
2. Local Explanation (Why this restaurant?):
   • On the Restaurant Deep Dive tab of the dashboard, users see a clear breakdown showing which specific factors pushed a restaurant’s score up or down (e.g., “+15% due to 4 consecutive weeks of review score >4.8”, “-20% due to no marketing activity in 60 days”).

7. Next Steps

To see how marketers and account managers use these predictions in the web interface, proceed to 05. Dashboard User Guide.