Assignment: Build Two Dashboards
Across this week's Metabase and Streamlit chapters, you built two dashboards. Before you present them, you need to document what the numbers mean. This chapter covers metric definitions, common presentation mistakes, and the five-minute format that works for a class (and for stakeholder meetings).
This is not a side skill: it is graded work. The assignment's Required tier includes metric_definitions.md for every panel and the 5-minute recorded presentation this chapter's format is built for. Everything below uses your own Metabase Questions and Streamlit panels as the worked example.
By the end of this chapter, you should be able to:
Look at your own Headline KPIs panel from Building a Metrics Dashboard: "Total revenue". Two data engineers building the same panel could compute it two different ways. One writes SUM(fare_amount) over every row. The other adds WHERE fare_amount > 0 first, because fct_trips has zero-fare trips sitting in it. Both numbers are "technically correct" SQL, but they disagree, and neither engineer would know it without comparing notes. The dashboard is not wrong because the SQL is wrong. It is wrong because the metric was never defined.
Metric definitions make dashboards reproducible:
<aside> 💡 Key insight: A metric without a definition is an opinion. Two people should be able to compute the same metric independently and get the same number. The definition is what makes that possible.
</aside>
Documenting metrics also builds trust. Stakeholders who know exactly how a number is calculated trust it more than a number that appears from nowhere.
Every metric on every panel should have five fields documented:
| Field | Question it answers | Example |
|---|---|---|
| Name | What do we call it? | avg_fare_per_trip |
| Description | What does it measure, in plain English? | Average fare charged per completed taxi trip, excluding zero-fare trips |
| Calculation | What SQL or formula produces it? | AVG(fare_amount) where fare_amount > 0 on fct_trips |
| Data source | Which table? | dev_yourname.fct_trips: built by your Week 10 dbt project |
| Refresh frequency | When is the number current as of? | Once per day, by 07:00 CET |
Fill these in for every panel before you present. A partial definition is better than none, but a complete one is the goal.
<aside>
⌨️ Hands on: Open the metric_definitions.md file from your assignment scaffold. Fill in all five fields for at least three panels from your Metabase dashboard and at least two panels from your Streamlit app. You will submit this file with the assignment.
</aside>
Five minutes is shorter than it feels. A common mistake is trying to explain every panel. Instead, pick three things and explain them clearly.
Use this structure. Here is what it sounds like for your own dashboards:
<aside> 💡 Every panel needs context. "Manhattan: 32,768 trips" is a fact. "Manhattan dominates with 32,768 trips, more than double Queens' 14,846" is a finding. Stakeholders remember findings, not facts.
</aside>
| Mistake | Fix |
|---|---|
| Too many panels at once | Walk through 2-3 panels, not all of them. Others can explore the dashboard themselves. |
| No time range stated | Always say what time period the numbers cover: "last 7 days", "January 2024". |
| Undefined axes | Label every axis. "Count" is not a label: "Trip count per day" is. |
| Reading numbers without interpretation | Don't say "the bar chart shows 32,768 trips for Manhattan." Say "Manhattan dominates with 32,768 trips, more than double Queens' 14,846." |
| Undefined metric | If a panel title says "quality score", explain what the score means before showing the number. |
| Presenting stale data | Always state when the data was last refreshed; the freshness panel exists for exactly this. |
<aside> 🤓 Curious Geek: The "three numbers" rule
Research on data presentations suggests that audiences retain at most three numbers from a 5-minute presentation. Every number you add beyond three competes with the first three. Professional data analysts often strip dashboards down before stakeholder meetings, hiding panels that are not relevant to the current discussion. The full dashboard exists for exploration; the presentation surfaces the three numbers that matter today.
</aside>
Metric definitions decay if they are not stored somewhere findable. Three common options:
| Option | Pros | Cons |
|---|---|---|
dbt docs (description: in schema.yml) |
Lives with the data model, auto-published | Requires dbt project access |
| README in the dashboard repo | Easy to edit, versioned in git | Decoupled from the dashboard itself, can drift |
| Notion or Confluence page | Stakeholders can find it, easy to link | Decoupled from both code and dashboard |
For this week: store your definitions in metric_definitions.md in your Streamlit repo. For a real project, the best home is dbt's schema.yml description field, as it is the closest to the source.
<aside> ⚠️ The drift problem: metric definitions stored separately from the query that produces them will drift. The SQL changes; the documentation does not. The only solution is a code review habit: if you change a metric's calculation, update its definition in the same PR.
</aside>
Each student presents for 5 minutes. Use this checklist before you go:
Practice is where you apply all six chapters to the exercises and the assignment. No new state to build here: confirm you can articulate the ideas:
<aside> 💡 Using AI to help: Paste one of your five-field metric definitions into an LLM and ask whether the Calculation field is unambiguous, or ask it to rewrite a panel finding into a one-sentence what/why/action statement. ⚠️ Never include real database passwords or personal data.
</aside>
avg_fare_per_trip changes (you now exclude zero-fare trips). List the two places you need to update.<aside> 🚀 Try it in the widget: Interactive Quiz: Presenting Metrics
</aside>
https://lasse.be/simple-hyf-teach-widget/mcq.html?bank=week_11_ch6_presenting_metrics_quiz&embed=1
Next up: Practice, where you apply Metabase and Streamlit through five structured solo exercises using the NYC taxi data.