Sådan bygger du et dashboard: datakilder, nøgletal, diagrammer og adgang

For at bygge et dashboard skal du starte fra de spørgsmål, det skal besvare, og de personer, der skal læse det, definere et lille sæt nøgletal præcist, forbinde de data, nøgletallene kommer fra, og vælge et simpelt diagram til hvert. Bestem derefter, hvem der kan se hvilke tal. Et AI-app-værktøj kan generere et poleret dashboard på få minutter; det svære, og det, der afgør, om nogen stoler på det, er at få data og definitioner rigtige.

Start med spørgsmål, ikke diagrammer

Et dashboard, der forsøger at vise alt, bliver åbnet én gang. Før du tænker på diagrammer, så besvar:

• Hvem er det til? Stifteren, et salgsteam, drift, investorer, dine kunder?
• Hvilke beslutninger understøtter det? „Skal vi ansætte endnu en supportmedarbejder?“ er et spørgsmål, et dashboard kan besvare. „Vis mig vores data“ er ikke.
• Hvor ofte vil de kigge? Daglige driftsdashboards har brug for friske data og alarmer; en månedlig bestyrelsesvisning gør ikke.

Skriv tre til fem spørgsmål. Hvert bliver til et eller to nøgletal.

Definer hvert nøgletal præcist

De fleste diskussioner om dashboards er egentlig diskussioner om definitioner. Skriv en kort definition for hvert tal:

Sæt disse definitioner ind i din prompt. Ellers vælger en AI en fornuftig lydende beregning, der måske ikke matcher, hvordan din virksomhed tæller.

Hvor dataene kommer fra

To principper gælder overalt:

1. Hold nøgler på serveren. API-nøgler og databaseadgangskoder hører hjemme i appens miljøvariabler, aldrig i browserkode.
2. Beslut friskhed. At hente fra flere API’er ved hver sideindlæsning er langsomt og kan ramme rate limits. Til de fleste forretningsdashboards er en synkronisering hver time eller natten over ind i din egen database, med et „sidst opdateret“-tidspunkt på siden, enklere og mere pålidelig.

Hvis API’er er nye for dig, forklarer hvad er en API og hvad er en database det grundlæggende.

Vælg det rigtige diagram

• Enkelt tal med ændring („42.000 kr., op 8 % ift. sidste måned“) — et nøgletalskort. Det mest nyttige element på de fleste dashboards.
• Udvikling over tid — et linjediagram. Brug søjler kun for et lille antal perioder.
• Sammenligning af kategorier — et vandret søjlediagram, sorteret efter værdi.
• Del af en helhed — et stablet søjlediagram. Kagediagrammer fungerer kun med to eller tre skiver.
• Detaljer og undtagelser — en tabel med sortering, søgning og filtre. Ofte mere nyttig end noget diagram.

Hold farverne konsistente: én farve til „denne periode“, en dæmpet til „sammenligning“, rød kun til ting, der kræver opmærksomhed.

Hvem ser hvad

Beslut adgang før bygning:

• Intern, alle ser alt — simplest. Kræver stadig login, hvis den indeholder forretningsdata.
• Rollebaseret — salg ser salgstal, økonomi ser marginer, ledere ser deres eget team.
• Kundevendt — hver kunde ser kun sine egne data. Hver forespørgsel skal filtrere på kundens konto på serveren. Test det ved at logge ind som to forskellige kunder.

Et dashboard med omsætnings- eller kundedata på en offentlig URL uden login er en datalæk, der bare venter på at blive fundet.

En første prompt der virker

Byg et salgsdashboard til et B2B-softwareselskab med 10 medarbejdere. Målgruppe: stifterne og salgschefen, som kigger på det hver mandag. Oversigtsside: nøgletalskort for ny MRR denne måned, total MRR, nye kunder denne måned, opsagte kunder denne måned og pipeline-værdi, hver med ændringen ift. sidste måned; et linjediagram over MRR de sidste 12 måneder; et søjlediagram over nye handler pr. kilde. En side Handler med en søgbar, sorterbar tabel (virksomhed, ejer, værdi, fase, lukkedato) og filtre på ejer og fase. Definitioner: MRR er summen af aktive månedlige abonnementsbeløb, årsabonnementer divideret med 12; frafald tæller kunder, hvis abonnement sluttede denne måned. Brug realistiske eksempeldata i en database indtil videre — vi forbinder Stripe senere. Vis et „sidst opdateret“-tidspunkt. Login påkrævet. Rent layout med sidemenu.

Den navngiver målgruppen, hvert nøgletal med dets definition, diagrammerne og dataplanen — og starter med eksempeldata, så I kan blive enige om designet, før rigtige kilder forbindes.

Byggetrin

1. Layout med eksempeldata. Bliv enige om nøgletal og diagrammer, mens dataene er falske og billige at ændre.
2. Forbind én rigtig kilde. Tjek hvert tal mod kildesystemet i hånden. Hvis MRR afviger fra det, Stripe viser, så find ud af hvorfor, før du går videre.
3. Tilføj de andre kilder, én ad gangen, og tjek hver.
4. Planlagt opdatering eller forespørgsler ved indlæsning, med en „sidst opdateret“-label.
5. Filtre — datointerval først, derefter de et eller to andre, folk spørger om.
6. Login og roller.
7. Tomme og fejltilstande — hvad siden viser, når en kilde er nede, eller et filter ikke giver noget.
8. Del det med målgruppen, og fjern derefter alt, som ingen kigger på efter en måned.

Gør det hurtigt

Et langsomt dashboard bliver tjekket mindre. Forudberegn totaler, der er dyre at udregne (en daglig opsummeringstabel i stedet for at scanne hver ordre), paginér store tabeller, og indlæs hovedkortene først, så siden er brugbar, før diagrammerne er færdige. Hvis et tal tager lang tid at beregne, så vis hvornår det sidst blev udregnet i stedet for at genberegne ved hvert besøg.

Almindelige fejl

• For mange diagrammer. Hvis alt er fremhævet, er intet fremhævet.
• Udefinerede nøgletal. To personer, der læser det samme dashboard, skal nå frem til samme konklusion.
• Aldrig at tjekke tal mod kilden. Ét forkert tal, og folk holder op med at stole på hele dashboardet.
• At forespørge hver API ved hver sideindlæsning. Langsomt, skrøbeligt og somme tider dyrt.
• Ingen datokontekst. Vis altid perioden og sammenligningen.
• Hemmeligheder i frontenden. En API-nøgle synlig i browseren kan kopieres af enhver, der åbner siden.

Hvornår et BI-værktøj er det bedre valg

Hvis dine data allerede ligger i en database eller et warehouse, og de vigtigste brugere er analytikere, der vil udforske, skære i og bygge deres egne diagrammer, så vil et BI-værktøj — Looker Studio, Power BI, Metabase og andre — tjene dem bedre end en egen løsning. Mange SaaS-værktøjer har også gode indbyggede rapporter; tjek dem, før du bygger dem om. Et eget dashboard vinder, når det er til kunder eller ikke-analytikere, kræver logik eller rettigheder, som BI-værktøjet ikke kan udtrykke, kombinerer kilder på en måde, der er specifik for din virksomhed, eller hører hjemme i et produkt, du allerede kører.

Hvis opgaven handler mindre om at se tal og mere om at ændre poster, så har du brug for et admin-panel eller internt værktøj i stedet — se sådan bygger du et internt værktøj. Og hvis dine tal i dag ligger i et regneark, er sådan gør du et regneark til en app en god næste læsning.

At bygge det med Mythex

På Mythex beskriver du dashboardet, og agenten bygger siderne og diagrammerne i en live forhåndsvisning, startende med realistiske eksempeldata og flytter til en dedikeret Postgres-database, når tallene skal gemmes. Dokumentationens dashboard-use case har en startprompt. Hvis dine data ligger i et værktøj som Google Sheets, kan du forbinde kontoen via Connectors og bede agenten læse den og bygge et dashboard ud fra den.

Der er ingen indbyggede warehouse-forbindelser til selve appen — til BigQuery, Snowflake, Stripe og lignende kalder appen deres API’er med nøgler, du gemmer som projekthemmeligheder. Logins og roller for de personer, der ser dashboardet, er en del af den app, du bygger. For at starte fra en prompt, se dashboard-skabelonerne, fx metrics-dashboardet.

Spørgsmål