What a Good Retail Dashboard in Power BI Shows
Most retail dashboards I am asked to fix have the same problem: they show everything the data model contains. Twenty visuals, five slicers, no obvious starting point. A commercial team opens such a report once, then goes back to its spreadsheet.
A useful dashboard starts from the meeting it serves. The weekly trading meeting, the monthly category review and the end-of-season review ask different questions, look at different time frames and have different audiences. Each deserves its own report, or at least its own set of pages, rather than one report that tries to serve them all.
- One question per page, written as the page title.
- Four to six headline KPIs at the top, always compared with plan or last year.
- One main visual that explains the headline, and a detail table for people who want to drill down.
- The same definitions everywhere: net sales after returns, sell-through on available stock, margin on net prices.
Power BI Sales Dashboard Example: Weekly Trading
The weekly trading dashboard is the Power BI sales dashboard most retail teams need first. It is opened on Monday morning, it covers the last completed week and season to date, and it must answer one question in under a minute: are we ahead of or behind plan, and where?
Page 1 is the summary. A row of KPI cards shows net sales, units, average selling price, full-price share and gross margin for the week, each against last year and plan. Below it, a bar chart splits the variance to plan by channel and market. Page 2 lists the best and worst sellers by style, with sell-through and weeks of cover next to sales, so the team can decide on reorders and transfers in the same meeting.
| KPI | Compared with | Question it answers |
|---|---|---|
| Net sales | Plan and last year | Are we on track this week? |
| Units sold | Last year | Is the change driven by volume or price? |
| Average selling price | Last year | Are we selling at lower prices than before? |
| Full-price sales share | Last year | How much of the week depended on discounts? |
| Gross margin % | Plan | Is the sales growth profitable? |
| Weeks of cover | Target range | Where will we run out or be overstocked? |
Two details make this page work in practice. The data must be refreshed before the meeting starts, with the refresh time shown on the page, so nobody asks whether Sunday is included. And the page should open on the level most people care about, usually the whole brand, with a drill-through to market and store for those who need it.
Power BI Retail Dashboard Example: Category Review
The category review dashboard serves buyers and merchandisers once a month. The time frame is season to date, and the question is different: which categories, price points and styles are working, and what should we change in the range?
Page 1 is a category matrix: one row per category with sales, sell-through, margin and stock, using conditional formatting so the weak rows stand out without reading every number. Page 2 shows the price architecture: units and sell-through by price band, which reveals gaps and overcrowded price points. Page 3 is the style list, filtered to one category at a time, with a slicer for colour and size so the team can see whether a problem sits in the design or in the size curve.
| KPI | Visual | Decision it supports |
|---|---|---|
| Sell-through season to date | Matrix with colour scale | Reorder, hold or mark down |
| Sales mix vs plan | Bar chart by category | Rebalance next season’s option count |
| Units by price band | Column chart | Fill or close price ladder gaps |
| Gross margin % | Matrix column | Review cost or price by category |
| Size sell-through | Heat map by size | Adjust the size curve for the next buy |
Power BI Dashboard Example: End-of-Season Review
The end-of-season review looks back at a closed season and feeds the next buy. The audience is wider: buying, planning, finance and often the management team. The question is: what did the season teach us, in numbers?
Page 1 compares the season with plan and with the same season last year: sales, achieved margin, markdown cost and closing stock. Page 2 shows the cumulative sell-through curve by category, this season against last, which makes a slow start or an early stock-out visible at a glance. Page 3 splits the margin gap between intake margin and achieved margin into markdowns, promotions and returns. Page 4 lists the leftover stock that will carry over, with its age and value.
| KPI | Page | What it tells the next buy |
|---|---|---|
| Final sell-through by category | Season curve | Where the buy was too deep or too shallow |
| Markdown cost | Margin bridge | How much intake margin to plan |
| Achieved margin vs intake margin | Margin bridge | Which categories lose most to discounts |
| Closing stock value and age | Carry-over list | How much stock enters next season |
| Stock-out weeks on best sellers | Style list | Which styles deserved a deeper buy |
The value of this dashboard comes from reusing it. When the same pages are built for every season, the team can open last year’s review during the next range planning session and check whether the same categories keep appearing on the problem list.
Every page that compares with last year needs the same time intelligence measure. For weekly retail reporting I compare with the same weekday last year, which is 364 days back, rather than the same calendar date:
Net Sales :=
SUM ( Sales[NetAmount] )
Net Sales LY :=
CALCULATE ( [Net Sales], DATEADD ( 'Date'[Date], -364, DAY ) )
Net Sales vs LY % :=
DIVIDE ( [Net Sales] - [Net Sales LY], [Net Sales LY] )Retail KPI Dashboard Design Rules
These rules come from watching how commercial teams actually use reports. None of them needs a special visual or a paid add-on.
- Write the page title as the question the page answers, not as “Overview” or “Sales”.
- Put comparisons next to every headline number: a KPI without plan or last year is just a number.
- Use colour only for meaning, such as red for behind plan, and keep everything else neutral.
- Keep slicers in the same place on every page and show clearly which filters are active.
- Show dates as the retail week and season the team uses, not as calendar months only.
- Add a definitions page that explains every KPI, its formula and its data source.
- Limit each page to what fits on one screen without scrolling.
- Test the dashboard in a real meeting before adding more pages.
If your team already has data in Power BI but still prepares the Monday numbers by hand, the gap is usually the page design and the definitions rather than the data. That is the part I focus on when I build Power BI dashboards for retail brands.