Как да създадете табло: източници на данни, KPI, графики и достъп

За да създадете табло, започнете от въпросите, на които трябва да отговаря, и от хората, които ще го четат, дефинирайте точно малък набор от показатели, свържете данните, от които идват тези показатели, и изберете проста графика за всеки. После решете кой може да вижда кои числа. Инструмент за създаване на приложения с ИИ може да генерира изчистено табло за минути; трудната част, и тази, която определя дали някой му вярва, е да подредите данните и дефинициите правилно.

Започнете с въпроси, не с графики

Табло, което се опитва да покаже всичко, се отваря веднъж. Преди да мислите за графики, отговорете на:

• За кого е? За основателя, за екипа по продажби, за операциите, за инвеститори, за клиентите ви?
• Какви решения подкрепя? „Трябва ли да наемем още един човек за поддръжка?“ е въпрос, на който таблото може да отговори. „Покажи ни данните“ не е.
• Колко често ще го гледат? Ежедневните оперативни табла се нуждаят от свежи данни и сигнали; месечният преглед за борда — не.

Напишете три до пет въпроса. Всеки става един или два показателя.

Дефинирайте точно всеки показател

Повечето спорове около таблата всъщност са спорове за дефиниции. Напишете кратко определение за всяко число:

Поставете тези дефиниции в подканата си. Иначе ИИ ще избере изчисление, което звучи разумно, но може да не съвпада с начина, по който бизнесът ви брои.

Откъде идват данните

Два принципа важат навсякъде:

1. Пазете ключовете на сървъра. API ключовете и паролите за базата данни принадлежат в променливите на средата на приложението, никога в кода на браузъра.
2. Решете колко свежи трябва да са данните. Дърпането от няколко API при всяко зареждане на страницата е бавно и може да удари лимитите. За повечето бизнес табла синхронизацията на всеки час или през нощта във ваша собствена база данни, с показано време на „последно обновяване“ на страницата, е по-проста и по-надеждна.

Ако API са нови за вас, какво е API и какво е база данни обясняват основите.

Изберете правилната графика

• Едно число с промяна („42 хил. $, нагоре с 8% спрямо миналия месец“) — карта с KPI. Най-полезният елемент в повечето табла.
• Тренд във времето — линейна графика. Стълбовете използвайте само за малко на брой периоди.
• Сравняване на категории — хоризонтална стълбовидна графика, сортирана по стойност.
• Част от цяло — натрупана стълбовидна графика. Кръговите диаграми работят само с две или три части.
• Детайли и изключения — таблица със сортиране, търсене и филтри. Често е по-полезна от всяка графика.

Пазете цветовете последователни: един цвят за „този период“, приглушен за „сравнение“, червено само за неща, които изискват внимание.

Кой какво вижда

Решете достъпа, преди да строите:

• Вътрешно, всеки вижда всичко — най-просто. Все пак изисква вход, ако съдържа бизнес данни.
• По роли — продажбите виждат продажбените числа, финансите виждат маржовете, мениджърите виждат своя екип.
• За клиенти — всеки клиент вижда само своите данни. Всяка заявка трябва да филтрира по акаунта на клиента на сървъра. Тествайте, като влезете с двама различни клиенти.

Табло с приходи или клиентски данни на публичен адрес без вход е изтичане на данни, което чака да бъде открито.

Първа подкана, която работи

Създай табло за продажби за B2B софтуерна компания с 10 души. Аудитория: основателите и ръководителят на продажбите, които го проверяват всеки понеделник. Преглед: карти с KPI за нов MRR този месец, общ MRR, нови клиенти този месец, отпаднали клиенти този месец и стойност на фунията, всяка със промяната спрямо миналия месец; линейна графика на MRR за последните 12 месеца; стълбовидна графика на новите сделки по източник. Страница Сделки с търсима, сортируема таблица (фирма, отговорник, стойност, етап, дата на сключване) и филтри по отговорник и етап. Дефиниции на показателите: MRR е сумата на активните месечни абонаментни суми, а годишните планове се делят на 12; отпадането брои клиенти, чийто абонамент е приключил този месец. Засега използвай реалистични примерни данни в база данни — Stripe ще свържем по-късно. Покажи време на „последно обновяване“. Изисква се вход. Чисто разположение със странично меню.

Подканата назовава аудиторията, всеки показател с дефиницията му, графиките и плана за данните — и започва с примерни данни, така че можете да се съгласите за дизайна, преди да свържете реални източници.

Стъпки за изграждане

1. Разположение с примерни данни. Съгласете показателите и графиките, докато данните са фалшиви и лесни за промяна.
2. Свържете един реален източник. Проверете всяко число ръчно със системата източник. Ако MRR се различава от това, което показва Stripe, разберете защо, преди да продължите.
3. Добавете другите източници, един по един, като проверявате всеки.
4. Планирано обновяване или заявки при зареждане, с етикет „последно обновено“.
5. Филтри — първо период от време, после един-два други, които хората искат.
6. Вход и роли.
7. Празни състояния и грешки — какво показва страницата, когато някой източник е недостъпен или филтър не връща нищо.
8. Споделете го с аудиторията, после махнете всичко, което никой не гледа след месец.

Направете го бързо

Бавното табло се проверява по-рядко. Предварително изчислявайте скъпите суми (дневна обобщителна таблица вместо сканиране на всяка поръчка), страницирайте големите таблици и зареждайте основните карти първо, така че страницата да е полезна, преди графиките да приключат. Ако едно число отнема дълго, показвайте кога е било изчислено последно, вместо да го изчислявате наново при всяко посещение.

Чести грешки

• Твърде много графики. Ако всичко е подчертано, нищо не е.
• Неопределени показатели. Двама души, които четат едно и също табло, трябва да стигнат до едно и също заключение.
• Без проверка на числата спрямо източника. Една грешна цифра и хората спират да вярват на цялото табло.
• Заявка към всеки API при всяко зареждане на страницата. Бавно, крехко и понякога скъпо.
• Без контекст за датите. Винаги показвайте периода и сравнението.
• Тайни във фронтенда. API ключ, видим в браузъра, може да бъде копиран от всеки, който отвори страницата.

Кога BI инструмент е по-добрият избор

Ако данните ви вече са в база данни или хранилище и основните потребители са анализатори, които искат да ги изследват, нарязват и правят собствени графики, BI инструмент — Looker Studio, Power BI, Metabase и други — ще им послужи по-добре от персонализирана разработка. Много SaaS инструменти също имат добри вградени отчети; проверете ги, преди да ги преправяте. Персонализираното табло печели, когато е за клиенти или за хора без аналитична подготовка, когато е нужна логика или права, които BI инструментът не може да изрази, когато комбинира източници по начин, специфичен за бизнеса ви, или когато принадлежи към продукт, който вече управлявате.

Ако задачата е по-малко за преглед на числа и повече за промяна на записи, вместо това ви трябва административен панел или вътрешен инструмент — вижте как да създадете вътрешен инструмент. А ако числата ви са в електронна таблица днес, как да превърнете електронна таблица в приложение е добро следващо четене.

Изграждане с Mythex

В Mythex описвате таблото, а агентът изгражда страниците и графиките в живия преглед, като започва с реалистични примерни данни и преминава към отделна Postgres база данни, когато числата трябва да се запазват. Случаят на употреба „табло“ в документацията има начална подкана. Ако данните ви са в инструмент като Google Sheets, можете да свържете акаунта през конекторите и да помолите агента да ги прочете и да създаде табло от тях.

За самото приложение няма вградени конектори към хранилища — за BigQuery, Snowflake, Stripe и подобни приложението извиква техните API с ключове, които съхранявате като тайни на проекта. Входовете и ролите за хората, които гледат таблото, са част от приложението, което изграждате. За да започнете от подкана, разгледайте шаблоните за табла, например таблото с показатели.

Въпроси