Forecasting
Inventory forecasting, without the mystique
A forecast is an estimate of how fast you will sell something, nothing more. Most of the value comes from measuring that rate honestly, not from the model that dresses it up.
Marcus VolstedCo-founder, Restocio
Published 7 August 2026Updated 10 October 202615 min read
What a forecast actually is
A demand forecast for a store is an estimate of how many units a product sells per day, measured over the days it was actually available to buy. That is the whole object. A rate, with error bars. Everything else in forecasting, the trend lines, the seasonal factors, the confidence intervals, the machine learning, is refinement layered on that one number, and no refinement survives a dishonest rate underneath it.
Be clear about what a rate can do. It cannot tell you what happens next Tuesday. It can tell you what pace to plan around, and a purchasing decision needs nothing more, because every downstream number is this rate multiplied by something. Days of stock is inventory divided by it. The order deadline is days of stock minus lead time. The order quantity is the rate times the period the order should cover. Get the rate wrong by half and all three are wrong by half, regardless of how clever the model that produced it was.
The mystique around forecasting mostly serves the people selling forecasting. In a real store the value sits at the unglamorous end: measuring honestly, choosing the window on purpose, keeping non-demand events out of the history, and knowing when the number deserves no confidence at all. That work is this page.
Count only the days you could actually sell
The most expensive forecasting error has nothing to do with algorithms. It is dividing units sold by calendar days, including the days the product was out of stock.
Sell 30 units in 60 days, but the product was unavailable for 40 of them, and the honest rate is 30 ÷ 20 = 1.5 per day, not 0.5. Using the calendar figure teaches the system that a product which keeps selling out is a slow mover, so it orders less, so it sells out again. It is a loop that quietly buries good products.
An out-of-stock day is an absence of goods, not an absence of demand. The customers were there; the shelf was not. Fold those days into the divisor and you are averaging real demand together with your own failure to supply it.
Notice which products the error selects. It only bites products that run out, which means it lands precisely on your best sellers, while products that never sell out are measured correctly and look healthy by comparison. The error is not random noise spread across the catalog. It is a systematic tax on winners.
Shopify's own reports do not say they leave out days with no stock. Its daily sales report divides by every day in the period, and its days-remaining report by the days a variant was “active”, a word its Help Center does not define (read 2 October 2026). If a sales-per-day figure goes from a report straight into a reorder decision unchecked, this distortion may be in your numbers today, and the products it hides are the ones you can least afford to hide.
The opposite error lives in the numerator. In most calculations a unit that is refunded and restocked still counts as sold, so a product with many returns reads faster than it empties, and every quantity sized on it is too big by the restocked share. It usually runs the safe way, buying early and too much, and how far it pushes the rate is its own page.
Choose the measuring window on purpose
A rate over how long? The window is a real decision, and it trades reaction speed against stability.
| Window | Good at | Misleads when |
|---|---|---|
| 30 days | Catching a genuine shift in demand quickly | One strong or weak week moves the whole rate |
| 60 days | Enough sales to be stable, recent enough to be true. A sensible default | A shift in the last month is diluted by the month before it |
| 90 days | Smoothing slow sellers with sporadic sales | Demand that ended weeks ago keeps voting |
There is no correct answer, only a fitting one. Sixty days suits most stable products, and it is what Restocio measures over by default. Go shorter when something real has changed, a price move, a listing rework, a new competitor, a lost ad account, because then the older history describes a product that no longer exists. Go longer for slow movers, where a 30-day window contains so few sales that the rate is mostly luck.
Two boundaries are firmer than the rest. The window should never be longer than the product has existed, otherwise the empty days before launch dilute the rate: a product created two days ago that sold 30 units is selling around 15 a day, not the half a unit a day that a 60-day divisor would report, an understatement of thirtyfold. And the window should exclude the days the product could not sell, which is the previous section.
A discount week measures price sensitivity, not demand
A campaign spike looks like demand in the history, and it is not. Demand at 30 percent off is demand for a different offer at a different price. What that week measured is how price sensitive your customers are, which is worth knowing, and it says very little about how fast the product sells at full price on an ordinary Tuesday.
Left in the history, a discount week inflates every forecast computed after it, and quantities follow forecasts, so one strong campaign can push a quarter of over-ordering through your purchasing. The mirror image distorts too: the days just after a campaign often run below normal, because some of those campaign buyers were simply buying early. Probably not all of them, and the size of the dip varies by product, but it happens often enough to expect.
The practical handling is unglamorous. Know your campaign dates. Keep them out of the window you measure the base rate over, or measure around them, and plan campaign stock as its own explicit decision on top of the base forecast rather than letting the spike leak into the average.
New products have no rate
For the first weeks of a product's life there is no history worth modelling. Whatever number you compute is a guess with a decimal point on it.
Two honest things can still be done. Measure over the product's lifetime rather than a fixed window, so the arithmetic at least does not understate it, as in the two-day example above. And hold the result loosely: a fortnight of sales proves attention, not a stable pace, and the rate will swing as the launch buyers wash through. Order small, keep the cover period short, and revisit quickly rather than committing a full container to three weeks of enthusiasm.
When a new product replaces an old one, the old product's history is often the best forecast available, imperfect as it is. A successor usually inherits most of its predecessor's demand. That judgement lives with you, though. No system can know that two SKUs are the same product wearing different codes unless someone tells it.
Trend, and how many months it takes
A flat average has a structural blind spot: growth. Average the past year of a growing store and the result sits below where the store is now, because every older, smaller month drags it down. The forecast then under-predicts, month after month, in exactly the direction that causes stockouts. A shrinking store gets the mirror error, over-prediction, in the direction that strands cash in stock.
A trend line fixes the direction problem by fitting the slope of your history and extending it. It needs raw material, though. A slope fitted to six weeks of data mostly fits noise, and a series with a partial month at either end inherits a distortion, because a month holding four days of sales looks like a collapse. Drop incomplete months at both ends, fit on full ones, and stay suspicious of any slope until several full months support it.
How do you choose between the average and the trend? Not by argument. By replay: train on the first part of your own history, predict the next month, compare against what really sold, step forward, repeat. Whichever method was less wrong on your past earns the job on your future. Restocio runs exactly this comparison on its Demand page and shows each method's measured error, rather than asking you to believe a slope on style points.
Seasonality, and why one year is not enough
Seasonality is the pattern that repeats: toys in December, sandals in June. Using it in a forecast is simple arithmetic, the base rate times a factor for the time of year. Knowing the factor is the hard part, and that is purely a question of how much history you own.
With less than a year you have never observed a full cycle, so any seasonal claim is extrapolation from a season you have not seen. With exactly one year you have seen each season once, and a single observation cannot be separated from everything else that happened that year. Was the November spike seasonality, or the ad account that launched in October? One pass through the calendar cannot say. It takes a second year to tell a repeating pattern from a one-off, which is why the honest schedule is a year to see seasonality and two years to trust it. Restocio applies that rule to itself: seasonal factors stay switched off until two full cycles of history exist, because a guessed factor is worse than none.
Seasonality also belongs to the product, not the store. One supplier sells winter jackets and shorts, and averaging their patterns cancels both. The awkward case is the strongly seasonal product before its season starts: its trailing window is the off-season, so the measured rate is near zero at exactly the moment the pre-season order must be placed. A winter jacket in August has no summer sales to compute from. For products marked seasonal, Restocio sizes that pre-season window on what the product sold in the same season last year instead of the trailing rate, because that is the only history that means anything at that moment. The other end of the season is a different sum, because the last order before a known end date is a subtraction rather than a forecast.
How much history each estimate needs
| What you want to estimate | History it takes |
|---|---|
| A sales rate | About 60 in-stock days for a stable product |
| A trend | Several full months, with part-months dropped |
| Seasonality | A year to see it, two years to trust it |
| A first-time event | No amount of history contains it |
Below the threshold on any row, the honest move is to say so and fall back a row, not to squint harder at the data.
What Shopify gives you, and where it stops
Shopify answers the historical half of the question well and does not attempt the forward half.
| What the decision needs | In the Shopify admin |
|---|---|
| What sold, per variant, per period | Yes. The reports are good history. |
| A rate over in-stock days | Not described. One report divides by every day in the period, another by the days a variant was active, which is not defined. |
| A projection of future demand | No. There is no forecast. |
| Supplier lead times | No. And without lead time there is no order deadline, only a stock level. |
| A trigger that moves with demand | Partly. Shopify Flow can alert when stock crosses a number you typed, but the threshold is static: it does not move when your sales rate does, and it fires on low stock rather than on the ordering deadline, which for an importer is months apart. |
Sidekick, Shopify's AI assistant, will answer questions like what should I reorder, and is genuinely useful for a quick look. It is not a demand-forecasting engine, and Shopify does not claim it is. None of this is a criticism. Shopify is a commerce platform, and forecasting is a planning job. It does mean that for any store with a real lead time, the forward-looking half of purchasing happens outside Shopify, or it happens nowhere.
A forecast only earns money as a date and a quantity
A rate sitting on a dashboard changes nothing. It pays for itself through three multiplications, each one line long.
- Days of stock. Units on hand divided by the rate. This converts every product, fast or slow, into the same currency: time.
- The order deadline. Days of stock minus lead time minus a safety margin. This converts time into a date, the last day you can order at the cheap freight price. The full arithmetic, safety stock included, with a worked example, is on the reorder point page.
- The quantity. The rate times the period the order must cover, minus what you hold and what is already on the way. How that plays out on Shopify specifically, including the fast bridge order when the boat would land too late, is the replenishment guide.
Notice that the forecast is the smallest link in that chain. Two stores with identical forecasts get completely different outcomes depending on whether the deadline is visible and acted on. That is the quiet truth of this subject: most of what looks like a forecasting problem in a store is a timing problem wearing forecasting's clothes.
What no forecast can tell you
A forecast is computed from history, so it contains exactly what history contains and nothing else. Four things sit permanently outside it.
- Campaigns you have booked. The history cannot see your marketing calendar. A launch planned for next month is invisible until it happens.
- First-time events. A first Black Friday, a first wholesale account. There is no history to compute from, and no honest method can conjure one. Planning stock for Black Friday is its own decision, made with judgement rather than extrapolation.
- Viral spikes. The defining property of a product going viral is that nothing in its past predicted it.
- Supplier closures. A factory shutting for Chinese New Year does not change demand at all, and it moves the right order date by weeks. No demand model can see it, because it is not a demand fact.
This is why a forecast should never be the final word. The person doing the buying knows things the data does not, and the system's job is to surface the deadline and accept the override, not to order on your behalf. The calm-looking numbers just before a first Black Friday are the canonical case: everything in the history says normal, and everything the human knows says otherwise.
Timing beats accuracy for importers
Here is the asymmetry that decides where the effort should go. Suppose your forecast runs 10 percent high. You order 10 percent more than needed, and the cost is some extra weeks of cover on the shelf: real, but modest, and it corrects itself as the units sell. Now suppose your forecast is perfect and you act on it a week after the sea-freight deadline. The boat lands a week after your stock runs out, and the fix is flying units in at several times the sea price per kilo, or a week of empty shelves on a proven seller. The forecast error costs percentage points. The timing error costs multiples.
Pushing a forecast from decent to excellent is slow work with a small payoff. Watching the order deadline instead of the stock level is neither slow nor hard, and it prevents the expensive failure. If you fix one thing after reading this page, make it the in-stock rate. If you fix two, make the second the deadline.
Where Restocio stands, honestly
Since this page sits on a vendor's site, here is exactly what our forecasting is and is not.
The number that sizes orders is a trailing sales rate computed over in-stock days, with seasonal handling for products marked seasonal and a shorter window for young products. It is not machine learning, and we do not call it that. On the Demand page, a flat average, a trend and a seasonal method are compared by replaying your own history, and each is shown with its measured error. A method does not get believed because it has a nicer name, and the seasonal one is withheld entirely until two full years of history exist.
The limitation follows directly. If demand modelling is genuinely the core of your problem, if you operate at a scale where shaving a few points off forecast error is worth real money, you want a specialist demand-planning tool and probably a person to run it, and Restocio is not that. We built for the importer whose losses come from timing, where the win is the deadline being visible on the day it matters. In our experience that is most importers, but it is a judgement you should make about your own store, not one we can make for you.
Common questions
How much sales history do I need for a useful forecast?
About 60 in-stock days to estimate a sales rate, several full months before a trend line means much, a full year before seasonality is visible and two years before it is trustworthy. With less than that, treat the forecast as a rough average rather than a prediction.
Should discount periods be included in a forecast?
Not as normal demand. A campaign spike reflects price, not underlying demand, and including it inflates every forecast that follows. Keep campaign dates out of the window you measure the base rate over, and plan campaign stock as a separate decision on top.
Does Shopify have built-in demand forecasting?
No. Shopify's reports describe what already sold, without saying they leave out days with no stock, and the admin has no forecast, no suggested reorder quantity and no concept of supplier lead time. Shopify Flow can alert on a fixed stock threshold you set, and Sidekick can answer questions, but neither is a forecasting engine.
How do I forecast demand for a new product?
Mostly, you cannot. Measure the rate over the product's lifetime rather than a fixed window so the early days are not understated, treat the number as provisional for the first few weeks, and order small with short cover until a real pattern exists. If the product replaces an older one, the predecessor's history is often the best estimate available.
Do I need machine learning to forecast inventory?
For most stores, no. The expensive failures in importing are timing failures, ordering after the cheap freight deadline has passed, and those are prevented by an honest sales rate and a visible deadline rather than by a better model. If demand modelling genuinely is your core need, use a specialist tool. Restocio's forecasting is a trailing rate with seasonal handling and does not pretend otherwise.
What is the best window for a sales rate, 30, 60 or 90 days?
Sixty days counted over in-stock days is a sensible default for a stable product. Use a shorter window when demand has genuinely shifted, a longer one for slow sellers where 30 days holds too few sales to mean anything, and never a window longer than the product has existed.
Marcus co-founded Restocio and works on it daily with a Swedish importer who plans their purchasing in it every working day. Restocio is built in Sweden by two founders, one Swedish and one Danish, and Marcus is the Danish one. Why we are building it.
Related reading
- How to calculate your reorder point
- Shopify replenishment, end to end
- Stock replenishment, the complete guide
- Forecasting a product with only a few weeks of sales
- Sales are declining, and why the reorder math still says buy the same amount
- How to tell whether your forecast is any good
- Weeks of supply formula, and how to convert it from days of stock
Restocio plans purchasing for Shopify stores that import. It works out what to order, how much, and whether it should travel by sea, rail or air, so you pay air freight only for the units that genuinely cannot wait.