Друзья, это финальный пост про пирамиду метрик.

Я довольно много писал про метрики и разные фреймворки, и к пирамиде мы возвращались не раз. Но с последним слоем я немного подзатянул - исправляюсь 🙂

На последнем уровне - интерфейс продукта и маркетинг - находятся самые прикладные метрики. Те, с которыми команды работают каждый день и которые напрямую отражают поведение пользователей.

Этот слой отвечает на базовые вопросы:
- как пользователи приходят в продукт?
- что они в нем делают?
- доходят ли до целевого действия?

Как и в предыдущих слоях, здесь есть своя логика группировки. Я выделяю четыре блока:

1. Маркетинг
Это про вход в продукт: кого мы приводим и за какие деньги.

2. Интерфейс
Это уже про UX и то, насколько продукт понятен.

3. Вовлеченность
Здесь видно, «цепляет» продукт или нет.

4. Аудитория
Это наша текущая и потенциальная база.

Этот слой - точка, где формируется все поведение пользователя: как он зашел, что сделал, получил ли пользу. А дальше поднимается выше по пирамиде - в ценность, лояльность и деньги.

На этом мы полностью разобрали пирамиду метрик - от бизнес-уровня до конкретных действий пользователя.

Главное не фреймворк, а используете ли вы его на практике. Будь то пирамида, дерево метрик или что-то свое - важно, чтобы метрики были системой, а не набором цифр.

#харды #метрики #разбор_метрик

Как написать стратегию аналитики и зачем она нужна?

Ура, я наконец-то закончил эту статью! Писал ее долго, потому что хотел сделать по-настоящему крутой гайд, в который вложил много сил. И теперь с радостью делюсь с вами.

Эта статья для тех, кто недавно стал тимлидом или хедом аналитики и чувствует, что пора выйти из режима «просто делаем задачи» и начать думать системно.

Перед тем, как ее опубликовать, я искал подобные материалы и не нашел ничего достойного на русском языке. Есть пересказы Gartner, есть руководства от вендоров уровня «нужно делать data-driven», есть какие-то корпоративные посты. Поэтому статья - попытка закрыть реальный пробел.

В ней вы найдете практическое руководство: как вывести стратегию аналитики из бизнес-целей, честно оценить зрелость команды, пройти три фазы развития и собрать дорожную карту. Это выжимка из моего опыта, с конкретными шагами. Приятного чтения.

#опыт

На русском языке о стратегии построения аналитической команды нет почти ничего. Буквально несколько статей, одна из которых моя. Тем ценнее handbook, продолжающий эту тему и превращающий разрозненные наблюдения в пошаговую систему.

📚 From Data to Insights. The strategy of a Data Analytics Team
John Mackay

Джон начинал инженером данных, вырос до руководителя аналитики в крупном европейском банке, а сейчас управляет data-аналитикой в ведущей технологической компании и консультирует Fortune 500. За два десятка лет он построил не одну команду, которая возвращала бизнесу миллионы и делала процессы заметно человечнее. Свой опыт он упаковал в короткое прикладное руководство.

Каркас книги - четыре обязательных элемента любой аналитической функции: команда, данные, стейкхолдеры и отчетность. Автор проведет вас от хаоса первых дней до внятной долгосрочной стратегии.

Вот семь типовых симптомов, знакомых почти каждой команде аналитики:

▪️Завал ad-hoc запросами.
▪️Репутация подорвана и вам не доверяют.
▪️На анализ и инсайты времени нет.
▪️Срочные задачи прилетают в последний момент.
▪️Отчеты разрозненные, пользоваться ими больно.
▪️Коллеги выгорели и потеряли драйв.
▪️Стейкхолдеры вынуждены делать отчеты сами.

Причина, по Маккею, одна - слабая стратегия и плохой дизайн команды. Книга ровно про то, как это исправить. Пригодится и CTO, и тимлидам, и рядовым аналитикам - чтобы понимать, как устроен здоровый data‑организм и в какой момент все пошло не так.

🔗 Электронную версию на английском в PDF качайте по ссылке.

#книга

Обновил телеграм-курс по метрикам

Уже несколько лет я разбираю метрики в канале: фреймворки, книги, разные подходы. Постепенно из этих постов сложилась система, в которой видно, как метрика с более низкого уровня дотягивается до чистой прибыли.

К новому учебному году собрал все опубликованные ранее материалы в один список и дополнил его. Появился пост про экосистемную аналитику и подход к измерению бизнеса, когда продуктов несколько и у них общий пользователь. А также целая серия постов про LTV и CAC.

Читать лучше последовательно, разделы опираются друг на друга.

База
▪️ Что такое метрика?
▪️ Фреймворки для работы с метриками

Целеполагание
▪️ Цели и ключевые результаты (OKR)
▪️ Книга.Измеряйте самое важное

NSM
▪️ Метрика Полярной звезды (NSM)
▪️ Почему Revenue и Profit плохие кандидаты в NSM
▪️ Книга.The North Star Playbook

Иерархия и пирамида
▪️ Дерево или иерархия метрик
▪️ Пирамида метрик
▪️ Построение пирамиды метрик
▪️ Слой бизнеса
▪️ От GMV к Net Profit
▪️ Слой маржинальности
▪️ Юнит-экономика
▪️ Слой продукта. Метрики лояльности
▪️ Слой продукта. Метрики ценности
▪️ Слой продукта. Метрики качества
▪️ Слой интерфейса и маркетинга
▪️ Экосистемные метрики

Опыт Amazon
▪️ Опережающие и запаздывающие индикаторы
▪️ Маховик Amazon
▪ Книга.Стратегия Amazon

Для конкретной задачи
▪️ Фреймворк AARRR
▪ Фреймворк HEART
▪️ Фреймворк PULSE

Подробно про LTV и CAC
▪️ Простой способ расчета LTV
▪️ LTV с учетом маржи и дисконтирования
▪️ Когортный LTV
▪️ Сравнение подходов
▪️ Customer Acquisition Cost
▪️ Что делать, когда показатели посчитаны

Все бесплатно. Сохраняйте в закладки и делитесь с коллегами.

#метрики

День знаний, или Я все еще студент

Лето опять пролетело подозрительно быстро. Я не успел накачаться, съездить на море и как следует отдохнуть. Впрочем, сегодня другой повод удивиться - начинается второй год моего обучения в магистратуре МИФИ на программе «Специалист по работе с данными и применению ИИ».

Первый год оказался очень сложным. Совмещать учебу, работу на руководящей должности и семью в зрелом возрасте было не просто смело, это было пи🤬ец как смело. Иногда ничего не успевал, иногда просто сжимал зубы и продолжал. Но раз пишу этот пост, значит меня не отчислили. И это я правда считаю большим личным достижением)

За год прошел Python, Linux, основы Data Science, бизнес- и системную аналитику. Где-то освежил знакомое, где-то наконец собрал тот самый технический фундамент, ради которого и поступал.

Далее нужно было выбрать специализацию. Я выбрал дата-инженерию, ведь людям, которые копают золото, всегда нужны продавцы лопат. Плюс этот трек соответствует моему карьерному плану стать CDO. К тому же, он показался мне немного легче чисто математических специализаций.

Впереди хранилища, качество и подготовка данных, потоковая обработка, озёра и облака. Потом ВКР. А там свобода, причем уже с дипломом магистра!

С возрастом учеба воспринимается иначе - ты хорошо понимаешь, зачем тратишь на нее вечера и выходные. В нашей сфере надолго останавливаться опасно, профессия быстро убежит вперед без тебя.

Всех с Днем знаний!

Поделитесь, а вы в этом году куда-нибудь поступили, чему-то учитесь? Или уже умеете?)

#личное

Продукты 24

12 сентября в Москве Т-Банк собирает конференцию Продукты 24 x ffdd2d в комплексе «Мечта» на набережной парка Горького. Можно смотреть онлайн, но лучше приходите лично.

Сама конфа для продактов, аналитиков и дизайнеров. Кроме Т-Банка со своими кейсами приедут Яндекс, Авито и Додо Пицца.

Три зала на разные темы, и один из них, «Говорим прямо», идет без трансляции и записи. В нем обсуждают спорные темы и решения, отвечают на неудобные вопросы, рассказывают о провалах и неожиданных победах. В общем все то, о чем обычно не говорят публично.

А вечером стендап и вечеринка с видом на Москву-реку.

Выступать будут мои коллеги и друзья, народ крутой, так что за программу я спокоен.

Я тоже там буду, подходите знакомиться, поболтаем про метрики и про то, как у кого устроена аналитика.

Мест на площадке немного, лучше не тянуть с регистрацией.

В таком стильном лонгсливе на прошедшей конференции «Продукты 24» я отвечал за экспертную зону, связанную с ИИ. Ко мне можно было записаться, а дальше все собирались за одним столом, тянули карточку и обсуждали тему. Я модерировал дискуссию. У нас был следующий набор карточек:

▪ не знаю, как встроить AI в свой продукт;
▪ AI быстро меняет мою профессию, не знаю, чему учиться;
▪ команда хочет AI-фичу ради тренда;
▪ хочу понять, что в моей работе отдать AI.

Согласитесь, актуалочка)

Самую жаркую дискуссию вызвала тема про внедрение ИИ ради внедрения. Вы наверняка слышали много кейсов, когда руководство хочет идти за трендами и говорит: все, завтра внедряем ИИ, без понимания того, как это работает, какие есть ограничения и последствия. А может, даже слышали о том, как сокращаются целые отделы в угоду этому тренду (например, разработки или тестирования).

В итоге мы все вместе решили, что перегибы, к сожалению, возможны. Чтобы с ними бороться, нужно понять, какую проблему мы решаем, придумать метрики и замерить их, а также посчитать экономику, потому что порой стоимость токенов и ошибок может быть сопоставима со стоимостью работы человека. И всегда надо идти через пилот и не делать резких движений. Но в целом в некоторых сферах ИИ действительно очень ускоряет работу и заменяет человека.

Второй кейс, который мне понравился, как раз на эту тему. Была девочка-продакт из небольшого стартапа, у которой вообще не было аналитиков, а с данными работать нужно: делать отчеты, выгрузки и считать метрики.

Так вот, она очень классно закрыла свою боль тем, что делегировала агенту такие простые и повторяющиеся задачи, как выгрузки. Не помню, это был Клод или Курсор, но факт в том, что она написала несколько скиллов и нашла MCP-шки по работе с базой данных и научила агента выполнять простые эдхоки, что полностью покрыло ее запрос. По ее отзывам, сейчас агент может справляться с работой аналитика на уровне джуна или даже джуна+.

В общем, мне понравилось. Не жалею, что сходил, и даже удалось послушать несколько докладов. Если вы тоже хотите послушать и посмотреть, то вот ссылки на записи из залов «Достигаем результатов»  и «Ломаем шаблоны».

Тем временем готовлю серию постов про базу ИИ. Но это ни в коем случае не означает, что я перестану писать про аналитику)

#мысли

Как работают языковые модели?

Когда я изучал программирование, то нас учили простому правилу. Функция при одних и тех же входных данных возвращает один и тот же результат. Два плюс два всегда равно четыре. Это называется детерминированность.

Языковая модель работает по-другому. Она вероятностная, поэтому при одинаковых входных данных может пойти разными путями. Но как модель выбирает путь, по которому пойти?

Под капотом она предсказывает следующий фрагмент текста (токен) на основе двух факторов:

▪️Информации, на которой модель была обучена;
▪️Того, что вы передаете ей на вход (промпта).

Далее на каждом шаге она оценивает, насколько вероятен каждый следующий токен. Более вероятные она выбирает чаще, но может выбрать и менее вероятные. Угадала кусок, показала его на экране и уже от него угадывает следующий. Вы можете наблюдать за этим процессом при диалоге в чате, когда печатается ответ, как будто его при вас набирает живой человек. Каждый выбранный токен меняет вероятности для следующего. Поэтому один и тот же вопрос, заданный дважды, может дать два разных ответа.

Теперь давайте разберемся с тем, что такое токен. Токен - это не слово. Иногда это действительно целое слово, но чаще лишь часть слова, знак или пробел.

На английском 1 токен занимает примерно 4 символа, сто токенов - около 75 слов. В русском иначе - 1 токен занимает 2-3 символа, сто токенов это 30-40 слов. Одна и та же мысль на русском часто тратит в 1.5-2 раза больше токенов.

Почему так происходит? Токенайзер собирает словарь из самых частых кусков в данных, на которых модель учили. Чем чаще последовательность встречалась, тем выше шанс, что она станет одним токеном. Английского в обучающих данных было гораздо больше, поэтому целые английские слова часто лежат в словаре одним куском. Русский исторически дробился сильнее, иногда до отдельных букв. Сейчас ситуация стала лучше, но русское слово все равно чаще режется на 2-4 токена, английское на 1-2.

На практике это влияет на стоимость, поэтому один и тот же запрос на русском выходит дороже, и в лимит модели русского текста влезает гораздо меньше, а значит, долгий диалог упирается в потолок раньше.

Можете проверить сами: вставьте одну и ту же фразу по-русски и по-английски в любой токенайзер и сравните счетчик.

С базой вроде разобрались. Теперь, если модель на один и тот же вопрос ответит по-разному, вы знаете почему.

#эйяй

Как правильно вайбкодить?

Недавно я писал, что пошел учиться и изучаю вайбкодинг. А также обещал делиться инсайтами по мере обучения, но факт в том, что каких-то секретных инсайтов как таковых нет. Однако есть простые правила взаимодействия с агентом, предохраняющие вас от печальных последствий в дальнейшем. Про это сегодня и поговорим.

Как чаще всего мы общаемся с агентом? Открываем приложение под определенным брендом и пишем, что хотим получить на выходе: бота, ассистента, сайт или целый сервис. Ну и дальше агент начинает кодить, запрашивать разные токены, иногда даже пушить в Git, и на выходе получается что-то работающее. Чаще всего нас это даже устраивает.

Но проблема в том, что получившийся результат - ненадежная поделка, неустойчивая, немасштабируемая и опасная в плане инфобеза.

Чтобы так не было, ниже несколько лайфхаков, как правильно организовать работу:

0️⃣ Начните с описания проекта. Это своеобразный манифест про ваше приложение, правила работы, технологии, сервер, тестирование. То есть некая отправная точка, которую любой агент считывает при начале работы. Обычно такой файл называется AGENTS.md.

1️⃣ Прежде чем делать фичу, напишите спецификацию. На ее основе создаются план работы и тесты, и с ней же агент сверяется, чтобы ничего не поломать при расширении функционала.

2️⃣ Всегда используйте Plan Mode. В этом режиме агент не бросается делать фичу сразу, сначала он рассуждает, задает вопросы, советуется, и на выходе получается план, который вы согласовываете. По нему и ведется разработка.

3️⃣ Сначала пишутся тесты, потом код. На основе спеки просим агента написать автотесты, чтобы проверять функционал. Да, именно в таком порядке - сначала тест, после него реализация. У агента должно быть правило перед любым релизом всегда запускать тесты.

4️⃣ Берегите секреты. Токены и ключи храните в файле .env, а сам .env добавьте в .gitignore, чтобы он не улетел в Git. Никогда не вставляйте их в чат и не давайте агенту доступ к проду. А если ключ уже попал в репозиторий, перевыпустите его, удаления файла недостаточно, так как он останется в истории вашей переписки и коммитов.

5️⃣ Храните код в Git. Код вашего детища обязательно должен жить в Гите - разработали фичу, прогнали через тесты, коммит и пуш. Так у вас всегда будет история изменений, и если агент что-то сломает, можно вернуться к рабочей версии.

В итоге у вас получится своеобразный конвейер:

➡️ спека,
➡️ план,
➡️ тесты,
➡️ код,
➡️ пуш,
🔄 повторить.

Его можно настроить самостоятельно, просто объяснив агенту, что вы хотите и попросив запомнить. Но благо умные люди уже выложили эти правила в виде готовых скиллов или даже целых фреймворков, например таких как Superpowers.

Агент сильно ускоряет разработку, но скорость без правил дает ту самую поделку. Использование конвеера фичи превращает ее в надежное приложение, которое можно развивать, не боясь что-то сломать.

#эйяй