Retail sales velocity formula: units per store per week

The retail sales velocity formula is units sold divided by selling store-weeks: how quickly a SKU moves at the locations selling it. A total sales increase can come from more distribution, faster movement, or both. Keeping those effects separate makes a retailer comparison useful.

Define the store and week base first

Retail unit velocity = Units sold / Selling store-weeks

Selling store-weeks = Sum of the weekly counts of stores selling the SKU

This article defines a selling store-week as a store reporting positive unit sales for that SKU during that week. The numerator contains those same store-week sales. If your retailer supplies an authorized-store or ranged-store measure instead, use it deliberately and name the result units per authorized or ranged store per week.

That distinction matters. A stocked location reporting no sales disappears from a positive-sales denominator. Its lack of movement remains visible in a ranged-store denominator. Neither definition should silently replace the other in a trend report.

This is a sell-through measure, based on sales to shoppers. Shipments into a retailer's distribution center answer a different question. It is also separate from the opportunity-based calculation in the four-factor CRM sales velocity formula.

The export rows you need

Start with a retailer sales export and a distribution export at the same weekly grain. Retain retailer, store identifier, SKU, week ending, units, the distribution flag and any reporting-completeness flag. Preserve the original unit definition: individual items, cases and multipacks are different quantities.

Join the records by retailer, store, SKU and week. A store count repeated on every transaction row must be counted once for that store-week. A missing report is unknown, while a complete report with no sales is an observed zero. Keep that difference visible before calculating anything.

Use a closed reporting window. Confirm that each retailer has delivered all included weeks and that returns follow the same policy. A retailer with an incomplete final week should remain outside the comparison until its file is complete, or appear with a clearly different end date.

The sales analytics KPI definitions provide a broader measurement reference; this calculation needs only matching unit sales and a clearly defined distribution exposure.

A worked comparison across SKUs and retailers

A US beverage brand reviews a completed four-week period. The table shows the grouped export inputs. Weekly store counts refer to positive-selling locations, and unit totals cover those same weeks. Rates are rounded to two decimal places; calculations retain unrounded values.

For Citrus at East, the calculation proceeds as follows:

For a sheet with units in C and the weekly store counts in D:G, store-weeks in H2 are =SUM(D2:G2). Velocity in I2 is =IF(H2=0,NA(),C2/H2). A zero denominator is undefined, so it should not become a reported zero velocity.

Do not divide the whole period's units by the final week's store count multiplied by the number of weeks. Stores joined during the window, so the ending count does not describe the exposure that produced all the sales.

Prove the aggregate before interpreting it

The total is 1,410 / 136 = 10.37 units per SKU-selling-store-week. Because the table combines products, a store selling both SKUs contributes exposure to both. This is an aggregate across SKU-store-weeks, not a measure per unique physical store.

The unrounded identity is:

Total units = Sum of each row's velocity × its store-weeks

Here, 12 × 50 + 10 × 36 + 9 × 30 + 9 × 20 = 1,410. Dividing that result by the 136 store-weeks returns the same total velocity. In Excel, =SUMPRODUCT(H2:H5,I2:I5) performs this reconstruction; Microsoft documents SUMPRODUCT as summing products of corresponding arrays.

Also reconcile the unit total to the retailer's period sales report. The arithmetic identity proves the calculation, but it cannot detect a missing retailer file or duplicated sales rows that were already in the inputs.

Separate distribution gains from faster movement

Compare Citrus at East with its previous completed period:

Units rose by 600 / 480 − 1 = 25%. Exposure rose by 50 / 40 − 1 = 25%. Velocity did not change. At the previous pace, the additional exposure explains 10 × 12 = 120 units, the entire sales increase.

This identifies where growth occurred; it does not prove why. Promotions, shelf placement, weather and store mix can change the result. Keep comparable stores as a second view when new distribution has a different customer base. NIQ's discussion of store-level assortment decisions also explains why velocity alone can miss whether an item expands the category or shifts demand between SKUs.

For marketplace units without a store base, use Amazon sales velocity. Property unit sales use another denominator, covered in sales velocity in real estate.

Where it goes wrong

• Ending stores used for the whole window. Sum weekly exposure when distribution changes.
• Zero-selling stores silently excluded. Report the chosen store population and inspect ranged locations with no movement separately.
• Different unit sizes combined. Convert cases and individual items to a consistent measure before comparing SKUs.
• Incomplete reports treated as zero. Missing retailer weeks should trigger a completeness check, not a lower velocity.
• Promotion and store mix mistaken for sustainable demand. Compare like periods and comparable locations before recommending a distribution expansion.

Covirage is not affiliated with Microsoft or NIQ.

Compare your own retail files in Covirage

Bring a sample of your own weekly sales and distribution exports to Covirage. Covirage maps the columns, and its tools compute unit velocity, compare distribution exposure and check the totals; the external AI model explains the result with every figure traced to its rows. Create a free Covirage account, then set up your business and bring your files.

See Covirage for CPG brands for the supporting industry context.