I've got a sales forecasting model using the fbprophet
library.
The model is additive: calculates a base trend
and then adds modifiers for each component/feature, like weekly seasonality
, yearly seasonality
and temperature
.
Normal example:
sales = trend + weather + weekly + yearly
sales = 1518 + (1518 * 0.02) + (1518 * -0.624) + (1518 * 0.319)
sales = 1518 + 31 - 947 + 484
sales = 1086
I want to identify the effects on the sales prediction. Here I can easily see that the weekly seasonality (eg. a Monday) has a negative effect of 62% on the sales, resulting in a £947 reduction.
My problem: Sometimes the model calculates the trend as far higher than the median sales value, and therefore the weekly seasonality ranges between -50% and -80%, instead of being standardised with a mean of zero. This prevents understanding the output for a single prediction, and requires you to compare the component modifier with the other days of the week to see the relative change.
Example:
The model output shows the base trend
is unusually high compared to actual sales (y
).
Consequently, this means the weekly seasonality weekly_pct
is very low and isn't intuitive when looking at a single prediction. The other components look fine in this case.
Solution idea:
One naïve solution is to:
- Adjust the trend to be the median actual sales (
y
).
diff = old_trend - y_median
diff = 3800 - 1200 = 2600
- Add this difference to the weekly seasonality coefficient for this day (eg. Monday was -82% (-£3116) and Saturday was -47% (-£1786) in this case)
monday = old_monday + diff
monday = -3116 + 2600 = -£516
saturday = old_saturday + diff
saturday = -1786 + 2600 = £814
- Re-calculate the percentage modifiers using the new value of trend (
y_median
).
All we've done here is reduced one component (the trend), and added it to a different component (weekly seasonality), and kept the absolute values of the other components.
The problem with this solution is that we're only standardising the weekly seasonality. This wouldn't work if two or more of the components needed standardising. Am I missing a clever statistics trick here?