ДЕМО · синтетичні дані · структура за 11 показниками ТЗ

Retention-дашборд: повторні замовлення з KeyCRM

Макет на вигаданих даних (2 800 клієнтів, 5 Telegram-акаунтів, ~14 місяців історії), розрахований за формулами з вашого ТЗ: «нова робота» окремо від «Платних правок», rolling-12 місяців, когорти, dormant-сегменти. Перемикайте акаунт і період — усі цифри перераховуються з тих самих «замовлень».

Акаунт:
Період перегляду: —

3.4 Конверсія в повторну покупку

% клієнтів, що зробили 2-ге замовлення протягом X днів після першого (беруться клієнти, чиє вікно X днів уже завершилось; період перегляду тут не звужує когорту).

3.5 Воронка кількості замовлень

Клієнти за кількістю оплачених замовлень «нова робота» (за весь час).

3.9 Реактивація dormant-клієнтів

Група фіксується, коли минув поріг без оплат; результат — після 60-денного вікна. Поріг змінюється одним параметром, без переробки логіки.

Поріг dormant, днів:

3.6 / 3.8 За категоріями послуг

Медіана часу до наступної покупки і LTV за категорією першого замовлення.

Когортна таблиця

Рядок — місяць першої оплати, стовпець — місяць життя. Значення — % клієнтів когорти, що оплатили «нову роботу» в цьому місяці.

Як це збудовано

KeyCRM API → завантаження за графіком (щодня / щотижня / щомісяця) → сховище PostgreSQL → SQL-в’ю з формулою кожного показника → BI-дашборд (Metabase / Looker Studio).
Формули лежать у SQL-в’ю, а не у візуальному шарі: їх можна прочитати й змінити. Поріг dormant, межі сегментів і назва товару «Платні правки» — у таблиці параметрів.
Приймання: звірка значень на вибірці 20–30 клієнтів із ручним розрахунком; сума по акаунтах = показник по компанії (перевірка вгорі сторінки).

Усі числа на сторінці згенеровані для демонстрації й не належать жодній реальній компанії. На реальному проєкті першим кроком іде перевірка даних у KeyCRM: зв’язки клієнт–замовлення–оплата, картки лояльності, реактиваційні комунікації.