Главная метрика в ИТ
Источник: «Жиза ИТ руководителя»
Источник: «Жиза ИТ руководителя»
Недавно я получила комментарий к одному из моих постов, что "хороший аналитик" - это как психотерапевт для бизнеса!
Я полностью согласна с этим!
Психотерапия - это курс регулярных встреч, на которых врач с помощью специальных техник помогает пациенту понять причины его состояния, изменить деструктивные модели мышления и поведения, научиться справляться с трудностями и реагировать на стресс, а также развить навыки эмоциональной саморегуляции.
Так описывается взаимодействия "человек-человек". Но и для бизнеса тоже есть свои психотерапевты. Очень часто эту роль выполняет аналитик. Иногда в связке с финансистом или продактом. Именно аналитик задает правильные вопросы и переводит ощущения в факты.
В моем канале Аналитика FM я рассказываю про инструменты аналитика, про мышление и разбираю рабочий кейсы. Мы рассматриваем SQL и Python в применении к данным.
Этот канал я веду с нуля подписчиков.Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!
Бизнес, как и человек, редко приходит с чётким запросом.
Обычно это звучит так:
Продажи что-то просели
Маркетинг стал дорогим
Клиенты какие-то не такие
Кажется, мы зарабатываем, но денег нет
Это не диагноз. Это эмоции и тревога.
Бизнес чувствует, что всё плохо.
Аналитик проверяет:
где именно плохо,
с какого момента,
для каких сегментов,
и плохо ли вообще.
Иногда оказывается, что:
revenue растёт,
но падает маржа,
или растёт LTV, но сжирается CAC,
или прибыль есть, но кэшфлоу убит.
Аналитик возвращает контроль через структуру.
Пока нет цифр - есть хаос.
Появляются метрики → появляется язык, на котором бизнес может с собой разговаривать.
Аналитик:
договаривается, что считать,
как считать,
и зачем.
Это ровно как в терапии: сначала выстраивается общий словарь.
Аналитик помогает увидеть причинно-следственные связи.
Бизнес часто путает:
симптомы и причины,
решения и их последствия.
Аналитик показывает:
какие действия к чему привели,
где решение помогло, а где замаскировало проблему,
и что будет, если ничего не менять.
Не "плохо работает маркетинг",
а "вот где именно он перестал окупаться и почему".
Хороший аналитик не обвиняет.
Он говорит:
Это не ошибка команды
Это ограничение модели
Это следствие выбранной стратегии
Как психотерапевт - без осуждения, но честно.
Аналитик не решает за бизнес,
но делает так, чтобы решения принимались не на тревоге, а на понимании.
Аналитик - не спасатель и не волшебник.
Он не делает бизнес успешным.
Он делает бизнес осознанным.
А дальше - как в жизни:
осознанность не гарантирует счастья,
но резко повышает шансы перестать делать себе больно.
Поэтому, если отвечать на вопрос коротко:
психотерапевт для бизнеса - это аналитик, который умеет слушать цифры и переводить их на человеческий язык.
В моем канале Аналитика FM уже вышла серия постов про Revenue в разных бизнесах.
Как рассчитывается, где и какие есть особенности. Как пишутся запросы на SQL.Если тоже хочешь разобраться в нюансах подсчета выручки в разных бизнесах, то подписывайся.
Следующая серия постов будет про Retention.
Revenue часто переводят как "выручка" - и на этом понимание заканчивается.
Кажется логичным: если деньги пришли на счёт, значит бизнес заработал.
Но в реальности Revenue - это доход, который бизнес признал, а не просто получил.
Ключевое слово здесь - признал.
То есть ответ на вопрос не "когда заплатили", а когда бизнес считает, что он действительно заработал эти деньги.
И вот тут начинаются нюансы.
Кстати, в моём канале Аналитика FM уже есть примеры SQL-запросов для расчёта 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 для разных бизнесов:
подписки, финансы, маркетплейсы и проектные модели.
Без магии - только логика и данные.Подписывайся!
Очень часто к аналитику приходят с запросом
Давайте посчитаем стандартные метрики
У меня в этот момент всегда возникает вопрос:
А стандартные - это какие?
ИЛИ
Стандартные для кого?
Могут ли стандартные метрики быть одинаковыми для разных категорий бизнеса?
Об этом чуть ниже.
А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков. В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках. Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!
Формула для метрик может выглядеть одинаково.
Но смысл метрики почти всегда зависит от бизнеса.
Возьмём простую вещь - Revenue (выручка).
Для интернет-магазина это деньги за заказы.
Для подписочного сервиса - выручка за период, иногда с учётом отложенных платежей.
Для маркетплейса - комиссия, а не сумма всех продаж.
Для финтеха - вообще может быть не тем, что платит клиент, а тем, что остаётся компании после всех операций.
Формально везде можно написать:
SUM(amount)
Но то, что именно лежит в amount, решает всё.
То же самое с конверсией.
В одном бизнесе конверсия - это "визит → покупка".
В другом — "регистрация → первый платёж".
В третьем — "лид → контракт через 3 месяца".
Цифра одна.
Слово одно.
А управленческие решения - совершенно разные.
Поэтому метрики не бывают универсальными.
Универсальными бывают названия, а не смыслы.
И именно здесь аналитика перестаёт быть "про формулы" и становится "про понимание бизнеса".
Одинаковая метрика в разных компаниях - это как одно и то же слово в разных языках.
Вроде знакомо, но если не знаешь контекста - легко ошибиться.
Кстати, в моём телеграм-канале Аналитика FM я как раз разбираю Revenue:
что под ним реально считают бизнесы и где чаще всего начинаются ошибки.
Если интересно копать глубже - буду рада видеть.
Большая часть клиентской аналитики опирается на user_id - идентификатор клиента.
Пользователь → действия → история → повторные визиты → поведение во времени.
И когда user_id нет, ломается не написание SQL-запроса - ломается логика вопросов, которые вообще можно задавать данным.
В своем канале Аналитика FM начала серию постов про метрики в разных бизнесах.
Являются ли эти метрики или формулы их вычисления универсальными для разных бизнес направлений.Об этом и об аналитике в целом рассказываю у себя в канале.
Канал веду с нуля подписчиков.
Присоединяйся, если хочешь разобраться в SQL, python и мышлении аналитика.
Одна из самых неприятных фраз, которую аналитик может услышать в начале проекта:
user_id у нас нет
Есть метрики, которые принципиально живут без пользователя.
- Выручка за день.
- Количество заказов.
- Средний чек.
- Сумма транзакций по категориям.
Это агрегаты "по событиям".
Им не важно, кто именно сделал действие - важно, что действие произошло.
Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.
Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".
- Повторные покупки.
- Возвраты клиентов.
- LTV.
- Retention.
- Конверсия по шагам воронки.
Все эти метрики - не про события.
Они про людей.
А без user_id "человек" в данных перестаёт существовать.
И когда user_id отсутствует, бизнес начинает выкручиваться.
Вместо user_id появляются:
номер телефона
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. В английском есть такое понятие perverse incentive, «порочный стимул». Это когда пытаешься придушить зло, но методы превращаются для него в идеальное удобрение. На это есть «Когда мера становится целью, она перестает быть хорошей мерой» (Мэрилин Стратерн на основе Закона Гудхарта).
Классика жанра — «Эффект кобры». В колониальной Индии англичане решили сократить популяцию змей и назначили награду за каждую голову. План казался надёжным, как швейцарские часы, пока индийцы не начали разводить кобр на домашних фермах ради «урожая». Когда власти поняли, что их водят за нос, и отменили выплаты, фермеры просто выпустили бесполезных теперь змей на волю. В итоге кобр стало в разы больше, чем до начала программы
Похожим образом французы в Ханое боролись с крысами, выплачивая деньги за отрезанные хвосты. По городу стали бегать толпы бодрых, но бесхвостых крыс: вьетнамцы отрезали «валюту» и отпускали зверьков плодиться дальше, чтобы не лишиться стабильного дохода.
В 19 веке археологи, искавшие кости динозавров и древние окаменелости, платили местным жителям за каждую найденную деталь. В итоге находчивые копатели специально разбивали целые, бесценные скелеты на мелкие кусочки, чтобы сдать их по отдельности и заработать побольше. Наука рыдала, зато KPI по «количеству находок» зашкаливал. Аналогичная трагедия произошла со Свитками Мертвого моря: бедуины разрезали найденные свитки на мелкие части, чтобы продать каждый фрагмент отдельно.
В США эта болезнь ударила по инфраструктуре. Когда строили Трансконтинентальную железную дорогу, правительство платило компании Union Pacific субсидии за каждую проложенную милю. В Небраске вместо прямого маршрута инженеры в едином коррупционном порыве вычертили огромную петлю — Oxbow Route. Лишние 9 миль крюка не имели никакого смысла для логистики, но принесли строителям сотни тысяч долларов «из воздуха».
Но если «петля» в Небраске — это просто воровство, то ошибки министра обороны США Роберта Макнамары — это уже трагедия. Будучи фанатом цифр и математических моделей, он пытался управлять войной во Вьетнаме как конвейером Ford.
Когда генерал Эдвард Лэндсдейл робко заметил, что в формулах Макнамары нет переменной «чувства и воля вьетнамского народа», министр записал это карандашом в блокнот. А потом стёр. Он сказал, что если что-то нельзя измерить, значит, оно неважно. Главной метрикой стал body count (подсчёт убитых). Офицеры на местах, желая выслужиться, начали записывать в «враги» всех подряд, рисуя в Вашингтоне иллюзию скорой победы, пока реальная ситуация катилась в бездну.
В науке есть радикальный принцип, похожий на бритву Оккама — «Пылающий лазерный меч Ньютона» (также известный как «Бритва Алдера»). Его суть: если что-то нельзя проверить экспериментом (или измерением), оно вообще не достойно обсуждения.
Звучит здраво для физики, но в жизни это прямой путь к тому, что социолог Даниэль Янкелович назвал деградацией восприятия. Он описал это как спуск по четырём ступеням:
1. Сначала мы измеряем только то, что легко измерить.
2. Затем игнорируем то, что измерить трудно или что требует качественной оценки.
3. Третий шаг — мы решаем, что то, что нельзя измерить, не так уж и важно.
4. И финальный шаг — мы объявляем, что того, что нельзя измерить, на самом деле не существует.
И в этот момент мы становимся слепыми. Мы смотрим на мир через замочную скважину метрик, пока в комнате за дверью разводят кобр, ломают кости динозавров и проигрывают войны.
Не мое, но очень беспокоит и надеюсь с этим буду сталкиваться как можно меньше.
Из комментариев, мне понравилось:
Про метрики Джеф Безос хорошо сформулировал. Любая метрика содержит некоторые допущения которые держал в голове автор метрики. А поэтому:
- метрика должна быть краткосрочной (пока допущения актуальны, а автор доступен)
- эффективнее сравнивать разницу между двумя положениями, а не оценивать абсолютные значения.
- если метрика противоречит наблюдениям, метрику надо менять. Удачная метрика получается не сразу, а через несколько итераций.
При правильном использовании, хороший инструмент который позволяет делегировать принятие тактических решений вниз, сохранив наверху контроль за общим направлением. И измеримые результаты сразу, а не в конце квартала.
Очень интересует обратная связь от владельцев сайтов по данным метрики от Яндекса. На скринах видно процентное соотношение того, сколько визитов на мой сайт идёт из Яндекса и Google. Хочется понять, насколько эта картина соответствует вашим показателям, может, у вас обратная ситуация?
Тот же вопрос относится и к браузерам, которыми пользуются пользователи. Хочется понять, какой расклад у вас, чтобы сделать определённые выводы. Заодно обменяемся опытом и проясним ситуацию.