Skip to content

Deal seasonality and projections

Seasonality is a per-deal profile of twelve monthly factors describing how far each calendar month's turnover typically deviates from the deal's average month (e.g. "December runs 40% below average"). It exists so projections and rebate estimates don't assume spend arrives evenly across the year.

Seasonality is not user-editable. It is generated automatically, server-side, from historical turnover: the platform takes the deal's categories, averages the site's historical monthly turnover in those categories (adjusted for year-on-year growth), and stores each month's percentage deviation from the annual mean. Generation happens the first time a consumer asks for the profile with defaults enabled — typically the first rebate calculation. Cloning a deal copies its seasonality.

A vestigial "edit seasonality" launcher exists in the front-end code but is dead: nothing links to it, its controller is a stub, and no endpoint writes seasonality.

What consumes seasonality

  • Rebate calculation estimates — period estimates for partially elapsed periods are actuals plus the monthly average weighted by each remaining month's factor. Deals without seasonality fall back to a flat average with a 5% haircut.
  • Deal dashboard projection line — labeled Seasonal moving avg when seasonality exists, Linear otherwise (legacy fallback path; newer stored projections take precedence when present).
  • Rebate target insights — the next-three-months seasonality hint in the rebate target dialog.

Not consumed by the Projections toggle datasets on the spend and rebates views: those "advanced" projections are generated by a separate process that computes its own seasonal factors from turnover history (category-based, with supplier-level fallback), independently of the deal's seasonality profile. The two mechanisms can therefore disagree.

Why do projections change unexpectedly

  • A deal's estimates switched from linear to seasonal (or numbers jumped) — the deal's seasonality was generated for the first time by a rebate calculation.
  • A deal never gets seasonal estimates — deals with no categories never get a seasonality profile and permanently use the linear/95% fallback. Assigning categories fixes this for future generations.
  • Dashboard projection disagrees with the Projections toggle — they are different mechanisms (see above).
  • Estimates moved without new figures — projections are recomputed from turnover history by background processes; they are derived data.

What seasonality is not

  • Not a user setting — there is no working edit screen.
  • Not the advanced projections datasets behind the Projections toggles — those are computed independently.
  • Not participation or weighting of rebates — it only shapes estimates and projections, never actual calculated rebate amounts for completed periods.