What it is
The seasonal factor per month, and where it comes from. Measured from this tenant’s own sales unless a manual override is set. Profiles come from the products themselves — a profile nobody uses does not appear. One row per (profile, month).factor is what the demand engine actually applies; factor_source says whether it is the damped measured value or a manual override, and sample_size / confidence say how much history backs the measurement. This is the factor behind Sales/day (season removed) and the coverage-window season factor in Product Demand.
How the measured factor is computed
- Monthly unit sales are taken from the tenant’s own history. At least 6 observed months are needed, otherwise nothing is measured and the profile default applies.
- The long-term growth trend is removed first, so a company that is simply growing does not read every recent month as “high season”.
- For each calendar month, the detrended ratio is averaged across all years observed.
sample_sizeis that number of years — a month seen in two Novembers hassample_size2. - The twelve ratios are normalised so their average is exactly 1.0 (
measured_raw). 1.6 means the month sells 60 % above an average month; 0.7 means 30 % below. - The raw value is damped toward 1.0 when history is thin:
measured_applied = 1 + min(1, k × years) × (measured_raw − 1), withkfrom Procurement Config. One year of history therefore counts only partially; three or more years count fully. confidencefollows the years:high= 3 or more years,medium= 2,low= 1.- A manual override in Procurement Config wins over the measurement (
factor_source= override); a value of 1.0 in the config means “no override”.
How it gets data
Computed view — measured automatically from this tenant’s sales history per Products seasonality profile; manual overrides come from Procurement Config. Read-only; no ingest endpoint.Fields
All columns are read-only. The view also carries
tenant_id / workspace_id for tenant isolation — filtered automatically, never selected.
