Jak zbudować dashboard: źródła danych, KPI, wykresy i dostęp

Żeby zbudować dashboard, zacznij od pytań, na które ma odpowiadać, i od osób, które go przeczytają, zdefiniuj precyzyjnie niewielki zestaw wskaźników, połącz dane, z których te wskaźniki pochodzą, i wybierz prosty wykres dla każdego z nich. Potem ustal, kto może widzieć które liczby. Narzędzie do budowy aplikacji z AI wygeneruje dopracowany dashboard w kilka minut; trudna część, i ta, która decyduje o tym, czy ktokolwiek mu zaufa, to poprawne dane i definicje.

Zacznij od pytań, nie od wykresów

Dashboard, który próbuje pokazać wszystko, zostaje otwarty raz. Zanim pomyślisz o wykresach, odpowiedz na pytania:

• Dla kogo jest? Dla założyciela, zespołu sprzedaży, operacji, inwestorów, Twoich klientów?
• Jakie decyzje wspiera? „Czy potrzebujemy kolejnej osoby w wsparciu?” to pytanie, na które dashboard może odpowiedzieć. „Pokaż mi nasze dane” — nie.
• Jak często będą na niego zaglądać? Codzienne dashboardy operacyjne potrzebują świeżych danych i alertów; miesięczny widok dla zarządu — nie.

Zapisz trzy do pięciu pytań. Każde staje się jednym lub dwoma wskaźnikami.

Zdefiniuj każdy wskaźnik dokładnie

Większość sporów o dashboard to spory o definicje. Napisz krótką definicję dla każdej liczby:

Wklej te definicje do promptu. W przeciwnym razie AI wybierze rozsądnie brzmiący sposób liczenia, który może nie pasować do tego, jak Twój biznes liczy.

Skąd pochodzą dane

Dwie zasady obowiązują wszędzie:

1. Trzymaj klucze na serwerze. Klucze API i hasła do baz należą do zmiennych środowiskowych aplikacji, nigdy do kodu w przeglądarce.
2. Ustal świeżość danych. Pobieranie z kilku API przy każdym ładowaniu strony jest powolne i może trafić na limity zapytań. Dla większości dashboardów biznesowych wystarczy synchronizacja co godzinę lub w nocy do własnej bazy danych, z czasem „ostatnia aktualizacja” na stronie; to prostsze i bardziej niezawodne.

Jeśli API są dla Ciebie nowością, czym jest API i czym jest baza danych wyjaśniają podstawy.

Wybierz właściwy wykres

• Pojedyncza liczba ze zmianą („42 tys. zł, wzrost o 8% w porównaniu z poprzednim miesiącem”) — karta KPI. Najbardziej użyteczny element większości dashboardów.
• Trend w czasie — wykres liniowy. Słupki używaj tylko przy małej liczbie okresów.
• Porównanie kategorii — poziomy wykres słupkowy, posortowany według wartości.
• Część całości — słupek skumulowany. Wykresy kołowe nadają się tylko dla dwóch lub trzech wycinków.
• Szczegóły i wyjątki — tabela z sortowaniem, wyszukiwaniem i filtrami. Często bardziej przydatna niż jakikolwiek wykres.

Utrzymuj spójne kolory: jeden kolor dla „tego okresu”, stonowany dla „porównania”, czerwony tylko dla rzeczy wymagających uwagi.

Kto co widzi

Ustal dostęp przed budową:

• Wewnętrzny, wszyscy widzą wszystko — najprostsze. Nadal wymaga logowania, jeśli zawiera dane biznesowe.
• Oparty na rolach — sprzedaż widzi liczby sprzedaży, finanse widzą marże, menedżerowie widzą swój zespół.
• Dla klientów — każdy klient widzi tylko swoje dane. Każde zapytanie musi filtrować po koncie klienta na serwerze. Przetestuj to, logując się jako dwóch różnych klientów.

Dashboard z przychodami lub danymi klientów pod publicznym adresem bez logowania to wyciek danych, który czeka, aż ktoś go znajdzie.

Pierwszy prompt, który działa

Zbuduj dashboard sprzedaży dla firmy produkującej oprogramowanie B2B, zatrudniającej 10 osób. Odbiorcy: założyciele i szef sprzedaży, sprawdzający go w każdy poniedziałek. Strona przeglądu: karty KPI dla nowego MRR w tym miesiącu, całkowitego MRR, nowych klientów w tym miesiącu, klientów, którzy odeszli w tym miesiącu, i wartości lejka, każda ze zmianą względem poprzedniego miesiąca; wykres liniowy MRR z ostatnich 12 miesięcy; wykres słupkowy nowych transakcji według źródła. Strona Transakcje z tabelą z wyszukiwaniem i sortowaniem (firma, właściciel, wartość, etap, data zamknięcia) oraz filtrami po właścicielu i etapie. Definicje metryk: MRR to suma aktywnych miesięcznych kwot subskrypcji, a plany roczne dzielone przez 12; odpływ liczy klientów, których subskrypcja zakończyła się w tym miesiącu. Na razie używaj realistycznych przykładowych danych w bazie — Stripe podłączymy później. Pokaż czas „ostatniej aktualizacji”. Wymagane logowanie. Czysty układ z paskiem bocznym.

Prompt wymienia odbiorców, każdy wskaźnik z jego definicją, wykresy i plan danych — i zaczyna od przykładowych danych, żebyście mogli uzgodnić projekt, zanim podłączycie prawdziwe źródła.

Kroki budowy

1. Układ z przykładowymi danymi. Uzgodnijcie wskaźniki i wykresy, dopóki dane są sztuczne i tanie w zmianie.
2. Połącz jedno prawdziwe źródło. Sprawdź każdą liczbę ręcznie z systemem źródłowym. Jeśli MRR różni się od tego, co pokazuje Stripe, dowiedz się dlaczego, zanim pójdziesz dalej.
3. Dodaj pozostałe źródła, jedno po drugim, sprawdzając każde.
4. Zaplanowane odświeżanie lub zapytania przy ładowaniu, z etykietą „ostatnia aktualizacja”.
5. Filtry — najpierw zakres dat, potem jeden lub dwa inne, o które ludzie prosią.
6. Logowanie i role.
7. Stany pusty i błędu — co strona pokazuje, gdy źródło nie działa albo filtr nic nie zwraca.
8. Udostępnij odbiorcom, a po miesiącu usuń to, na co nikt nie patrzy.

Zrób to szybko

Wolny dashboard jest sprawdzany rzadziej. Wstępnie oblicz kosztowne sumy (dzienna tabela podsumowań zamiast przeszukiwania każdego zamówienia), dziel duże tabele na strony i ładuj najpierw karty z najważniejszymi liczbami, żeby strona była użyteczna, zanim dokończą się wykresy. Jeśli obliczenie liczby trwa długo, pokaż, kiedy była ostatnio liczona, zamiast przeliczać ją przy każdej wizycie.

Częste błędy

• Zbyt wiele wykresów. Jeśli wszystko jest wyróżnione, nic nie jest.
• Niezdefiniowane wskaźniki. Dwie osoby czytające ten sam dashboard powinny dojść do tego samego wniosku.
• Nigdy nieporównywanie liczb ze źródłem. Jedna błędna liczba i ludzie przestają ufać całemu dashboardowi.
• Odpytywanie każdego API przy każdym ładowaniu strony. Powolne, kruche i czasem kosztowne.
• Brak kontekstu dat. Zawsze pokazuj okres i porównanie.
• Sekrety we frontendzie. Klucz API widoczny w przeglądarce może skopiować każdy, kto otworzy stronę.

Kiedy lepszym wyborem jest narzędzie BI

Jeśli Twoje dane już leżą w bazie lub hurtowni, a głównymi użytkownikami są analitycy, którzy chcą je eksplorować, kroić i budować własne wykresy, narzędzie BI — Looker Studio, Power BI, Metabase i inne — posłuży im lepiej niż budowa na zamówienie. Wiele narzędzi SaaS ma też dobre wbudowane raporty; sprawdź je, zanim zbudujesz je od nowa. Własny dashboard wygrywa, gdy jest przeznaczony dla klientów lub osób nietechnicznych, wymaga logiki lub uprawnień, których narzędzie BI nie obsłuży, łączy źródła w sposób specyficzny dla Twojego biznesu albo ma być częścią produktu, który już prowadzisz.

Jeśli zadanie polega mniej na przeglądaniu liczb, a bardziej na zmienianiu rekordów, potrzebujesz panelu administracyjnego lub narzędzia wewnętrznego — zobacz jak zbudować narzędzie wewnętrzne. A jeśli Twoje liczby dziś leżą w arkuszu, dobrą kolejną lekturą jest jak zamienić arkusz w aplikację.

Budowa z Mythex

W Mythex opisujesz dashboard, a agent buduje strony i wykresy w podglądzie na żywo, zaczynając od realistycznych przykładowych danych i przechodząc do dedykowanej bazy Postgres, gdy liczby mają być trwale zapisywane. Przypadek użycia dashboardu w dokumentacji zawiera gotowy prompt startowy. Jeśli Twoje dane są w narzędziu takim jak Arkusze Google, możesz połączyć konto przez Konektory i poprosić agenta, by je odczytał i zbudował na ich podstawie dashboard.

Samej aplikacji nie ma wbudowanych konektorów do hurtowni — dla BigQuery, Snowflake, Stripe i podobnych aplikacja wywołuje ich API z kluczami, które zapisujesz jako sekrety projektu. Logowanie i role dla osób przeglądających dashboard są częścią aplikacji, którą budujesz. Żeby zacząć od promptu, przejrzyj szablony dashboardów, na przykład dashboard metryk.

Pytania