Skip to main content
Aamina Mughal

Blog8 min read

Turning my own dataset into a dashboard

I froze a dataset I built myself and started moving it into Power BI. This is written from the middle of that, while the awkward parts are still fresh.

I am writing this from the middle of the job rather than the end, because the awkward parts are still fresh and I suspect I will forget them once it works.

The short version: I built a dataset myself about how much online attention different high-profile cases attract, froze it at version 1.0, and started moving it into Power BI. The dashboard is not finished. What follows is what the move has taught me so far.

Freezing it first

Before touching Power BI I stopped changing the data and gave that state a version number. This felt fussy at the time and has turned out to be the single most useful thing I did.

The reason is that platform numbers move. A view count I wrote down in March is not the number you would see today. If I had kept topping the dataset up while building charts, I would never have known whether a change on screen came from my work or from the internet carrying on without me. So every figure traces back to a source workbook that records where it came from and the date I collected it.

The path from source workbook to an unfinished dashboardFour completed stages — source workbook, standardised case IDs and dates, per-platform sheets, and normalised metrics — followed by two stages that are not done: building the Power BI model and building the dashboard.DONENOT DONESource workbookURLs, collection dates, rulesCase IDs & datesone format everywherePlatform sheetsone per sourceNormalised metricsput on a common scalePower BI modeltables joined properlyThe dashboardnot built yetEvery number traces back to the first box.The workbook holds the URL and the date each figure was collected, because platform counts move.
Where the data has come from, and the two stages that are still ahead of me.

Three platforms that refuse to be compared

Here is the problem that took me longest to understand. The platforms do not measure the same kind of thing. One counts views, which run into millions. One counts comments, which run into tens of thousands. One reports a search interest index that never goes above a hundred.

Put them on one chart and the two smaller ones flatten into the axis. It is not that they are unimportant — it is that the chart is answering the wrong question. So each platform gets put on a common scale first, and only then do the shapes become comparable.

The same three shapes, before and after putting them on a common scaleIn the top row each platform is drawn on its own axis, running to millions, tens of thousands, and one hundred respectively, so the three cannot be compared. In the bottom row all three run from zero to one and the differences in shape become visible.RAW — THREE DIFFERENT SCALESPlatform A0–1.9M viewsPlatform B0–61k commentsPlatform C0–100 search indexNORMALISED — ALL 0 TO 1Platform A0–1Platform B0–1Platform C0–1
Top row: each platform on its own axis, which tells you nothing about how they compare. Bottom row: the same six points rescaled to run from 0 to 1. Illustrative shapes standing in for the real ones.

The thing I had to sit with is that this rescaling is a decision, not a neutral tidy-up. Whichever method you pick changes which cases look prominent. It is a judgement I made, so it belongs in the write-up rather than buried in a formula.

Spreadsheet habits do not survive the move

In a spreadsheet I had one sheet per platform, which felt organised. Power BI wants something else: one long table of measurements, with small lookup tables beside it describing the things being measured.

It took me a while to see why. When every sheet is separate, “show me all platforms for one case” means stitching things together by hand every time. When the measurements live in one table and the case names live in another, that question is just a filter.

The table shape the model is moving towardA central metrics table holds one row per case, platform and date. Three lookup tables — cases, platforms and dates — connect to it. A separate media triggers table connects to cases and dates, so events can be lined up against the metrics without being mixed into them.Attention metricsone row per case × platform × dateCasesone row per casePlatformsone row per sourceDatesone row per dayMedia triggersdated events, kept separate
The shape I am moving toward: one measurements table in the middle, lookup tables around it, and dated events kept in their own table.

The dashed table on the right matters more than it looks. Documented events — a verdict, a documentary, a news cycle — live separately rather than being mixed into the measurements. If I merged them, I would quietly be treating “an event happened” and “attention rose” as the same kind of fact. They are not, and keeping the tables apart stops me pretending otherwise.

What I am sketching

I drew the layout on paper before building anything, which I would recommend to anyone, mostly because paper is much easier to throw away. The plan is four regions: filters across the top, a ranked list of cases on the left, a timeline on the right with marks where documented events sit, and a per-platform comparison underneath.

A layout sketch for the planned dashboardA sketch, not a built dashboard. A filter strip runs across the top. Below it, a ranked list of cases on the left and a timeline on the right with marks where documented events sit. A per-platform comparison runs across the bottom, and a note about limitations sits at the foot.filters — date range · platform · caseCases, rankedAttention over time, with event marksgreen marks = a documented event on that datePlatform comparisonone small panel per platform, each on its own scalefooter: what this dashboard cannot tell you
A sketch of the intended layout. A plan drawn for this post — not a screenshot of a built dashboard.

The footer is deliberate. I want the limitations on the dashboard itself, not in a document nobody opens. If someone screenshots one panel, the caveat should still be attached to it.

The line I keep repeating to myself

When you put a timeline next to a set of event markers, your brain does something unhelpful: it draws a causal arrow. A spike sits near an event, and the story assembles itself before you have checked anything.

What my data can support is that two things happened around the same time. It cannot support the claim that one caused the other. There are too many things I am not measuring, and attention is not a measure of how serious a case is, how much a victim matters, or whether anyone is guilty. It measures visibility on three platforms, and nothing else.

Building the dashboard has made this harder rather than easier, because a good chart is persuasive whether or not it is right. That is worth being nervous about.

What is left

Finish the model, build the four regions, and write a short methodology note that can sit alongside it. Then, when there is something real to show, put the actual visuals on the project page rather than the sketch above.

The current state of the work, including the parts I revised when the evidence went against what I expected, is on the project page.

All posts