Forecast vs actuals
shipped, per ASIN per forecast window.
- Grain
- forecast window x vendor x marketplace x ASIN
- Built from
- 2Raw tables
- 2Staging
- 1Core
- 1Analytics
- Reads from Amazon Vendor Central API
- vendor_forecasting_reportvendor_sales_report
- Ships as
- Weld and dbt SQL, open source on GitHub
1-- amazon_vendor_forecast_vs_actuals - Amazon's demand forecast against what actually
2-- shipped, per ASIN per forecast window.
3--
4-- Grain: forecast window x vendor x marketplace x ASIN.
5-- Depends on: staging.amazon_vendor.forecast, .sales
6--
7-- WHY BUILD THIS AT ALL. Amazon's forecast drives Amazon's purchase orders. If the
8-- forecast for an ASIN is 40% above what has ever shipped, POs are coming that will
9-- leave Amazon overstocked - and overstock becomes your markdown request. If it is
10-- well below, Amazon will under-order and you will lose sales you could have made.
11-- Either way you find out months later, from the consequence rather than the cause.
12--
13-- This model puts the forecast next to the outcome so you can see the error while it
14-- still matters, and take a specific number into a Vendor Manager conversation.
15--
16-- FORWARD-LOOKING WINDOWS HAVE NO ACTUALS YET, and that is the useful half. Rows
17-- where forecast_status = 'FORECAST' are what Amazon expects next; 'REALISED' rows
18-- are windows that have fully elapsed and can be scored. 'IN_PROGRESS' is partially
19-- elapsed - the actuals are real but incomplete, so do NOT read the error columns on
20-- those rows. They are NULL for exactly that reason.
21--
22-- ONE LIMITATION, AND IT IS STRUCTURAL. Amazon retains only the current forecast, so
23-- a realised window is scored against whatever forecast was live when you last
24-- synced - which, for a window already in the past, may have been revised toward the
25-- outcome. Measuring true forecast accuracy needs the forecast AS IT STOOD before the
26-- window opened, which means retaining generations: enable Weld history tables on the
27-- vendor_forecasting_report stream and read the history table here instead. Until
28-- then, treat these errors as indicative, not as a forecast-accuracy KPI.
29
30WITH actuals AS (
31 SELECT
32 f.amazon_vendor,
33 f.marketplace,
34 f.asin,
35 f.forecast_start_date,
36 f.forecast_end_date,
37 SUM(s.shipped_units) AS actual_shipped_units,
38 SUM(s.ordered_units) AS actual_ordered_units,
39 COUNT(DISTINCT s.date) AS days_with_sales
40 FROM {{staging.amazon_vendor.forecast}} fThis model and the 3 it depends on. Deploy them together; refs like {{staging.…}} resolve to the matching folders in Weld, and the dbt view uses source() and ref().
How it counts. And where it stops.
WHY BUILD THIS AT ALL. Amazon's forecast drives Amazon's purchase orders. If the forecast for an ASIN is 40% above what has ever shipped, POs are coming that will leave Amazon overstocked - and overstock becomes your markdown request. If it is well below, Amazon will under-order and you will lose sales you could have made. Either way you find out months later, from the consequence rather than the cause. This model puts the forecast next to the outcome so you can see the error while it still matters, and take a specific number into a Vendor Manager conversation. FORWARD-LOOKING WINDOWS HAVE NO ACTUALS YET, and that is the useful half. Rows where forecast_status = 'FORECAST' are what Amazon expects next; 'REALISED' rows are windows that have fully elapsed and can be scored. 'IN_PROGRESS' is partially elapsed - the actuals are real but incomplete, so do NOT read the error columns on those rows. They are NULL for exactly that reason. ONE LIMITATION, AND IT IS STRUCTURAL. Amazon retains only the current forecast, so a realised window is scored against whatever forecast was live when you last synced - which, for a window already in the past, may have been revised toward the outcome.
Raw tables it reads
- raw.amazon_vendor_central.vendor_forecasting_report
- raw.amazon_vendor_central.vendor_sales_report
More Amazon Vendor Central API models
Put Amazon Vendor Central API in front
of your agents.
Connect Amazon Vendor Central API, deploy the models, and ask questions in Claude, Cursor or ChatGPT. Free for 14 days, no credit card.