Конференции — нужны ли они?

80% контента на конференциях — это, уж простите, вода. Красивые слайды, громкие слова и кейсы, которых спикер в жизни не делал. Главное — произвести впечатление, а не поделиться опытом. Вот и получается: ты пришёл за мясом, а получил соевый заменитель.

Я был на десятках конф и чаще всего уходил с ощущением: «ну ок». Много слов, мало сути. Маркетинг поверх контента.

Но не всегда так. Бывают и бриллианты — когда человек, который реально что-то делал, проваливался, вытаскивал, и не боится об этом говорить. Такие выступления — как глоток воды в пустыне. Жаль, редко.

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

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

Ради контента — не хожу. А вот свою команду — отправляю. Для них это часто полезно: посмотреть, что есть за пределами команды, набрать идей, получить заряд. И как формат поощрения — тоже норм.

А как вы относитесь к конференциям?

#мысли

Ждали майские статьи? Так они уже в ленте. Сегодня разбираемся с базами данных, изучаем очередное применение LLM и анализируем аргументы в пользу data-driven.

Начнем с баз. Вы задавались вопросом, нафига столько разных хранилищ? Как будто хватит и одной многофункциональной, чтобы хранить данные и обращаться к ним (на рынке такие есть). Давно хотелось найти источник, который бы дал классификацию баз и подсказал, какую следует использовать в конкретном случае. И недавно мне попалась такая статья на Medium (VPN) от дата-инженера Кая Перри-Джонса. Он выделил девять типов баз данных, дал основную характеристику каждого типа, привел примеры продуктов и высказал мнение, для каких задач они подходят. Но несмотря на обилие вариантов, универсальным хранилищем остается PostgreSQL.

Вторая статья пришла из Хабра. Виталий Кулиев, Data Science Tech Lead из Wildberries & Russ, поделился интересным вариантом матчинга товаров с помощью больших языковых (LLM) и визуально-языковых (VLM) моделей. Матчинг — это поиск идентичных товаров. Благодаря ему пользователи маркетплейсов не утонули в сотнях дубликатах от разных продавцов. Команда внедрила LLM на этапах извлечения и сравнения атрибутов и подключила VLM к матчингу по изображениям. В результате увеличилась точность распознавания товаров до 92–96%, а количество примеров для подбора промта снизилось до сотни в разметке.

Завершает список статья-эссе на тему, почему важно внедрять data-driven подход при построении бизнеса, от руководителя направления в KION Алексея Жирякова, евангелиста data-driven. С его точки зрения, это не просто тренд, а способ делать бизнес эффективнее благодаря точному прогнозированию, оптимизации процессов и пониманию потребностей клиентов. Алексей рассказывает, как устроен data-driven подход в KION, где все продуктовые фичи идут в прод только через A/B-эксперименты, и приводит примеры из практики Netflix, Starbucks и отечественного финтеха. Читать интересно, аргументы убедительные.

#дайджест

С чего начинается хорошая аналитика?

В прошлом посте я рассказывал, почему без EDA нельзя делать ни аналитику, ни машинное обучение. Даже если продакт стоит над душой и требует цифры «ещё вчера». Теперь давай разберём первый и самый недооценённый шаг в исследовательском анализе: осмотр данных.

Представь, что ты лезешь в базу и... сразу пишешь groupby() или строишь график? Это ловушка. Начинать нужно не с расчётов, а с банального знакомства с тем, что у тебя вообще в руках. Осмотр данных — это как включить свет в темной комнате. Сразу видно, где пыльно, а где стоит тумбочка, об которую легко споткнуться.

Первым делом смотри на объем данных: df.shape покажет, сколько строк и колонок. Иногда там вообще пара десятков строк — и это уже повод позвать дата-инженера.
Дальше — названия колонок. Через df.columns можно заметить лишние пробелы, странные символы, дубли названий. Здесь же удобно сразу стандартизировать названия: убрать русские слова и привести к единому стилю ("snake_case" ван лав). Такие вещи не бросаются в глаза, но потом ломают пайплайн.

Теперь — в бой идет df.info(). Это твой лучший друг. Он покажет:

▪️какие типы данных у колонок,
▪️сколько ненулевых значений,
▪️сколько памяти жрёт датафрейм.

Обрати внимание: если в колонке написано, что у неё 80 000 непустых значений, а в df.shape[0] у тебя 100 000 — значит, 20% пропусков. Это серьёзно.
Ещё один лайфхак: если колонка выглядит пустой, но info() говорит, что там всё заполнено — проверь, не строки ли там вроде " " или "None". Это визуальные, а не настоящие пропуски. Так что df.replace() тебе в помощь.

Если всё типы данных соответствуют ожиданиям — отлично. Если нет — можно наткнуться на неприятности. Например, object вместо чисел или дат — и ты не сможешь нормально группировать, фильтровать, делить на категории. В таких случаях сразу меняй тип или уточняй источник.

Следом подключай df.describe(). Это быстрый способ понять, как «живут» числовые данные. Сравни среднее и медиану — это может подсветить асимметричное распределение. Проверь минимум и максимум — там часто сидят выбросы или ошибки: отрицательные значения там, где их быть не должно, нули в колонке с деньгами, тысячи категорий у рейтинга от 1 до 5.

Дополнительно пригодится .nunique(): иногда колонка кажется категориальной, а там каждый второй элемент уникален. Это уже почти ID, и скорее всего — не то, что ты хотел анализировать.

И не забывай смотреть глазами. df.head(), df.tail() — быстрый способ поймать неявные проблемы. Например, даты, которые лежат строками. Или списки внутри ячеек. Или дубли с разницей в один символ. В табличке может быть много неожиданного — особенно если её собирали в два этапа, три человека, а выгружал четвёртый.

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

В следующем посте поговорим про пропуски и дубликаты. Ставь лайк, если тема интересна.

#eda

Если бездумно обобщить данные из разных групп, то можно наткнуться на парадокс Симпсона или «парадокс объединения». Это ситуация, когда тенденция, наблюдаемая в нескольких группах данных, исчезает или меняется на противоположную при объединении этих групп. В итоге общий результат противоречит результатам в подгруппах из-за разного влияния неучтенных скрытых переменных.

Парадокс был упомянут Карлом Пирсоном в 1899 году и Удни Юлом в 1903 году, но Эдвард Симпсон был первым, кто описал его с точки зрения статистики в 1951 году. Позже математик Колин Блайт в статье «On Simpson’s Paradox and the Sure-Thing Principle» увековечил имя статистика, введя термин в обращение. Под постом я прикрепил пару статистических статей для любителей копнуть поглубже.

Загвоздка с парадоксами всегда в том, что никогда не знаешь, где наткнешься на них. Например, посмотрим на статистику выживших при крушении Титаника среди пассажиров третьего класса и членов экипажа. Если анализировать общее количество выживших (верхняя таблица на картинке), то их процент в обеих группах будет около 24%. Кажется, обе категории пассажиров имели одинаковые шансы спастись.

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

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

Парадокс Симпсона напоминает нам, как важно проводить анализ как объединенных данных, так и отдельных групп. Не стоит делать выводы по выборочным показателям, если на ключевую метрику влияют несколько факторов. Понимание парадокса убережет от неверных выводов, в том числе при A/B-тестировании.

#аномалии

Что там с ИИ-грамотностью?

Когда из каждого утюга кричат об искусственном интеллекте, мнение части IT-специалистов цепляет внимание. Я говорю об ИИ-нигилистах, которые принципиально не используют ИИ-чаты, считая, что они поощряют лень. Позиция крайне радикальная, и подсознательно хочется возразить: «А как же автоматизация рутинных задач, например, написание рабочих текстов?»

Другая крайность удивляет не меньше. Некоторые люди настолько поверили в ИИ, что перестали вникать в задачи. Такие ребята приходят на собеседование по лайв-кодингу, без стеснения открывают ChatGPT и спрашивают ответы у чата. Они не пытаются разобраться в проблеме, не знают синтаксиса и не хотят думать.

Истина, видимо, посередине двух крайностей. ИИ активно внедряется в мире. Навык работы с ним — один из самых востребованных на рынке. Ряд компаний отмечает рост ROI и Revenue после внедрения ИИ, тогда как другие ожидают такого же эффекта в ближайшие годы. ИИ-компетенция становится базовой для дата-аналитиков и продуктовых менеджеров, как Excel, Python или SQL. Без понимания работы ИИ мы рискуем лишиться карьерных перспектив.

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

ИИ-грамотность не сводится к одной только болтовне с ChatGPT. Но подобные чаты — самый простой инструмент для практики общения с ИИ. Там мы учимся корректно ставить задачи и критически оценивать ответы. Кроме того, ИИ-чаты — это универсальный интерфейс доступа к ИИ, как командная строка — к компьютеру. Знание ИИ без владения его интерфейсом кажется сомнительным.

Я не отношусь к гиперактивным пользователям, но я признаю, что ИИ-чаты очень помогают разгребать рутину и находить оптимальные решения. Поэтому я за повышение ИИ-грамотности.

#мысли

Продолжаем путешествие по пирамиде метрик. Мы уже побывали на вершине — там, где живут бизнес-цели. Затем заглянули на самый серьезный слой пирамиды — слой маржинальности. А теперь пришло время наиболее насыщенного и живого уровня — продуктового.

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

Здесь обитают три важнейших аспекта: лояльность, ценность и качество продукта:

▪️лояльность показывает, останется ли клиент с нами надолго;
▪️ценность — насколько мы полезны клиенту;
▪️качество — какой пользовательский опыт мы создаем.

На разных стадиях развития компании фокус может смещаться: стартапы гонятся за ценностью, зрелые бизнесы начинают оптимизировать качество и удержание. Но в идеале — все три работают в связке.

Сегодня копнем в первый блок — лояльность.

Итак, лояльный клиент — это не просто довольный. Это тот, кто:

✔️среди конкурентов выбирает именно вас;
✔️платит и возвращается;
✔️и самое ценное — советует продукт друзьям.

Лояльность можно измерять разными способами — от простого к сложному:

📍 Метрики удовлетворенности

▪️NPS (Net Promoter Score) — «А порекомендуете ли вы нас своему другу?»
▪️CSI (Customer Satisfaction Index) — общий уровень удовлетворенности.

Оба показателя — из опросов. И да, важны не только сами цифры, но и динамика: падает ли NPS после обновления или CSI растет после улучшения сервиса?

📍 Метрики вовлечения

▪️Churn Rate — доля клиентов, которые ушли.
▪️CRR (Customer Retention Rate) — доля тех, кто остался.

Формулы простые, но внимание к деталям — обязательное. Период, активность, возвраты — всё это влияет на корректность.

📍 Скоринговая модель лояльности

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

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

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

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

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

Но пока писал — наступил вечер, а пост так и не закончен 🙃

Поэтому выкладываю фото кота. Потому что пятница.
Если у вас есть домашние питомцы — кидайте в комменты, пусть сегодня будет просто мило.

#пятница #кототерапия

Июнь закончился, и я готов поделиться, что интересного мне повезло прочитать за месяц.

Начну со знакомого автора — Павла Левчука. В этот раз он разобрал построение дерева метрик на Medium (VPN). Это иерархическая декомпозиция метрик верхнего уровня на дочерние, чтобы показать, как низкоуровневые измеримые показатели влияют на бизнес-цели. Павел обозначил подводные камни на первый взгляд простого разложения бизнес-метрик и рассказал, когда деревья помогают аналитику, а когда — лишь сбивают с толку. Например, декомпозиция может не учитывать внешние факторы, такие как сезонность или изменения в экономике, которые влияют на все показатели в цепочке. При работе с таким деревом мы не можем делать адекватные выводы о поведении верхнеуровневых метрик.

Далее предлагаю приподнять капот и посмотреть на внутренности LLM-агентов — программных систем на основе больших языковых моделей, способных самостоятельно решать, какие действия предпринимать для достижения поставленной цели. Кирилл Филипенко из Selectel в блоге на Хабр рассказал, из каких частей они состоят, как планируют свои действия, как хранят информацию и общаются с внешними инструментами. Мне понравилось, как понятно автор объяснил подходы планирования действий Chain-of-Thought, ReAct и Tree-of-Thoughts, а также затронул работу памяти и function calling.

Завершает топ статья о A/B-тесте и заблуждениях вокруг него. Диля Хакимова из Яндекс Go развеяла 10 мифов об A/B-тестировании и разложила варианты решений возникающих проблем по полочкам. В фокус попали мифы об агрегации данных, статистических тестах, метриках и проведении экспериментов. В заключение автор напоминает, что, хотя тема не новая и часто обсуждаемая, возвращаться к ней надо. Подобные упущения ведут к серьезным просчетам и противоречат идее принятия решений на основе объективных данных. Ну как с этим не согласиться!

#дайджест

Metrics matter! Поэтому я не перестану грузить вас постами с их разбором. Сегодня в фокусе — скользкая метрика LTV.

Lifetime Value (LTV), она же CLV или CLTV (Customer Lifetime Value) — метрика, которая показывает, сколько денег в среднем заработает бизнес с клиента, пока тот не прекратит пользоваться услугами: отменит подписку, перестанет делать покупки и др.

LTV пришел из маркетинга прямого отклика. Еще в 1980-х компании осознали, что не все клиенты одинаково ценны. Привлечение новых стоит денег, и если человек исчез после первой покупки, компания понесет убыток. Тогда бизнес сосредоточился на удержании клиентов и стимулировании повторных покупок, чтобы сократить затраты на поиск новых покупателей.

В интернете описаны миллионы способов расчета LTV. Самый простой приведен на слайде.

Если вы учитываете всех пользователей, то используйте ARPU. Но если вас интересует только платящий сегмент, то берите ARPPU. Разницу между метриками я объяснял в одном из прошлых постов.

Под Average Lifetime мы подразумеваем среднее время, в течение которого человек продолжает быть клиентом. Для простоты расчета используют обратную величину оттока Churn Rate. Главное, чтобы тот был стабильным и считался на месячной базе.

В этом подходе есть много минусов, например:
▪️не учитывается маржинальность;
▪️в будущем деньги будут стоить дешевле, чем сейчас;
▪️Lifetime весьма спорная метрика, имеющая множество допущений.

Почему с LTV всё сложно?
LTV — это оценка, основанная на предсказании поведения клиентов. Мы пытаемся просчитать длительность сотрудничества, изменения потребностей людей, действия конкурентов. Это выходная метрика, которая зависит от внешних факторов.

LTV требует качественных данных о доходах, маржинальности, оттоке и поведении клиентов. Если они неполные (например, из-за короткой истории продукта), расчёты будут ненадежными.

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

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

Дубликаты в данных: откуда берутся и почему с ними важно работать

Продолжаем говорить про EDA.

Один из частых источников искажений в аналитике — дубликаты. Они могут незаметно влиять на показатели: увеличивать количество пользователей, транзакций или заказов, создавать иллюзию активности и «раздувать» отчёты. Поэтому выявление и обработка дубликатов — обязательный этап в рамках EDA.

Дубликаты бывают двух типов:

▪️Явные — полные копии строк, где значения совпадают по всем колонкам. Их легко обнаружить с помощью df.duplicated() и удалить через df.drop_duplicates().

▪️Неявные — строки, которые описывают один и тот же объект, но отличаются по формату.

Например:
▪️"USER@mail.ru" и "user@mail.ru"
▪️"ООО Ромашка" и "О.О.О. Ромашка"
▪️"Иванов И.И." и "Иванов Иван"

Такие дубликаты сложнее заметить, и с ними приходится работать вручную или через нормализацию данных.

Основные причины появления дубликатов:

▪️Повторная выгрузка или объединение таблиц без фильтрации.
▪️Ошибки при джойне.
▪️Разные источники с разной структурой.
▪️Отсутствие стандартизации ввода данных.
▪️Человеческий фактор (опечатки, лишние пробелы, регистр).

Что помогает:

✔️ Приведение строк к единому регистру .str.lower()
✔️ Удаление пробелов .str.strip() и лишних символов .str.replace()
✔️ Поиск дубликатов по ключевым колонкам с помощью duplicated(subset=...)
✔️ В отдельных случаях — предварительная агрегация или группировка

Лайфхак: duplicated(subset=...) особенно полезен, когда в таблице есть автоинкрементные ID. Такие поля делают строки уникальными, хотя по сути данные могут дублироваться.

Например, в датасете мы видим, что один и тот же пользователь почему-то сделал два одинаковых заказа — разный order_id, но одинаковые user_id, product_id и order_date. В этом случае duplicated(subset=['user_id', 'product_id', 'order_date']) поможет найти дубли, которые не видны при обычной проверке.

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

Дубликаты — это не просто технический шум. Это риск искажения выводов, особенно в метриках, связанных с уникальными пользователями, заказами или событиями. Их стоит проверять в самом начале работы с данными.

В следующем посте — разберёмся с пропущенными значениями: от типовых NaN до «пустых» строк, которые такими не являются.

#eda

Когортный LTV — метрика, которая оценивает совокупный доход от конкретной группы клиентов за весь период их взаимодействия с продуктом или услугой. В отличие от усредненного LTV для всех пользователей, когортный подход отслеживает динамику LTV по времени и выявляет структурные сдвиги в поведении пользователей.

Напомню, что когорта — это группа пользователей, объединенная по какому-либо признаку: времени регистрации, первой покупки, типу взаимодействия с продуктом и др. Например, при когортном анализе мы понимаем, когда возрастает количество покупок в когорте, а когда покупательская активность спадает. Зная это, можно подстраивать стратегии вовлечения клиентов и увеличивать LTV внутри когорты.

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

План действий:
1️⃣ Группируем пользователей по когортам, например по дате регистрации.
2️⃣ Внутри когорт собираем данные и считаем Revenue за определенные периоды, например три месяца.
3️⃣ Рассчитываем кумулятивный LTV.

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

Можно ли установить причинно-следственную связь между двумя явлениями без эксперимента? Очень даже да!

📚 В поисках эффекта. Планирование экспериментов и причинный вывод в статистике / The Effect: An Introduction to Research Design and Causality
Ник Хантингтон-Клейн / Nick Huntington-Klein

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

В книге два раздела — «Схема исследования» и «Инструменты». Первый, так сказать, для гуманитариев. Он посвящен тому, как мы делаем предположения относительно реального мира и насколько они обоснованы. Ник предлагает начинать с анализа историй, стоящих за данными, чтобы идентифицировать ту их часть, в которой скрыт ответ.

Второй раздел более технический. Он о стандартном наборе инструментов, к которому обращается специалист при поиске причинно-следственных связей. Некоторые из них — статистические инструменты, другие же — обычные исследовательские схемы, удобные для ответов на вопросы исследований.

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

Зато англоязычная веб-версия есть в свободном доступе на theeffectbook.net. Более того, в разделе 0.1 Additional Materials вы найдете 72 видеоурока по темам книги, записанных самим автором, а также исходные коды на Python, Stata и R, используемые в книге, и ссылки на программные пакеты на GitHub.

#книга

Зачем делать ИПР, если всем все равно?

Каждый год тысячи сотрудников старательно заполняют индивидуальные планы развития. Вроде бы всё по-взрослому: есть шаблоны, электронные формы, дедлайны, даже доброжелательный one-to-one с менеджером. Но правда в том, что большинство ИПР никто не читает, не обновляет и уж точно не использует по назначению.

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

Хочется предложить другой подход. Более честный, системный и полезный. В его основе alignment, идея, которую я взял из книг «Working Backwards» и «Measure What Matters».

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

Как это устроено?

Цели компании последовательно декомпозируются до конкретных действий и зон ответственности на всех уровнях:

1️⃣ Компания (стратегический уровень)
Тут главные бизнес-цели на год – рост, прибыль, удержание, масштабирование.

2️⃣ Департамент (тактический уровень)
Тут мы видим вклад подразделения в стратегические цели – направления развития и ключевые проекты.

3️⃣ Команда (операционный уровень)
Что конкретно делает команда, чтобы внести вклад в общие цели? Это уже про OKR, инициативы, дедлайны и результат.

4️⃣ Сотрудник (индивидуальный уровень)
Здесь начинается самое важное – развитие компетенций (курсы, грейды, скиллы) и чёткий кусок ответственности в общей командной цели.

То есть прямо прописано, что конкретно ты делаешь, чтобы команда достигла своих OKR. Если ты затащил – логично ожидать поощрения: рост, бонус, новая зона ответственности. Все прозрачно и мотивирует.

Что это даёт?

✔️ Каждый сотрудник понимает, зачем он развивается и как это влияет на общий успех.
✔️ Менеджер может реально управлять ростом и вкладом каждого.
✔️ Бизнес получает систему, в которой развитие сотрудников работает на стратегию компании.

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

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

Я видел всего одну компанию, которая использовала этот принцип и там ИПР реально работал. А какой у вас опыт? Поделитесь.

#опыт

Выбрал для вас лучшие статьи июля.

Первая из них — о прогнозном фреймворке для расчета временных рядов метрик, которым поделились аналитики из Яндекса. Общий пайплайн включает пять основных шагов: сбор данных и их первичная обработка, комбинирование рядов, очистка данных, построение прогноза и визуализация. Данный фреймворк можно настроить под любую метрику. Именно такое отделение бизнес‑логики отдельных доменов от алгоритма команда ставила своей главной задачей при разработке. В итоге получилось ускорить типовой прогноз, облегчить проведение экспериментов и сделать прогнозные цифры понятнее и прозрачнее для бизнеса. Жаль, что фрейм не выложен в open source.

Далее мне понравился обзор дата-платформы от Т-банка. Она существует более 18 лет и охватывает весь жизненный цикл работы с данными. В настоящий момент ее MAU составляет более 17 тысяч пользователей, а количество запросов к данным в месяц превышает 144 млн. Главная задача платформы — сократить time-to-value для аналитиков и обеспечить их удобными инструментами для обработки данных. В статье автор Дима Пичугин рассказывает о ее нынешней архитектуре, не ныряя глубоко в технические детали (хотя заинтересованные могут найти их по ссылкам).

Последняя статья спускает LLM-фанатов с небес на землю. Павел Бабин, CPO платформы MWS GPT от МТС, рассказал о реальном применении технологии. Оказывается, что кейсы, действительно оптимизирующие бизнес-процессы, относятся к простым вещам: помощь сотрудникам-консультантам при живом общении с клиентами, общение пользователей с ИИ в приложении, удобный UI для сотрудников для работы с LLM. Последний кейс автор выделил как главный тренд. Логика проста: дай человеку нормальный инструмент, и он сам найдет, как его применить, чтобы упростить свою работу.

#дайджест

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

Ценность – это не про эмоции или «нам кажется». Это про то, чего человек реально достиг с помощью продукта. Поэтому, прежде чем что-то измерять, нужно ответить на простой, но не всегда очевидный вопрос: а что именно пользователь хочет получить от продукта?
И второе: в какой момент он действительно это получает?
Именно этот момент называют обменом ценностью.

Важно: не путайте момент обмена ценностью с Aha-моментом. В Aha-моменте пользователь только осознаёт, зачем продукт нужен. А в моменте ценности – уже получает результат.

Чтобы измерить эту ценность, не нужен идеальный фреймворк, нужны базовые метрики:

▪️Количество успешных завершений целевого действия

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

▪️Скорость достижения ценности

Через сколько времени или шагов человек доходит до нужного действия? Чем быстрее – тем выше шанс, что он останется.

▪️Регулярность использования

Повторяет ли он ключевые действия? Осваивает ли новые функции?

▪️Качество результата

Насколько успешно пользователь решает свои джобы? Здесь помогают коэффициенты успешности и CSAT сразу после ключевого события.

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

Следующий слой – метрики качества. И там тоже будет интересно.

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

Что делать с пропусками в данных?

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

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

Работу с пропусками всегда начинаем с базы: df.isna().sum() – покажет нам, где и сколько пропущено.

Так, пропуски найдены. Может просто удалить их? Нееет, подожди.
Удаление – это крайняя мера, так как можно потерять слишком много ценных данных. Особенно если это не просто пустая строчка, а редкий, но важный пользователь. Поэтому чаще выбирают заполнение. Вот основные методы:

1️⃣ Среднее, медиана, мода

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

df['income'] = df.groupby('region')['income'].transform(lambda x: x.fillna(x.median()))

2️⃣ Предыдущее или следующее значение

Идеально подходит для временных рядов. Если один день в продажах пропал, но до и после были – можно заполнить с помощью .ffill() или .bfill().

df['sales'] = df['sales'].ffill()

Только помни: это работает, если данные меняются постепенно, а не скачками.

3️⃣ Интерполяция

Вот тут начинается магия. Интерполяция – способ аккуратно восстановить пропущенные значения по соседним точкам. Простой вариант – линейный:

df['metric'] = df['metric'].interpolate(method='linear')

Если тренд сложный, можно попробовать polynomial, а если данные колеблются, то spline. Это особенно полезно в метриках с сезонностью или кривыми трендами.

Важно: интерполяция работает, когда есть хотя бы несколько точек до и после. Если пропуски в начале или в конце ряда – лучше использовать .ffill() или .bfill().

Как выбирать метод?

✔️ Пропуск один – заполни медианой.
✔️ Пропуск в середине временного ряда – попробуй интерполяцию.
✔️ Пропуск в начале или в конце – используй ближайшее значение.
✔️ Пропуски только в отдельных группах – группируй перед заполнением.

Пропуски не повод паниковать. Это повод задуматься: почему их так много и что будет, если их игнорировать?

#eda

Как эффективно взаимодействовать с ИИ

Недавно я проводил опрос, и 88% подписчиков канала ответили, что используют ИИ-чаты для решения каких-либо задач. А 19% делегируют ИИ даже ежедневную рабочую рутину. Цифры впечатляют.

Но как чаще всего выглядит это общение? Мы задаем какой-то вопрос, пишем призыв «сделай то-то и то-то», чуть уточняем и все. На самом деле можно получать гораздо более качественный результат, для этого существует такая штука, как промпт-инжиниринг.

Промпт-инжиниринг – это искусство создания эффективных запросов (промптов) для взаимодействия с большими языковыми моделями (LLM), такими как ChatGPT.
Умение составить качественный промпт помогает раскрывать весь огромный потенциал ИИ.

Основные техники

1. Zero-shot prompting – запрос без примеров. Модель должна понять задачу и попытаться ответить.
2. Few-shot prompting – запрос с несколькими примерами. Модель получает образцы правильных ответов, что помогает ей лучше понять задачу.
3. Chain-of-thought prompting – пошаговое рассуждение. Модель объясняет свой процесс мышления, что улучшает качество и прозрачность ответа.
4. Role prompting – задание роли. Указание модели определённой роли (например, «ты эксперт по статистике») помогает получить более целенаправленные ответы.
5. Context-enhanced prompting – использование контекста. Предоставление модели дополнительной информации о задаче или ситуации улучшает релевантность ее ответов.

Примеры использования

Zero-shot:

Объясни p-value простыми словами.

→ Модель даст общий обзор, понятный новичку.

Few-shot:

Вот несколько примеров объяснения статистических понятий:

1. Среднее значение – это статистический показатель, который характеризует типичную величину набора числовых данных.
2. Дисперсия – это показатель разброса данных вокруг их среднего значения.

Теперь объясни p-value аналогичным образом.

→ Модель ориентируется на стиль и уровень объяснения.

Chain-of-thought:

Объясни p-value, рассуждая пошагово, чтобы я понял, как его вычисляют и как интерпретируют результаты A/B теста.

→ Модель подробно описывает последовательность действий и логику анализа.

Role + Context-enhanced:

Ты аналитик в финтех-компании. Мы проводим A/B тесты. Объясни p-value так, чтобы я понял его практическое значение и математическую интерпретацию. Приведи пример на основе сравнения двух выборок.

→ Модель выдаёт экспертный разбор с конкретным примером, максимально приближённым к реальной задаче.

Что почитать?

▪️Руководство по промпт-инжинирингу – отличная база с примерами и техниками.
▪️Книга «The Art of Prompt Engineering» – практическое руководство с кейсами и советами.

ИИ-чаты уже стали частью нашей работы и жизни. Пока они не способны заменить человека, но это мощный инструмент автоматизации. Главное – уметь им правильно пользоваться. Экспериментируйте с промптами и выжимайте из ИИ максимум.

#опыт

И снова 3 сентября… а вместе с ним третий способ посчитать LTV!

Прошлые два способа можно глянуть здесь: тыц и тыц.

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

Маржинальность (Gross Margin) – это доля прибыли от выручки после вычета переменных затрат на обслуживание, производство, доставку, сырье и т.д. Она считается так:

Gross Margin (%) = (Revenue - COGS) / Revenue * 100

Например, если COGS составляет 300 000 р., а Revenue – 1 200 000 р., то маржинальность равна 75%. Это значит, что из общей выручки в 1 200 000 р. ваша прибыль составила 900 000 р. Остальные 300 000 р. покрыли затраты на продукт. Про расчет Revenue и COGS я делал отдельный пост.

Дисконтирование – метод, который корректирует будущие доходы на основе ставки дисконтирования. Обычно ставка составляет 5–15% годовых. В нашем случае для простоты мы возьмем 10% годовых или в упрощенном расчете 0.833% в месяц. Метод учитывает, что деньги, полученные через год, менее ценны из-за инфляции, альтернативных инвестиций и рисков.

Чтобы рассчитать прогноз LTV за выбранный период, нужно для каждого месяца взять ARPU, умножить его на маржинальность, дисконтировать и сложить результаты.
Формулу и пример я привел на слайде.

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

Знакомимся!

Спасибо, что вы здесь и читаете канал.
Нас уже 6 тысяч – маленький стадион людей, объединенных любовью к данным. И мне хочется, чтобы мы знали друг друга чуть лучше.

Меня зовут Рома. Родился и живу в Москве, в IT работаю с 2008 года. Начинал как веб-разработчик, потом стал seo-шником (да-да, был и такой грех), а примерно с 2015 ушел в аналитику. Тогда все было куда проще: «Знаешь что такое Яндекс Метрика и Google Analytics?» – ты принят! Сегодня же это профессия с серьезным порогом входа: SQL, Python, A/B-тесты, модели и многое другое. Все эти навыки я осваивал постепенно на практике, дорос до хеда и даже директора по аналитике.

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

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

Теперь ваша очередь! Напишите в комментариях: кто вы, чем занимаетесь и как пришли в аналитику (или только думаете об этом). Будет интересно познакомиться поближе)

Мы разобрали три популярных способа подсчета метрики LTV. Теперь пора сравнить их и сделать выводы.

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

LTV с учетом маржи и дисконтирования. Такой метод расчета популярен среди финансистов, так как отражает финансовую оценку прибыли от усредненного клиента. Оставаясь прогнозной, метрика учитывает дисконтирование за расчетный период и маржу. Это позволяет использовать полученный LTV в юнит-экономике. Такой расчет применяется зрелым бизнесом с накопленной клиентской историей.

Когортный LTV. Это уже фактическая метрика, которая учитывает категорию клиентов. Она рассчитывается на основе накопленных данных о взаимодействии клиентов с продуктом и отражает прибыль, которую получил бизнес от конкретного сегмента пользователей. Метрика помогает переориентировать маркетинговые кампании на более прибыльные когорты клиентов. Ее можно превратить в финансовую модель, если учесть маржу и дисконтирование.

На слайде я суммировал информацию и привел формулы. Сохраняй как шпаргалку.

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