Solving the Right problem at the Right time matters

Traffic Forecasting for Retail Stores (2013)

I was part of the team that worked on Traffic Forecasting for Retail Stores:

• Multiple stores across geographies
• Multiple DBs for each local store

The forecasting system used to run at Enterprise, synchronize data to local stores with their own internal synchronization jobs.

These jobs were configured to run according to time zones of stores.

The algorithms were mostly around:

• Weighted moving average
• Trend + moving average

The forecast job runs leveraging previous data and predicts forecasts for the next day, hourly basis patterns.

The actuals are captured the following day and measured against it.

In case of data not present, sister stores (similar stores) data was leveraged for calculation.

Considerations Back Then

Whatever we say as of today—measure model drift, missing data features, work at scale— all of them were considered, and the system was built on top of the existing transaction system as server components, custom-built.

What We Missed

• Instead of traffic forecast, if we had done a sales forecast, it would have helped to apply solutions for both eCommerce and retail stores.
• We had inherent details of out of stock, replenishment alerts. The same could have been used for out of stock forecast per zone, replenishment forecast per zone.
• These real-time reports from RFID could have served as effective forecast opportunities on the same.

Reflection

Sometimes we may have the right #technology and #architecture, but not the right #usecases.

Now I see the same things ML attempts to do with #kubeflow, #pipelines, #scale, but the same problem which was solved with models available at that point in time would take a different set of skills to solve today. ??