Дашборд для бізнесу: як зробити той, яким справді користуються

Більшість дашбордів помирає за місяць. Їх замовляють з ентузіазмом, на демо всі кивають, а потім власник знову просить менеджера «скинути цифри в Telegram». Причина рідко в інструменті. Зазвичай дашборд відповідає на запитання, яких ніхто не ставив, а на справжні — мовчить.

У цьому гайді — як я підходжу до дашборда для малого й середнього бізнесу: від запитань до даних, від даних до екрана і від екрана до звички щоранку туди дивитися.

#Що таке дашборд і чим він не є

Дашборд — це один екран, де людина за хвилину розуміє, чи все гаразд, і якщо ні — де саме проблема. Не сховище всіх можливих графіків, не заміна Excel і не презентація для інвесторів.

Корисно розрізняти три типи:

Найчастіша помилка — змішати всі три на одному екрані. Власник бачить 40 віджетів і закриває вкладку.

#Почніть із запитань, а не з графіків

Перша зустріч у мене ніколи не про візуалізацію. Я прошу записати 5–10 запитань, які людина ставить щотижня. Наприклад:

• Скільки ми заробили минулого тижня і це більше чи менше, ніж зазвичай?
• Який рекламний канал окупається, а який — ні?
• Чому впали заявки у вівторок?
• Скільки клієнтів повертаються вдруге?

Кожне запитання перетворюється на метрику з чітким визначенням, джерелом і порогом, після якого треба реагувати. Якщо метрика не веде ні до якої дії — вона не на першому екрані.

#Шаблон опису метрики

Цю таблицю я зберігаю як «словник метрик» — він потім стає підказками в самому дашборді.

#З чого складається дашборд технічно

Гарний екран — лише верхівка. Під ним чотири шари:

1. Джерела: GA4, Google Ads, Meta Ads, CRM (KeyCRM, Bitrix24, HubSpot), платформа магазину (Shopify, Horoshop, Prom), платежі (LiqPay, monobank), Google Таблиці.
2. Пайплайн: регулярне завантаження й очищення даних (ETL). Детально — у гайді про пайплайни даних.
3. Сховище й модель: BigQuery чи PostgreSQL з таблицями «одна версія правди» — замовлення, клієнти, витрати, сесії.
4. Візуалізація: власний кабінет, Looker Studio, Power BI чи Metabase.

Коли дашборд «показує не те», проблема майже завжди в шарах 1–3. Тому я не починаю з дизайну, доки не перевірено трекінг (чекліст аудиту).

#Що виносити на перший екран

Правило, яке працює: 4–6 KPI зверху, один головний графік, одна таблиця з деталізацією.

Для кожного KPI показуйте:

• значення за період;
• порівняння з попереднім періодом або тим самим тижнем минулого року;
• колір, що враховує «полярність» (зростання повернень — це погано, навіть якщо стрілка вгору);
• коротку підказку, як рахується.

Приклади наборів KPI за нішами:

Деталі по кожній ніші — у статтях про дашборд для інтернет-магазину, аналітику сервісного бізнесу, метрики SaaS і звіти для клієнтів агенції.

#Дизайн, який не заважає

Кілька принципів, які я застосовую завжди (більше — у правилах дизайну дашбордів):

• найважливіше — зліва вгорі, бо так читають екран;
• однакові формати чисел: роздільники тисяч, валюта, однакова кількість знаків;
• жодних 3D, «бубликів» на 9 сегментів і градієнтів заради краси;
• кольори кодують зміст (добре/погано, категорію), а не настрій;
• тренд важливіший за точне число — sparkline поруч із KPI;
• мобільна версія для власника, який дивиться звіт у дорозі.

#Готовий BI чи власний кабінет

Коротко: якщо в команді є аналітик, який хоче сам крутити дані, — BI-інструменти (Power BI, Looker Studio) чудові. Якщо дашбордом користуються нетехнічні люди, потрібні бренд, пояснення метрик, Telegram-звіти й дані на вашому сервері — власний кабінет часто зручніший і дешевший у довгу. Повне порівняння — у статтях Power BI чи Looker Studio і власний дашборд чи BI. Для разового звіту на готових таблицях може вистачити статичного мікродашборда.

#Скільки часу займає впровадження

Реалістичні терміни для одного аналітика:

Разом — від 2–4 тижнів для готового шаблону ніші до 4–8 тижнів для аналітики під ключ. Головне, що з'їдає час, — не код, а доступи й перевірка розбіжностей.

#Як зробити так, щоб дашбордом користувались

• Приносьте дані туди, де люди вже є: щоранку коротке зведення в Telegram з посиланням на дашборд (як налаштувати автозвіти).
• Пояснюйте зміни: «виручка −12%, бо вимкнули кампанію X» корисніше за сам −12%. Тут допомагає ШІ-асистент на даних.
• Призначте власника кожної метрики — того, хто реагує на відхилення.
• Переглядайте набір KPI раз на квартал і видаляйте те, на що ніхто не дивився.

#Чекліст хорошого дашборда

• Є список запитань, на які він відповідає
• Кожна метрика має формулу, джерело і власника
• Цифри звірено з CRM/бухгалтерією, розбіжності пояснено
• Перший екран — до 6 KPI з порівнянням і трендом
• Дані оновлюються автоматично, видно час останнього оновлення
• Є мобільна версія або Telegram-зведення
• Доступи розмежовано за ролями

#Приклад: від запитань до дерева метрик

Ось як «почати з запитань» виглядає на практиці для умовного інтернет-магазину з кількома сотнями замовлень на місяць. Усі цифри нижче ілюстративні.

Справжні запитання власника, записані на першій зустрічі:

1. «Ми цього місяця заробляємо чи лише крутимо оборот?»
2. «Якому рекламному каналу дати бюджет наступного місяця?»
3. «Клієнти повертаються?»

Кожне запитання стає однією метрикою верхнього рівня, а кожна метрика розкладається на драйвери, на які можна вплинути:

Дерево потрібне, бо воно підказує, що робити, коли верхнє число змінилося. Якщо маржа впала, дивимось рівнем нижче: впала виручка, зросла доставка чи реклама подорожчала без нових клієнтів? Дашборд лише з верхнім числом створює тривогу; дашборд з деревом — рішення.

#Розрахунок на прикладі

Припустимо, минулий місяць виглядав так:

Якщо наступного місяця реклама зросте до 240 000, а виручка — до 1 100 000 при тій самій структурі витрат, маржа стане 1 100 000 × (1 − 0,52 − 0,07 − 0,02) − 240 000 = 189 000 грн. Виручка +10%, маржа −10%. Саме таку ситуацію ховає дашборд «лише про виручку», і саме тому маржинальний прибуток має бути на першому екрані.

#Спочатку визначення метрик, потім графіки

Кожна метрика на дашборді потребує однорядкового визначення, з яким згодна вся команда. Я веду їх у простій таблиці поряд із дашбордом:

Три правила роблять цю таблицю корисною:

• Одна назва — одне визначення. Якщо фінанси й маркетинг під «виручкою» розуміють різне, потрібні дві назви, а не одна суперечка.
• Записуйте винятки. ПДВ, тестові, скасовані, внутрішні замовлення, подарункові сертифікати. Більшість суперечок живе саме у винятках.
• Призначте власника. Хтось має відповідати, коли число виглядає дивно.

#Зведена таблиця під дашбордом

Графіки не повинні ганяти важкі запити по сирих даних. Я будую одну щоденну зведену таблицю, і всі графіки беруть дані з неї. У BigQuery чи PostgreSQL основа виглядає так:

-- daily_summary: один рядок на день і канал
SELECT
  o.order_date                         AS day,
  COALESCE(o.channel, 'unknown')       AS channel,
  COUNT(DISTINCT o.order_id)           AS orders,
  COUNT(DISTINCT CASE WHEN o.is_first_order THEN o.customer_id END) AS new_customers,
  SUM(o.revenue_net)                   AS revenue,
  SUM(o.cogs + o.shipping + o.payment_fee) AS variable_costs,
  MAX(s.spend)                         AS ad_spend
FROM orders o
LEFT JOIN ad_spend_daily s
  ON s.day = o.order_date AND s.channel = o.channel
WHERE o.status = 'paid' AND NOT o.is_test
GROUP BY 1, 2;

Дві деталі легко зробити неправильно. По-перше, витрати приєднуються на рівні «день + канал» і беруться один раз (MAX), інакше вони множаться на кількість замовлень. По-друге, канали, що витратили гроші, але не дали жодного замовлення, зникають при такому з'єднанні — тому в робочій версії я спочатку будую сітку «дата × канал» і приєдную до неї і замовлення, і витрати.

#Щоденні перевірки якості даних

Дашборд втрачає довіру після першого неправильного числа, яке ніхто не помітив. Дешеві автоматичні перевірки запобігають більшості таких випадків:

• Рядок за вчора є для кожного активного каналу
• Замовлення у зведенні збігаються із CRM за вчора (±1–2% через час)
• Витрати не нульові для каналів з активними кампаніями
• Немає днів з від'ємною виручкою, якщо їх не пояснюють повернення
• Оновлення завершилося до часу, коли люди відкривають дашборд

Коли перевірка падає, повідомлення отримує відповідальна людина, а дашборд показує банер «дані запізнюються», а не мовчки показує неповний день.

#Типові помилки

#Як зрозуміти через місяць, що дашборд працює

Запуск — це не фініш. Через 4–6 тижнів я перевіряю кілька простих ознак:

• Його відкривають. Більшість BI-інструментів і власних кабінетів показують статистику переглядів. Якщо екран для власника відкривали двічі за місяць — він не відповідає на його запитання, і це треба обговорити, а не чекати.
• На нього посилаються в рішеннях. «Зменшили бюджет на канал X, бо маржа за каналом від'ємна третій тиждень» — ось ознака, що дашборд працює. «Подивились, цікаво» — ні.
• Зникли ручні таблиці. Якщо менеджер досі щотижня збирає ту саму звітність в Excel, значить, чогось бракує — дізнайтеся чого саме.
• Запитання стали глибшими. Замість «скільки продали?» з'являються «чому повторні покупки в категорії Y нижчі?». Це хороший знак: базові відповіді вже є, і можна додавати наступний рівень.

За результатами — коротка ітерація: прибрати віджети, на які ніхто не дивиться, додати одну-дві метрики, яких не вистачило, уточнити визначення, що викликали суперечки. Зазвичай друга версія дашборду значно корисніша за першу, і це нормально.

#Часті запитання

#Скільки коштує дашборд для бізнесу?

Залежить від кількості джерел, стану трекінгу і того, чи потрібен супровід. Готовий шаблон для ніші на ваших джерелах значно дешевший за аналітику з нуля. Точну оцінку я даю після короткого аудиту доступів.

#Чи можна почати з Google Таблиць?

Так, і часто варто. Таблиці підходять для першої версії й перевірки метрик. Межі цього підходу описані в статті про дашборд з Google Таблиць.

#Як часто мають оновлюватися дані?

Для більшості бізнесів достатньо щоденного оновлення вночі. Погодинне потрібне там, де рішення ухвалюються протягом дня — наприклад, при великих рекламних бюджетах.

#Хто має доступ до дашборда?

Зазвичай власник і керівники бачать усе, менеджери — свої розділи. У власному кабінеті доступи налаштовуються за ролями, а вхід можна захистити паролем з TOTP, Cloudflare Access або корпоративним VPN.