Product Demand

What it is

How fast each variant sells, and how long the stock lasts. Sold 30/90/180d are raw units. Sales/day (weighted) blends those windows — recent weeks count more. Sales/day (season removed) is the same rate with the seasonal swing taken out, so periods are comparable. Planned demand/day is what procurement actually plans with: the weighted rate times the season factor of the period a purchase placed today would cover, times lifecycle and any manual factor. Days of Stock is stock divided by planned demand. Every factor is exposed as its own column, so an agent can cite the exact calculation path for any number it reports. demand_status (READY / LOW_HISTORY / NO_SALES_HISTORY / MANUAL_FORECAST / INSUFFICIENT_DATA) and demand_confidence (high / medium / low) say how much history backs the rate: under 180 days of history the windows shrink and the weights renormalize (READY); under 30 days the rate is measured since launch (LOW_HISTORY); no sales plus a manual target becomes MANUAL_FORECAST.

How it gets data

Computed view — derived automatically from Orders / Order Line Items, Products, and Procurement Config. Read-only; no ingest endpoint. To change the numbers, change the inputs (sales data, product master data, config). Sales are counted per variant on orders.placed_at, with refunded/expired/voided orders excluded via financial_status. Both shops are summed when several feed one workspace. The view lists every active product, including products that procurement does not track (procurement_trackable = false, e.g. families bought manually). It is a sales statistic, not an order list — the tracking filter lives only in the Procurement Queue.

Fields

Identity & stock

Field	Label	Type	Description
`sku`	SKU	text	Variant SKU
`product_name`	Product	text	Variant title
`product_family_label`	Family	text	Human-readable model family
`product_family`	—	text	Source product-group id (API only — not a registered app column)
`product_id`	Product (internal)	text	Joins to `products.id`
`stock_on_hand`	Stock	number	Current stock from the shop sync
`inventory_synced_at`	Inventory synced	datetime	When stock was last synced
`days_of_stock`	Days of Stock	number	Stock ÷ planned demand/day — how long the shelf lasts at the planned rate
`lifecycle_status`	Lifecycle	text	Lifecycle stage from the product master
`seasonality_profile`	Season Profile	text	Seasonality profile assigned to the variant
`calculated_at`	Calculated	datetime	When the view was computed

Raw sales windows

Field	Label	Type	Description
`units_sold_14d`	Units 14d	number	Raw units sold, last 14 days
`units_sold_28d`	Sold 28d	number	Raw units sold, last 28 days (trend window)
`units_sold_30d`	Sold 30d	number	Raw units sold, last 30 days
`units_sold_90d`	Sold 90d	number	Raw units sold, last 90 days
`units_sold_180d`	Sold 180d	number	Raw units sold, last 180 days
`units_sold_365d`	Units 365d	number	Raw units sold, last 365 days
`sales_history_days`	History (days)	number	Days of sales history backing the rates — windows shrink and weights renormalize when shorter than 180

Demand rates & blend weights

Field	Label	Type	Description
`daily_sales_28d`	Rate 28d	number	Units/day over the last 28 days
`daily_sales_30d`	Rate 30d	number	Units/day over the last 30 days
`daily_sales_90d`	Rate 90d	number	Units/day over the last 90 days
`daily_sales_180d`	Rate 180d	number	Units/day over the last 180 days
`w30` / `w90` / `w180`	—	number	The actual blend weights applied to the 30/90/180-day rates (API only). Renormalized when history is shorter — the visible proof of how the weighted rate was mixed
`weighted_daily_demand`	Sales/day (weighted)	number	Blend of the window rates; recent windows weighted higher
`deseasonalized_daily_demand`	Sales/day (season removed)	number	Weighted rate with the seasonal swing taken out — comparable across months

Seasonality & coverage window

Field	Label	Type	Description
`seasonal_multiplier`	Season factor (order window)	number	Season factor of the period a purchase placed today would cover
`seasonal_source`	Seasonal basis	text	Where the factor comes from: measured from own sales, manual override, or profile
`coverage_window_start`	Window from	date	Start of the coverage window: today + lead time (an order placed now arrives here)
`coverage_window_end`	Window to	date	End of that window: arrival + target stock days
`coverage_window_factor`	Season factor (order window)	number	Season factor averaged over the coverage window — the factor that actually multiplies into planned demand

Planned demand & its factors

Field	Label	Type	Description
`forecast_daily_demand`	Planned demand/day	number	The rate procurement plans with: weighted rate × season factor of the coverage window × lifecycle × manual factor
`lifecycle_multiplier`	Lifecycle factor	number	Demand factor from the lifecycle stage (launch boosts, declining damps)
`manual_demand_multiplier`	Manual factor	number	Manual factor from the product master
`manual_target_quantity`	Manual target	number	Manual forecast from the product master — used when there is no sales history
`demand_status`	Demand status	text	`READY` / `LOW_HISTORY` / `NO_SALES_HISTORY` / `MANUAL_FORECAST` / `INSUFFICIENT_DATA` — how the rate was derived. Zero sales during a stockout still reads as zero demand; the status makes that visible instead of hiding it
`demand_confidence`	Demand confidence	text	`high` / `medium` / `low` — how much history backs the rate

Trend & momentum (per SKU)

These three columns answer one question: is this SKU selling faster or slower than it was? They compare the last 28 days (four complete weeks) with the last 90 days, both with the seasonal swing removed, so a December spike does not read as a trend.

Field	Label	Type	Exact definition
`momentum_pct`	Momentum % (28d vs prior)	number	`100 × (season-removed rate over 28d) ÷ (season-removed rate over 90d)`. 100 = same pace as the 90-day average, 150 = 1.5× that pace (+50 %), 70 = 0.7× (−30 %). It is a ratio, not a growth delta. Empty when the SKU sold fewer than 8 units in 28 days or has no 90-day rate — a percentage from single-digit volumes is noise and is deliberately not shown
`trend_label`	Trend	status	`LOW_VOLUME` = under 8 units in 28 days (no verdict possible) · `RISING` = momentum ≥ 130 · `FALLING` = momentum ≤ 70 · `STABLE` = everything in between
`trend_confidence`	Trend confidence	text	How much current volume backs the verdict, from `units_sold_28d` alone: `high` = 30 units or more in 28 days · `medium` = 15 to 29 · `low` = under 15. A `RISING` with `low` confidence is a watch item, not a signal

Worked example: Marquis 3021 sold 21 units in 28 days (0.75/day) and 45 in 90 days (0.50/day). 0.75 ÷ 0.50 = 1.50; after removing the season, momentum reads 152, so RISING. With 21 units it is medium confidence. | momentum_delta_pct | Momentum Δ vs 90d % | number | The same momentum as a growth delta: momentum_pct − 100. +52 means 52 % above the 90-day pace, −30 means 30 % below. Read this one; keep momentum_pct for thresholds |

Prior year & 90-day outlook

The buyer’s second question: how does this SKU run against last year, and what did the coming quarter look like last time? Prior-year windows are the same calendar windows shifted back exactly 365 days.

Field	Label	Type	Exact definition
`units_28d_py`	Units 28d (prior year)	number	Units sold in the same 28-day window one year earlier
`units_90d_py`	Units 90d (prior year)	number	Units sold in the same 90-day window one year earlier
`yoy_pct`	YoY % (28d vs prior year)	number	`100 × (units_sold_28d − units_28d_py) ÷ units_28d_py`, a growth delta: +30 = 30 % more than last year, −20 = 20 % less. Empty when the prior-year window had fewer than 5 units
`yoy_90d_pct`	YoY % (90d vs prior year)	number	Same delta on the 90-day window; steadier, slower. Empty below 15 prior-year units. Use it to sanity-check a wild 28-day value
`units_next90d_py`	Units next 90d (prior year)	number	Units sold in the 90 days that followed today’s date last year — what the coming quarter did last time. Rolls forward every day; not a calendar quarter
`units_forecast_next90d`	Units next 90d (forecast)	number	`units_next90d_py × (100 + yoy_pct) ÷ 100` — last year’s coming quarter scaled by this year’s growth. An assumption that the growth rate holds, never a truth. Empty whenever `yoy_pct` is empty

Read them left to right: momentum (now) → YoY (against last year) → next 90d prior year (what came) → forecast (what to expect) → stock and days of stock (does it last). Backtest on company level: prior year alone missed actual orders by 27–43 %, prior year × momentum by 5–22 %. The trend never changes Planned demand/day. Trend is a signal; the order quantity comes from the weighted rate and the season factor, so a spike is not counted twice. Family-level versions of the same three columns live in Family Trend. All columns are read-only. The view also carries tenant_id / workspace_id for tenant isolation — filtered automatically, never selected.

How last year’s season enters the plan

There is no “last year” column on this view, yet last year’s Black Friday is in every planned number. It arrives through two pieces:

The seasonal factor per month. Seasonality measures, from this tenant’s own sales history, how much each calendar month sells relative to an average month — November at 1.6 means November sells 60 % above average. Every past year of history feeds that factor, and the factor is damped when only one or two years exist.
The coverage window. An order placed today does not sell today. It arrives after the lead time (coverage_window_start) and has to last until the target stock days run out (coverage_window_end). The season factors of the months inside that window are averaged into coverage_window_factor.

forecast_daily_demand = deseasonalized_daily_demand × coverage_window_factor × lifecycle_multiplier × manual_demand_multiplier. So when a purchase manager asks in September “what do I need for Black Friday?”, the engine already answers it: the window of an order placed now reaches into November, and November’s factor lifts the planned rate by exactly what November did in previous years. Reading 365-day columns is not needed for that; they exist for volume context (units_sold_365d), not for the plan.

Query it

{
  "method": "tools/call",
  "params": {
    "name": "data_query",
    "arguments": {
      "view_slug": "v_product_demand",
      "filters": { "demand_status": "READY" },
      "select_fields": ["sku", "product_name", "forecast_daily_demand", "days_of_stock", "stock_on_hand"],
      "sort_by": "days_of_stock",
      "sort_desc": false,
      "limit": 25
    }
  }
}

Getting Started

Vertical Intelligence

AI Operating Guide

Resources

Sales & Commerce

Procurement

Marketing & Outreach

Governance

What it is

How it gets data

Fields

Identity & stock

Raw sales windows

Demand rates & blend weights

Seasonality & coverage window

Planned demand & its factors

Trend & momentum (per SKU)

Prior year & 90-day outlook

How last year’s season enters the plan

Query it

​What it is

​How it gets data

​Fields

​Identity & stock

​Raw sales windows

​Demand rates & blend weights

​Seasonality & coverage window

​Planned demand & its factors

​Trend & momentum (per SKU)

​Prior year & 90-day outlook

​How last year’s season enters the plan

​Query it

What it is

How it gets data

Fields

Identity & stock

Raw sales windows

Demand rates & blend weights

Seasonality & coverage window

Planned demand & its factors

Trend & momentum (per SKU)

Prior year & 90-day outlook

How last year’s season enters the plan

Query it