0 просмотренных постов скрыто
Главная метрика в ИТ
Источник: «Жиза ИТ руководителя»
Показать полностью
1
Психотерапевт для бизнеса
Недавно я получила комментарий к одному из моих постов, что "хороший аналитик" - это как психотерапевт для бизнеса!
Я полностью согласна с этим!
Психотерапия - это курс регулярных встреч, на которых врач с помощью специальных техник помогает пациенту понять причины его состояния, изменить деструктивные модели мышления и поведения, научиться справляться с трудностями и реагировать на стресс, а также развить навыки эмоциональной саморегуляции.
Так описывается взаимодействия "человек-человек". Но и для бизнеса тоже есть свои психотерапевты. Очень часто эту роль выполняет аналитик. Иногда в связке с финансистом или продактом. Именно аналитик задает правильные вопросы и переводит ощущения в факты.
В моем канале Аналитика FM я рассказываю про инструменты аналитика, про мышление и разбираю рабочий кейсы. Мы рассматриваем SQL и Python в применении к данным.
Этот канал я веду с нуля подписчиков.Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!
Бизнес, как и человек, редко приходит с чётким запросом.
Обычно это звучит так:
Продажи что-то просели
Маркетинг стал дорогим
Клиенты какие-то не такие
Кажется, мы зарабатываем, но денег нет
Это не диагноз. Это эмоции и тревога.
Бизнес чувствует, что всё плохо.
Аналитик проверяет:
где именно плохо,
с какого момента,
для каких сегментов,
и плохо ли вообще.
Иногда оказывается, что:
revenue растёт,
но падает маржа,
или растёт LTV, но сжирается CAC,
или прибыль есть, но кэшфлоу убит.
Аналитик возвращает контроль через структуру.
Пока нет цифр - есть хаос.
Появляются метрики → появляется язык, на котором бизнес может с собой разговаривать.
Аналитик:
договаривается, что считать,
как считать,
и зачем.
Это ровно как в терапии: сначала выстраивается общий словарь.
Аналитик помогает увидеть причинно-следственные связи.
Бизнес часто путает:
симптомы и причины,
решения и их последствия.
Аналитик показывает:
какие действия к чему привели,
где решение помогло, а где замаскировало проблему,
и что будет, если ничего не менять.
Не "плохо работает маркетинг",
а "вот где именно он перестал окупаться и почему".
Хороший аналитик не обвиняет.
Он говорит:
Это не ошибка команды
Это ограничение модели
Это следствие выбранной стратегии
Как психотерапевт - без осуждения, но честно.
Аналитик не решает за бизнес,
но делает так, чтобы решения принимались не на тревоге, а на понимании.
Аналитик - не спасатель и не волшебник.
Он не делает бизнес успешным.
Он делает бизнес осознанным.
А дальше - как в жизни:
осознанность не гарантирует счастья,
но резко повышает шансы перестать делать себе больно.
Поэтому, если отвечать на вопрос коротко:
психотерапевт для бизнеса - это аналитик, который умеет слушать цифры и переводить их на человеческий язык.
В моем канале Аналитика FM уже вышла серия постов про Revenue в разных бизнесах.
Как рассчитывается, где и какие есть особенности. Как пишутся запросы на SQL.Если тоже хочешь разобраться в нюансах подсчета выручки в разных бизнесах, то подписывайся.
Следующая серия постов будет про Retention.
Показать полностью
1
Revenue в разных бизнес кейсах и как его считать
Revenue часто переводят как "выручка" - и на этом понимание заканчивается.
Кажется логичным: если деньги пришли на счёт, значит бизнес заработал.
Но в реальности Revenue - это доход, который бизнес признал, а не просто получил.
Ключевое слово здесь - признал.
То есть ответ на вопрос не "когда заплатили", а когда бизнес считает, что он действительно заработал эти деньги.
И вот тут начинаются нюансы.
Кстати, в моём канале Аналитика FM уже есть примеры SQL-запросов для расчёта Revenue в разных бизнес-моделях. Ниже как раз объяснение, почему этих вариантов так много.
Присоединяйся!
В классическом виде Revenue:
Revenue = количество × цена
Или:
сумма чеков
сумма оплаченных заказов
сумма выставленных счетов
Это работает ровно до тех пор, пока бизнес простой.
Но как только появляются:
подписки
рассрочки
комиссии
возвраты
отложенные услуги
формула "сумма денег" перестаёт отражать реальность.
Пример: клиент оплатил год обучения сразу.
Но по договору он может расторгнуть его и вернуть часть денег.
Если считать Revenue как "всё, что оплатили", то при возврате показатели будут прыгать - и бизнес будет принимать решения на искажённой картине.
Как по-разному считается Revenue в разных бизнесах
1️⃣ Транзакционные офлайн-бизнесы
(кафе, рестораны, услуги)
Здесь всё относительно честно и просто:
Revenue = сумма оплаченных чеков
возвраты не входят
дата Revenue = дата покупки
Заплатили → заработали.
2️⃣ Подписочные и онлайн-продукты
(SaaS, онлайн-образование)
Здесь деньги и доход - разные сущности.
деньги могут прийти сразу
Revenue признаётся равномерно во времени
payment ≠ revenue
Если подписка действует 3 месяца, то и доход "размазывается" по этим 3 месяцам - независимо от того, когда пришла оплата.
Поэтому:
смотрят не на платёж
считают строго по периоду оказания услуги
На практике для этого делают отдельную таблицу начислений, а не пересчитывают всё каждый раз.
3️⃣ Финансы и страхование
В финтехе деньги почти никогда не означают доход «сегодня».
кредит выдали сегодня
доход зарабатывается постепенно
Revenue считается на даты начислений
Причём Revenue может:
пересчитываться задним числом
меняться из-за досрочного погашения
корректироваться из-за каникул, судов, ошибок
Здесь Revenue отвечает на вопрос:
"Когда мы реально заработали?",
а не "когда приняли решение выдать кредит".
4️⃣ Розница и FMCG
Фокус не на клиенте, а на товаре.
Revenue = количество × цена
считается по SKU, магазинам, регионам
аналитика чаще товарная, чем клиентская
Кто купил - вторично. Главное - что и где продали.
5️⃣ Маркетплейсы и платформы
Самый частый источник ошибок.
Клиент платит много, но:
эти деньги не принадлежат платформе
платформа - посредник
Поэтому:
order_amount ≠ revenue
Revenue = комиссия + сервисные сборы
Платформа не владеет товаром и не несёт товарные риски.
Она зарабатывает на услуге, а не на продаже.
6️⃣ Проектные и экспертные бизнесы
Здесь нет логики "продал → отгрузил → забыл".
Работа делается этапами.
Каждый этап:
закрыт
принят заказчиком
имеет согласованную стоимость
Revenue признаётся по факту выполненной работы, а не по оплате.
Это не прихоть аналитиков, а:
бухгалтерский принцип
управленческий принцип
часто юридическое требование
Главное, что важно запомнить
Revenue — это всегда:
про модель бизнеса
про правила признания
про момент, когда бизнес считает, что заработал
Одна и та же формула в разных компаниях может означать совершенно разные вещи.
И именно поэтому нельзя просто взять "SUM(amount)" и успокоиться.
Если хочешь посмотреть, как это выглядит в реальных SQL-запросах -
в канале Аналитика FM я уже разбираю расчёт Revenue для разных бизнесов:
подписки, финансы, маркетплейсы и проектные модели.
Без магии - только логика и данные.Подписывайся!
Показать полностью
1
Метрики и их смыслы в разных бизнесах
Очень часто к аналитику приходят с запросом
Давайте посчитаем стандартные метрики
У меня в этот момент всегда возникает вопрос:
А стандартные - это какие?
ИЛИ
Стандартные для кого?
Могут ли стандартные метрики быть одинаковыми для разных категорий бизнеса?
Об этом чуть ниже.
А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков. В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках. Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!
Формула для метрик может выглядеть одинаково.
Но смысл метрики почти всегда зависит от бизнеса.
Возьмём простую вещь - Revenue (выручка).
Для интернет-магазина это деньги за заказы.
Для подписочного сервиса - выручка за период, иногда с учётом отложенных платежей.
Для маркетплейса - комиссия, а не сумма всех продаж.
Для финтеха - вообще может быть не тем, что платит клиент, а тем, что остаётся компании после всех операций.
Формально везде можно написать:
SUM(amount)
Но то, что именно лежит в amount, решает всё.
То же самое с конверсией.
В одном бизнесе конверсия - это "визит → покупка".
В другом — "регистрация → первый платёж".
В третьем — "лид → контракт через 3 месяца".
Цифра одна.
Слово одно.
А управленческие решения - совершенно разные.
Поэтому метрики не бывают универсальными.
Универсальными бывают названия, а не смыслы.
И именно здесь аналитика перестаёт быть "про формулы" и становится "про понимание бизнеса".
Одинаковая метрика в разных компаниях - это как одно и то же слово в разных языках.
Вроде знакомо, но если не знаешь контекста - легко ошибиться.
Кстати, в моём телеграм-канале Аналитика FM я как раз разбираю Revenue:
что под ним реально считают бизнесы и где чаще всего начинаются ошибки.
Если интересно копать глубже - буду рада видеть.
Показать полностью
1
Клиентские метрики без user_id
Большая часть клиентской аналитики опирается на user_id - идентификатор клиента.
Пользователь → действия → история → повторные визиты → поведение во времени.
И когда user_id нет, ломается не написание SQL-запроса - ломается логика вопросов, которые вообще можно задавать данным.
В своем канале Аналитика FM начала серию постов про метрики в разных бизнесах.
Являются ли эти метрики или формулы их вычисления универсальными для разных бизнес направлений.Об этом и об аналитике в целом рассказываю у себя в канале.
Канал веду с нуля подписчиков.
Присоединяйся, если хочешь разобраться в SQL, python и мышлении аналитика.
Одна из самых неприятных фраз, которую аналитик может услышать в начале проекта:
user_id у нас нет
Есть метрики, которые принципиально живут без пользователя.
- Выручка за день.
- Количество заказов.
- Средний чек.
- Сумма транзакций по категориям.
Это агрегаты "по событиям".
Им не важно, кто именно сделал действие - важно, что действие произошло.
Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.
Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".
- Повторные покупки.
- Возвраты клиентов.
- LTV.
- Retention.
- Конверсия по шагам воронки.
Все эти метрики - не про события.
Они про людей.
А без user_id "человек" в данных перестаёт существовать.
И когда user_id отсутствует, бизнес начинает выкручиваться.
Вместо user_id появляются:
номер телефона
email
cookie
device_id
хэш паспорта
комбинации из "телефон + дата рождения + регион"
Это не плохие решения.
Это компромиссы.
Каждый такой "заменитель пользователя" решает одну задачу и ломает другую.
Телефон:
- отлично для CRM
- плохо для веба и офлайна
Cookie:
- хорошо для сессий
- бесполезно для долгой аналитики
Email:
- стабилен
- но есть одноразовые email-ы
Device_id:
- у клиента может быть несколько устройств
- может жить до переустановки приложения
- может стоять запрет на трекинг
В итоге бизнес не считает "пользователей".
Он считает версии пользователей.
Из-за этого появляются странные эффекты:
пользователей стало больше, но денег больше не стало
retention упал, но продажи выросли
конверсия пляшет, а поведение вроде то же
И это не всегда ошибка данных.
Это ограничение идентификации.
Важно понимать:
отсутствие user_id - это не техническая проблема, а продуктовая.
Она говорит о том, как система была спроектирована изначально:
думали ли о пользователе как о сущности
или думали только о событиях и операциях
Поэтому аналитика без user_id возможна.
Но она всегда:
менее точная
более приближённая
и требует аккуратной интерпретации
Хуже всего - считать "пользовательские" метрики и делать вид, что всё ок.
Лучше честно сказать:
Мы считаем это так, потому что другого способа у нас нет
Данные могут существовать без user_id.
Запросы SQL может работать без user_id.
Отчёты можно построить без user_id.
Но аналитика поведения - нет.
НО... Главный НО...
Наличие user_id не спасет вас от того, что клиента "на входе" не идентифицировали и завели ему новый идентификатор. Либо при объединении клиентских баз у вас не задвоится один и тот же клиент.
Это повседневные процессы бизнеса. И уникальность клиента зависит от культуры ведения данных в базе, от технических процессов и бизнес процессов.
Для дедупликации клиентских записей существуют системы класса CDI (Customer Data Integration). Такие системы помогают идентифицировать клиента и вести его мастер карточку.
Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!
Показать полностью
Ответ на пост «Про KPI»1
"если что-то нельзя проверить экспериментом (или измерением), оно вообще не достойно обсуждения"
Тут надо правильно понимать или, скорее всего, правильно сформулировать перевод.
Есть разница между "невозможно обнаружить/измерить экспериментом" и "мы пока не умеем это измерять".
Т.е. в первом случае фактор не существует нигде, кроме нашего воображения. Например, толпа ангелов на острие иглы. Или чайник Рассела.
Во втором случае фактор реально существует, экспериментально обнаружить его можно. Например, боевой настрой бойца.
Любой полководец знает (и многие пишут - в т.ч. Наполеон и Суворов) о важности боевого духа солдат. Измерить этот "боевой дух" мы толком не умеем.
Тем не менее мы хорошо знаем, что такой фактор существует, и исход боя от него зависит. Это можно проверить экспериментально. (Да вы сами видели, что решительный коротышка может навалять трусливому амбалу.)
Только вот измерять не умеем. Ну, художественно можно описать такие степени: дрожит как осиновый лист - боится - все пофиг - зол - готов всех порвать, но это очень грубо и не объективно.
И поэтому не измеряем.
С точки зрения теории эксперимента и мат. статистики это означает, что мы берем некий фактор и перестаем его учитывать, объявляя связанные с ним колебания случайной величиной.
Т.е. при одном и том же количестве солдат, при одинаковом их вооружении - в одном случае получаем боеспособный взвод, в другом - небоеспособный, в третьем - слабо боеспособный, и такие типа не знаем, отчего это зависит. А то, что первый взвод набрали из мужиков, привыкших каждый день драться за ресурс, еду, женщину и т.д., второй - наловили бомжей по помойкам, а третий - из студентов, отчисленных за двойки - ну, это мы не учли. Патамушта в амириканской гумажке нет такой графы. А графы нет, патамушта измерить не можем.
Показать полностью