Een dashboard bouwen: databronnen, KPI’s, grafieken en toegang

Om een dashboard te bouwen begin je bij de vragen die het moet beantwoorden en de mensen die het gaan lezen, definieer je een kleine set meetwaarden nauwkeurig, koppel je de data waarop die meetwaarden zijn gebaseerd, en kies je per meetwaarde een eenvoudige grafiek. Bepaal daarna wie welke cijfers mag zien. Een AI-appbouwer kan in een paar minuten een strak dashboard maken; het moeilijke deel, en het deel dat bepaalt of iemand het vertrouwt, is het goed krijgen van de data en de definities.

Begin met vragen, niet met grafieken

Een dashboard dat alles probeert te tonen, wordt één keer geopend. Beantwoord voordat je aan grafieken denkt:

• Voor wie is het? De oprichter, een salesteam, operations, investeerders, je klanten?
• Welke beslissingen ondersteunt het? ‘Moeten we nog een supportmedewerker aannemen?’ is een vraag die een dashboard kan beantwoorden. ‘Laat me onze data zien’ niet.
• Hoe vaak wordt het bekeken? Dagelijkse operationele dashboards hebben verse data en waarschuwingen nodig; een maandelijks overzicht niet.

Schrijf drie tot vijf vragen op. Elke vraag wordt één of twee meetwaarden.

Definieer elke meetwaarde exact

De meeste discussies over dashboards gaan eigenlijk over definities. Schrijf per cijfer een korte definitie:

Zet deze definities in je prompt. Anders kiest een AI een redelijk klinkende berekening die misschien niet overeenkomt met hoe jouw bedrijf telt.

Waar de data vandaan komt

Twee principes gelden overal:

1. Houd sleutels op de server. API-sleutels en databasewachtwoorden horen in de omgevingsvariabelen van de app, nooit in browsercode.
2. Beslis over de versheid van de data. Bij elke paginalading data ophalen uit meerdere API’s is traag en loopt tegen rate limits aan. Voor de meeste zakelijke dashboards is een synchronisatie elk uur of ’s nachts naar je eigen database, met een ‘laatst bijgewerkt’-tijd op de pagina, eenvoudiger en betrouwbaarder.

Als API’s nieuw voor je zijn, leggen wat is een API en wat is een database de basis uit.

Kies de juiste grafiek

• Een enkel getal met verandering (‘€42k, 8% hoger dan vorige maand’): een KPI-kaart. Het nuttigste element op de meeste dashboards.
• Trend in de tijd: een lijngrafiek. Gebruik staven alleen bij een klein aantal periodes.
• Categorieën vergelijken: een horizontale staafgrafiek, gesorteerd op waarde.
• Deel van een geheel: een gestapelde staaf. Taartgrafieken werken alleen met twee of drie plakjes.
• Detail en uitzonderingen: een tabel met sorteren, zoeken en filters. Vaak nuttiger dan welke grafiek ook.

Houd kleuren consistent: één kleur voor ‘deze periode’, een gedempte kleur voor ‘vergelijking’, rood alleen voor zaken die aandacht nodig hebben.

Wie ziet wat

Bepaal de toegang voordat je bouwt:

• Intern, iedereen ziet alles: het eenvoudigst. Toch heb je login nodig als er bedrijfsgegevens in staan.
• Op rol gebaseerd: sales ziet salescijfers, financiën ziet marges, managers zien hun eigen team.
• Voor klanten: elke klant ziet alleen de eigen gegevens. Elke query moet op de server filteren op het account van de klant. Test dit door met twee verschillende klanten in te loggen.

Een dashboard met omzet- of klantgegevens op een openbare URL zonder login is een datalek dat wacht om gevonden te worden.

Een eerste prompt die werkt

Bouw een verkoopdashboard voor een B2B-softwarebedrijf met 10 mensen. Doelgroep: de oprichters en de salesmanager, die het elke maandag controleren. Overzichtspagina: KPI-kaarten voor nieuwe MRR deze maand, totale MRR, nieuwe klanten deze maand, opgezegde klanten deze maand en pijplijnwaarde, elk met de verandering ten opzichte van vorige maand; een lijngrafiek van MRR over de laatste 12 maanden; een staafgrafiek van nieuwe deals per bron. Een Deals-pagina met een doorzoekbare, sorteerbare tabel (bedrijf, eigenaar, waarde, fase, sluitingsdatum) en filters op eigenaar en fase. Definities van meetwaarden: MRR is de som van actieve maandelijkse abonnementsbedragen, jaarabonnementen gedeeld door 12; churn telt klanten wiens abonnement deze maand is beëindigd. Gebruik realistische voorbeeldgegevens in een database voor nu; we koppelen later Stripe. Toon een ‘laatst bijgewerkt’-tijd. Login verplicht. Overzichtelijke lay-out met zijbalk.

Bouwstappen

1. Lay-out met voorbeeldgegevens. Spreek de meetwaarden en grafieken af terwijl de data nep en makkelijk aan te passen is.
2. Koppel één echte bron. Controleer elk cijfer met de hand in het bronsysteem. Als MRR afwijkt van wat Stripe toont, zoek dan uit waarom voordat je verder gaat.
3. Voeg de andere bronnen toe, één voor één, en controleer elke bron.
4. Geplande verversing of queries bij het laden, met een ‘laatst bijgewerkt’-label.
5. Filters: eerst de datumperiode, daarna de een of twee andere waar mensen om vragen.
6. Login en rollen.
7. Lege en foutstatussen: wat de pagina toont als een bron uitvalt of een filter niets oplevert.
8. Deel het met het publiek, en verwijder daarna na een maand alles wat niemand bekijkt.

Maak het snel

Een traag dashboard wordt minder vaak gecontroleerd. Bereken dure totalen vooraf (een dagelijkse samenvattingstabel in plaats van elke bestelling doorzoeken), pagineer grote tabellen, en laad eerst de kerncijfers zodat de pagina bruikbaar is voordat de grafieken klaar zijn. Duurt een cijfer lang om te berekenen, toon dan wanneer het voor het laatst is berekend in plaats van het bij elk bezoek opnieuw te doen.

Veelgemaakte fouten

• Te veel grafieken. Als alles is uitgelicht, valt niets meer op.
• Ongedefinieerde meetwaarden. Twee mensen die hetzelfde dashboard lezen, moeten tot dezelfde conclusie komen.
• Cijfers nooit tegen de bron checken. Eén fout cijfer en mensen vertrouwen het hele dashboard niet meer.
• Bij elke paginalading alle API’s bevragen. Traag, broos en soms duur.
• Geen datumcontext. Toon altijd de periode en de vergelijking.
• Geheimen in de frontend. Een API-sleutel die in de browser zichtbaar is, kan door iedereen die de pagina opent worden gekopieerd.

Wanneer een BI-tool de betere keuze is

Als je data al in een database of datawarehouse staat en de belangrijkste gebruikers analisten zijn die die data willen verkennen, doorsnijden en eigen grafieken bouwen, dan dient een BI-tool hen beter dan een eigen bouw. Looker Studio, Power BI, Metabase en andere. Veel SaaS-tools hebben ook goede ingebouwde rapporten; kijk die eerst na voordat je ze opnieuw bouwt. Een eigen dashboard wint wanneer het voor klanten of niet-analisten is, logica of rechten nodig heeft die de BI-tool niet kan uitdrukken, gegevens uit meerdere bronnen op een manier die specifiek is voor jouw bedrijf combineert, of hoort in een product dat je al draait.

Als het doel minder het bekijken van cijfers is en meer het wijzigen van records, heb je eerder een beheerpaneel of interne tool nodig; zie hoe je een interne tool bouwt. En staan je cijfers nu in een spreadsheet, dan is hoe je een spreadsheet omzet in een app een goede volgende lees.

Bouwen met Mythex

Bij Mythex beschrijf je het dashboard en bouwt de agent de pagina’s en grafieken in een live preview, te beginnen met realistische voorbeeldgegevens en overgaand naar een eigen Postgres-database zodra de cijfers moeten blijven bestaan. De use case voor dashboards in de documentatie heeft een startprompt. Staat je data in een tool zoals Google Sheets, dan kun je het account koppelen via Connectors en de agent vragen het te lezen en er een dashboard van te maken.

Er zijn geen ingebouwde datawarehouse-connectors voor de app zelf. Voor BigQuery, Snowflake, Stripe en vergelijkbare diensten roept de app hun API’s aan met sleutels die je als projectgeheimen opslaat. Login en rollen voor de mensen die het dashboard bekijken maken deel uit van de app die je bouwt. Om vanuit een prompt te starten, bekijk de dashboardsjablonen, zoals het metrics-dashboard.

Veelgestelde vragen