Building Your First Interactive Dashboard

A static report answers the questions its author thought of. An interactive dashboard lets the reader ask their own: only international customers, only the last quarter, only one product line. That power comes with a risk beginners rarely consider: every filter combination produces new numbers, and each of them has to be right. This guide builds a small interactive dashboard on real sales data and then does what most tutorials skip, testing that the interactions give correct results.

The example uses Streamlit, a Python library for data apps, because every step can be shown as code and checked. The same design works in Power BI, Tableau or Looker Studio, as noted along the way.

Step 1: One tidy table at the right grain

Dashboards are fastest and least error-prone when they read a prepared table rather than raw transactions. Here, a UK online gift retailer's 2011 transactions (UCI: Online Retail) are cleaned and summarised to one row per day and market:

import io
import urllib.request
import zipfile
import pandas as pd

url = "https://archive.ics.uci.edu/static/public/352/online+retail.zip"
with zipfile.ZipFile(io.BytesIO(urllib.request.urlopen(url).read())) as archive:
    raw = pd.read_excel(archive.open("Online Retail.xlsx"), dtype={"InvoiceNo": str, "StockCode": str})
services = {"POST", "DOT", "M", "m", "C2", "D", "S", "B", "BANK CHARGES", "AMAZONFEE", "CRUK"}
sales = raw[~raw["InvoiceNo"].str.startswith("C") & ~raw["StockCode"].isin(services)
            & ~raw["StockCode"].str.startswith("gift_") & (raw["Quantity"] > 0) & (raw["UnitPrice"] > 0)]
sales = sales[(sales["InvoiceDate"] >= "2011-01-01") & (sales["InvoiceDate"] < "2011-12-01")]
daily = (sales.assign(date=sales["InvoiceDate"].dt.date,
                      market=sales["Country"].where(sales["Country"] == "United Kingdom", "International"),
                      revenue=sales["Quantity"] * sales["UnitPrice"])
              .groupby(["date", "market"])
              .agg(revenue=("revenue", "sum"), orders=("InvoiceNo", "nunique"))
              .reset_index())
daily.to_csv("daily_sales.csv", index=False)
print(daily.shape, "| markets:", daily["market"].unique().tolist())
print(daily.head(3).round(2).to_string(index=False))

(538, 4) | markets: ['International', 'United Kingdom']
      date         market  revenue  orders
2011-01-04  International   347.56       1
2011-01-04 United Kingdom 14997.67      35
2011-01-05  International  1265.18       2

Cancellations, postage and fees are removed before summarising, so every number downstream inherits the same definitions. The grain, one row per day and market, is chosen so that every filter the dashboard offers can be answered by summing rows. Orders can be summed safely because each invoice belongs to a single country and day.

Step 2: Filters, KPIs and a trend

The dashboard has two filters, market and a range of months, and everything else recalculates from the filtered rows. Save this as dashboard.py:

import pandas as pd
import streamlit as st

data = pd.read_csv("daily_sales.csv", parse_dates=["date"])
st.title("Online shop sales, 2011")
market = st.selectbox("Market", ["All", "United Kingdom", "International"])
months = st.slider("Months", 1, 11, (1, 11))
view = data if market == "All" else data[data["market"] == market]
view = view[view["date"].dt.month.between(*months)]
revenue, orders = view["revenue"].sum(), view["orders"].sum()
left, middle, right = st.columns(3)
left.metric("Revenue", f"{revenue:,.0f}")
middle.metric("Orders", f"{orders:,}")
right.metric("Average order value", f"{revenue / orders:,.0f}")
st.line_chart(view.groupby(view["date"].dt.to_period("M").astype(str))["revenue"].sum())

Three design choices matter more than the tool:

• Filters at the top, where readers look first, and only two of them. Every extra filter multiplies the combinations to understand and test.
• KPIs as big numbers (Streamlit: st.metric), computed from the filtered data.
• Averages recomputed, not averaged. Average order value is total revenue divided by total orders for the selection. Averaging daily averages would give a different, wrong number.

Run it with streamlit run dashboard.py and it opens in a browser. In Power BI, the same design uses slicers for the filters, which narrow the data shown in the other visuals (Microsoft Learn: slicers), card visuals for the KPIs, and measures defined once so every visual uses the same calculation.

Step 3: Test the interactions

Clicking through a dashboard by hand checks a few combinations at best. Streamlit's AppTest runs the app without a browser, simulates a user's choices and exposes the rendered values (Streamlit: app testing):

from streamlit.testing.v1 import AppTest

dashboard = AppTest.from_file("dashboard.py").run()
print("all markets:        ", [m.value for m in dashboard.metric])
dashboard.selectbox[0].select("International").run()
print("international only: ", [m.value for m in dashboard.metric])
dashboard.slider[0].set_value((9, 11)).run()
print("international, Sep-Nov:", [m.value for m in dashboard.metric])

all markets:         ['8,878,008', '17,407', '510']
international only:  ['1,410,149', '1,690', '834']
international, Sep-Nov: ['515,909', '673', '767']

The first line can be reconciled with an independent calculation: January to November revenue of 8,878,008 and 17,407 orders match the monthly totals of the same cleaned data computed separately. Reconciling the unfiltered view against a trusted source, then checking that filtered views move in the expected direction, catches most dashboard bugs.

The test also surfaces an insight worth putting on the dashboard: international orders average 834, against 510 overall, so overseas customers place far bigger orders. A reader who only saw the "All" view would never notice.

What to check before sharing any dashboard

The empty-selection check points at a real weakness of this example: if a filter ever removed every order, the average order value would divide by zero. Production dashboards need a guard for that case.

Beginner mistakes to avoid

• Building on raw transactions so every interaction recalculates millions of rows and slows the page.
• Adding a filter for every column because the tool allows it, leaving readers unsure where to start.
• Mixing definitions between visuals, such as one chart including returns and another excluding them.
• Decorating instead of informing: 3D charts, gauges and heavy colour that make numbers harder to read.
• Never looking at the dashboard as a newcomer would. Ask someone unfamiliar to answer three questions with it and watch where they hesitate.

From first build to a useful tool

• Start from the reader's questions. The two filters here exist because a sales manager would ask about markets and periods.
• Keep the page to one screen. Dashboard design principles covers layout and chart choice.
• Choose the tool your organisation uses. Power BI, Tableau and Looker Studio all support the same pattern of filters, KPIs and trends; the Looker Studio tutorial walks through a free option.
• Gather feedback from the people who will use it, and watch which filters they actually touch.

For a complete worked example of defining sales KPIs from raw data, see the sales dashboard project. Interactive dashboards and report publishing in Power BI are part of the Data Analytics course.

Sources

• Online Retail (UCI Machine Learning Repository) — UCI Machine Learning Repository
• Slicers in Power BI (Microsoft Learn) — Microsoft Learn
• st.metric (Streamlit documentation) — Streamlit documentation
• App testing (Streamlit documentation) — Streamlit documentation