Звіт чи аналітичний дашборд. Як не помилитись та перевірити себе
Вітаю, спільното! Мене звати Павло, я працюю аналітиком на підприємстві по виготовленню та реалізації електронних елементів. У вільний від роботи час я, як і більшість із нас, іноді залипаю в соцмережі, зокрема в LinkedIn, там багато людей, які тільки пізнають аналітику, публікують свої роботи.
Думаю, що ця стаття — це буде звернення, в першу чергу, до них, бо писати коментарі кожному, я не завжди можу :D.
Отже, переглядаючи роботи початківців, я постійно спосерігаю, що людина підключає дані, рахує кілька KPI, будує тренд продажів, додає Top 10 продуктів, розподіл за регіонами, категоріями і тд, і технічно все зроблено добре і правильно, бо формули робочі, а фільтри фільтрують, але потім я починаю читати опис і бачу, що текст не зовсім відповідає візуалу, що висновки є, а доказів немає, що факти і інсайти підмінені одним одним, а аналітика там тільки описова.
Головною проблемою таких робіт я можу назвати те, що на такому дашборді часто немає питання, на яке він має відповісти. Він демонструє набір фактів, а от всю аналітичну роботу залишає користувачу, який має самостійно знайти зв’язок між показниками, оцінити його важливість і зрозуміти, яке рішення можна ухвалити.
На прикладі одного простого дашборду я покажу, як кількома змінами перетворити огляд даних на послідовний аналітичний аргумент. Для цього я не використовував, прогнозування, LOD-вирази чи статистичні моделі. Основна зміна відбулась у логіці, тому кожен зможе покращити свій дашборд вже всьогодні.
Де закінчується опис і починається аналітика
Описова аналітика відповідає на питання «що відбулось?». Вона показує виручку, прибуток, кількість замовлень, динаміку показника, розподіл продажів між категоріями, цей список можна продувжувати, але я думаю, що суть ви зрозуміли. Варто зауважити, що це нормальний і потрібний рівень роботи з даними, без нього дуже складно зрозуміти поточний стан бізнесу.
Тільки окремий факт ще не є інсайтом, а фраза «у червні продажі знизились» переказує положення лінії на графіку і все, а нам треба, щоб з’явилась аналітика, щоб ми зрозуміли чому «у червні продажі знизились», бо на цей момент ми вже часто знаємо, що вона впала, і нам не треба ще раз це озвучувати, нам треба відповіді.
Грубо кажучи, описова аналітика є частиною аналітичного процесу, і щоб дашборд не перетворився в звіт, треба переглянути структуру дашборду і зосередитись на вирішенні якогось конктерного питання, а вась аналітичний маршрут виглядає так: ізнес-питання, релевантні показники, порівняння, інтерпретація та рішення, яке дані можуть підтримати.

Повернемось до нашого рпикладу. Я знайшов його випадково на Tableau Public. Тут ми бачимо Total Sales, Total Profit, Total Orders і Total Customer. Нижче розташовані продажі за категоріями, регіонами, місячний тренд, способи оплати, Top 10 продуктів і Return Analysis.

Кожна візуалізація окремо повідомляє коректний факт. Ми знаємо, що загальний обсяг продажів становить 734 250 доларів, прибуток —118 969 доларів, а кількість замовлень — 1 000, бачимо, які категорії і регіони продають більше, який продукт очолює рейтинг і скільки замовлень було повернуто, але між цими фактами немає спільної логіки.
Місячний тренд не має цілі, попереднього періоду, пояснення сезонності, тому коливання можна констатувати, не більше. Top 10 продуктів побудовано за продажами, але без прибутку, маржинальності чи частки повернень ми не знаємо, що релаьно ці продукти несуть бізнесу.
Кругова діаграма Payment Mode займає багато місця, використовує аж дві легенди, змушує зіставляти колір сектора з окремими підписами (це мало стосується саме аналітичного аспекту, але я не міг це проігнорувати), і тільки так ми можемо побачити, скільки продажів припадає на кожен спосіб оплати. Без комісії, конверсії, частоти відмов ця інформація не дає нам жодного рішення.
Return Analysis з двома стовпчиками No і Yes має схожу проблему. Візуалізація показує, що неповернених замовлень більше, хоча це й без графіка очікуваний результат. Тут немає вартості повернень, проблемних продуктів або причин, через які вони виникають. Сам заголовок нам обіцяє аналіз, але це не аналіз, а констатація фактів.
Цей дашборд можна використовувати як загальний огляд стану магазину, але якщо це видавати за готовий аналіз, то це стає проблемою.
Перевтілення
Тепер, коли ми побачили, що цей дашборд має певні проблеми, можна подумати. що тут проблема в даних чи погано підібраних візуалізаціях, але ні, в першу чергу — тут немає питання, а якщо немає питання, то не буде й відповіді. З цього і почнемо.
Для того, щоб цей дашборд почав виконувати свою функцію, спробуємо спочатку поставити питання. Я дослідив дані до цієї роботи і у мене виникло питання, на яке я спробую знайти відповідь:
Чи збільшує вища знижка розмір замовлення настільки, щоб компенсувати падіння прибутковості?
Коли питання сформульоване, то ми вже розуміємо, що нам треба, щоб перевірити цю гіпотезу. Дашборд — це не база даних, тому не треба використовувати кожен біт інформації, який нам доступний. Візьмемо тільки необхідні дані, зробимо просто розразунки і побачимо, що вийшло. Будемо розраховувати:
- Profit Ratio = Profit / Sales;
- Average Order Value = Sales / Orders;
- Profit per Order = Profit / Orders;
- Quantity per Order = Quantity / Orders.
Total Sales, Total Profit і Total Orders треба нам як загальний контекст. Замість Total Customer, який був в оригіналі, ми візьмемо Profit Ratio, він нам потрібен, бо він безпосередньо характеризує прибутковість продажів. Category та Region стали фільтрами, а не повноцінними графіками, тепер вони допомагають перевірити, чи зберігається закономірність у різних частинах бізнесу, але не займають місця.

Центральною візуалізацією став Profit Ratio by Discount, під ним ми розташували Average Order Value, Profit per Order і Quantity per Order у тому самому розрізі знижки. Всі графіки працюють як одна історія, ми спочатку бачимо зміну прибутковості, а потім перевіряємо можливу компенсацію через більший чек або більшу кількість товарів.
Коли я оновлював роботу, то використовував контейнери, завдяки цьому блоки мають однакові відступи, заповнюють доступний простір і зберігають чітку ієрархію. Це вже питання дизайну, а не аналітики, але дизайн допомагає побачити закладений аналітичний маршрут. Так, я контейнери не перейменува, за що прошу мене пробачити))

Відповідь
Тепер, коли у нас перед очима одна аналітична історія, ми можемо озвучити те, що ми бачимо.
За відсутності знижки Profit Ratio становить 20,7%, а при знижці 20% він падає до 10,6%, тобто різниця становить 10,1 відсоткового пункту. Profit per Order одночасно знижується з 152 до 81 долара, приблизно на 47%.
Також ми бачимо, що це падіння не компенсується більшим кошиком. Average Order Value зростає з 735 до 762 доларів, приблизно на 3,7%, але між рівнями знижки немає стабільного висхідного тренду. Quantity per Order залишається близько 4,6 товару без знижки і 4,5 товару при знижці 20%, тобто різниця практично відсутня.
Отже, в наявних даних вищі знижки пов’язані із значним падінням прибутку на замовлення, разом з тим, системного збільшення кошика ми не бачимо. Щоб оцінити наслідок, уявімо 100 замовлень, вони без знижки принеслиб приблизно $15 200 прибутку. При знижці 20% одне замовлення приносить $81, тому для отримання тих самих $15 200 знадобиться приблизно 188 замовлень ($15 200 ÷ $81 ≈ 188). Це на 88 замовлень, або приблизно на 88%, більше. Такий розрахунок справедливий лише за інших незмінних умов, зокрема однакової структури продажів і витрат, але ситуація не дуже.
Тепер ми бачимо, що треба перевірити доцільність знижок
Важливо пам’ятати, що дашборд не доводить, що знижки потрібно скасувати. Ми аналізуємо історичні замовлення, але не бачимо сценарію, коли покупці відмовились від покупки без знижок. Для таких висновків вже не обійтись без експериментів, порівняння груп клієнтів, моделі цінової еластичності. Думаю, тут ми можемо провести межу між спостереженням і причинним твердженням.
Підсумок
Тепер давайте подивимось, що ми отримали, використавши ті самі дані, додавши до них пару фільтрів, пару рохзахункових полів і пару найпростіших графіків (так, дашборд не є еталоном, але я це зробив спеціально).
Початкова версія дозволяла переглядати датасет з різних боків, а поточна веде від сформульованого питання через порівняння до висновку і рекомендацій, оцу і є різничею між звітом і аналітичним продуктом.
Тому, коли будете робити свій наступний дашборд, рекомендую спочатку поставити якесь конкретне питання, визначити, що саме допоможе його перевірити і зафіксувати відповіді і рекомендації. Якщо ж відповіді немає, можливо, ви робите звіт,в такому випадку варто його так і називати, не підміняючи констатацію фактів інсайтами.
P.S: Більше про аналітику пишу тут.
2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівСітація не дуже, але тому що тут немає вищого рівня. Яка ринкова ситуація загалом? Навіщо ми взагалі застосували знижку?... Можливо, стикнулись з ціновим демпінгом конкурентів? і тепер треба «пережити» навіть ціною втрати прибутку...
Треба розуміти домен. Вміти ставити питання. Знати своє місце в харчовому ланцюгу )) розуміти кому і навіщо в и щось готуєте.
Дмитре, зауваження цілком справедливе, втім, якщо компанія змушена відповідати на ціновий демпінг і питання стоїть про виживання, тоді ми вже не шукаємо найефективнішу знижку, а визначаємо мінімально допустиму ціну, рахуємо маржу за ціни конкурента і оцінюємо, як довго бізнес може працювати в таких умовах.
Цей аналіз побудований на публічному датасеті, де немає цін конкурентів, причин застосування знижок, загальної ситуації на ринку, тому висновок обмежений тим, що можна перевірити, що ми й зробили, і дійшли до висновку, що в наявних даних вищі знижки не компенсуються відповідним збільшенням кошика. Решта — це вже окремі гіпотези, для перевірки яких потрібно більше контексту.