Аналитика на кончиках пальцев

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

Аналитику оценивают не по знанию инструментов, а по способности связать данные с решениями и деньгами. Эти карты — не учебник, а каркас: для каждого понятия мы отвечаем, зачем оно бизнесу, когда включается и как его проваливают на практике. Так разрозненный опыт собирается в систему, которую видно «на кончиках пальцев».

Десять семей — от сути аналитики и AI до построения самой её функции. Сквозь все идёт один тезис: аналитика существует, чтобы повышать качество и скорость решений, а не чтобы делать отчёты.

Каждая карточка помечена уровнем — База / Продвинутый / Эксперт: фильтруйте по глубине, чтобы готовиться от джуновских основ до вопросов уровня Head.

Как читать карточку — пять слотов

Сутьчто это одним предложением, через ценность, без жаргона.

Когда важнов каком контексте и бизнесе понятие включается — насмотренность.

Зачем бизнесукакое решение или риск это улучшает — связь с деньгами.

Главная ошибкакак это проваливают на практике — то, что отличает опыт.

См. такжес чем граничит — системное мышление и связи между семьями.

Для кого Руководители аналитики и кандидаты на роль·Аналитики, растущие в лиды·Все, кто хочет видеть профессию целиком

121 из 121

Суть аналитики

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

01Суть

Аналитика существует ради решений

СутьЦепочка ценности: данные → инсайт → решение → действие → эффект. Аналитика — это не производство отчётов, а повышение качества и скорости решений.

Когда важноНа каждом запросе: первый вопрос — «какое решение ты примешь по результату?». Нет решения — нет смысла в анализе.

Зачем бизнесуФокусирует ограниченные силы на том, что меняет исходы, а не на «посчитать ради интереса».

Главная ошибкаПоследняя миля — инсайт получен, но решение не изменилось: отчёт прочитали и забыли. Ценность теряется именно здесь.

Подробно

Проверьте себя«Какое решение изменится от этого анализа?» Если ответа нет — работу можно не делать.

02Суть

Лестница аналитики

СутьЧетыре ступени по типу вопроса: описательная (что было) → диагностическая (почему) → предиктивная (что будет) → прескриптивная (что делать).

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

Зачем бизнесуКаждая ступень дороже и ценнее. Большинство решений закрывается первыми двумя — не каждую задачу нужно тащить до ML.

Главная ошибкаПерепрыгнуть ступень — строить предсказания, не наведя порядок в описательном слое и определениях.

Подробно

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

03Суть

Пирамида DIKW

СутьДанные → Информация → Знание → Мудрость. Сырые данные сами по себе бесполезны; ценность добавляется на каждом переходе вверх — контекст, связи, суждение.

Когда важноЧтобы отличать «у нас много данных» от «мы умеем принимать на их основе решения» — это разные вещи.

Зачем бизнесуОбъясняет, почему data lake сам по себе не даёт эффекта: между данными и мудростью лежит работа аналитики.

Главная ошибкаКульт объёма — собирать всё подряд («data exhaust») в надежде, что ценность появится сама. Не появляется.

Подробно

Проверьте себя«Чем информация отличается от знания?» Информация отвечает «что», знание — «почему и что с этим делать».

04Суть

Цена ошибки и обратимость решения

СутьГлубина анализа должна быть пропорциональна цене ошибки. Решения бывают обратимые («дверь в обе стороны») и необратимые («дверь в одну сторону»).

Когда важноПри выборе строгости: обратимое дешёвое решение — пробуй быстро; необратимое дорогое — измеряй строго.

Зачем бизнесуЭкономит время: не тратить недели на анализ там, где решение легко откатить, и не «прыгать» там, где откат невозможен.

Главная ошибкаОдинаковая строгость для всего — паралич анализа на мелочах и поспешность на необратимом.

Подробно

ПримерЦвет кнопки — обратимо, хватит быстрого A/B. Смена модели монетизации — необратимо для доверия, нужно строгое измерение и пилот.

Проверьте себя«Это решение в одну дверь или в обе?» — определяет, сколько анализа оно заслуживает.

05Суть

Ценность информации — когда анализ окупается

СутьАнализ имеет смысл, только если он способен изменить решение и его ценность выше стоимости (включая cost of delay — цену промедления). Идея ожидаемой ценности информации (EVPI).

Когда важноКогда просят «ещё данных» перед очевидным решением, или когда анализ дороже выигрыша от его точности.

Зачем бизнесуЗащищает от паралича анализа и от «исследований ради спокойствия», которые ничего не меняют.

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

Подробно

Проверьте себя«Изменится ли ваше действие, если результат окажется противоположным?» Нет — анализ не нужен.

06Суть

Корреляция не равна причинности

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

Когда важноВсегда при выводе «X влияет на Y» из наблюдательных данных — особенно перед дорогим решением.

Зачем бизнесуСпасает от решений на ложной связи: «активные в приложении дольше остаются» ≠ «заставим всех быть активными — удержим».

Главная ошибкаConfounder — упустить общий фактор. Классика: «мороженое и утопления растут вместе» (причина — жара).

Золотой стандарт: причинность доказывает только рандомизированный эксперимент или защитимый квазиэксперимент, а не корреляция в дашборде.

Подробно

Проверьте себя«Какой третий фактор мог вызвать обе величины?» — первый вопрос к любой найденной связи.

07Суть

Закон Гудхарта и метрики-тщеславие

Суть«Когда метрика становится целью, она перестаёт быть хорошей метрикой» — её начинают накручивать. Метрика-тщеславие (vanity) растёт красиво, но не связана с ценностью.

Когда важноПри выборе целевых показателей и KPI команд — особенно когда от метрики зависит премия.

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

Главная ошибкаОптимизировать метрику, а не цель — команда выполняет показатель, а бизнес-исход ухудшается.

Подробно

Как защититьсяПарные метрики и guardrails: к метрике роста добавлять контр-метрику качества, чтобы её нельзя было накрутить в ущерб цели.

Проверьте себя«Как эту метрику можно накрутить, не создав ценности?» — если легко, нужна контр-метрика.

08Суть

Данные vs мнения vs гипотезы

СутьИерархия достоверности: факты (доказано экспериментом) → данные (наблюдения, «что», не «почему») → обоснованные гипотезы → мнения → заблуждения. Интуиция генерирует гипотезы; решения принимаются на фактах.

Когда важноНа каждом совещании, где «очевидно» и «логично» выдают за установленную истину.

Зачем бизнесуОтделяет проверенное от правдоподобного: «звучит логично» — это гипотеза, а не основание для дорогого решения.

Главная ошибкаПринять мнение за факт — действовать по «эксперты считают» без проверки. История полна красивых заблуждений (кровопускание, Scared Straight повышала преступность).

Подробно

Пример«Пользователи с пушами лучше удерживаются» — это наблюдение (возможен эффект отбора), а не доказательство, что включение пушей удержит.

Проверьте себя«Это факт, обоснованная гипотеза или мнение?» — вопрос к любому утверждению на встрече.

09Суть

Закон Голла — от простого к сложному

Суть«Работающая сложная система неизменно выросла из работающей простой» (Джон Голл). Сложную систему нельзя спроектировать с нуля и ждать, что она заработает, — её наращивают итеративно.

Когда важноПри запуске продуктов, платформ, дата-платформ и аналитических систем.

Зачем бизнесуОправдывает MVP и итерации и предостерегает от «большого взрыва»: переписать всё сразу и идеально почти всегда проваливается.

Главная ошибкаБольшой взрыв — строить сложное с нуля (мега-платформа, «идеальный» склад за год) вместо работающего простого, которое эволюционирует.

Подробно

Проверьте себя«Есть ли работающая простая версия, из которой это растёт?» Если строите сложное с чистого листа — риск не взлететь.

Data Engineering — инженерия данных

Фундамент: надёжные, своевременные, правильно смоделированные данные. «Мусор на входе — мусор на выходе». Здесь важно не знание конкретных инструментов, а понимание trade-off’ов: почему именно так хранят и моделируют под аналитику.

01Инженерия

OLTP против OLAP

СутьФундаментальный водораздел. OLTP — транзакционные системы (много мелких записей, целостность, текущее состояние). OLAP — аналитические (тяжёлые запросы на чтение по большим объёмам, история).

Когда важноНельзя гонять аналитику по боевой OLTP-базе: тяжёлые запросы кладут продукт. Отсюда — отдельное хранилище.

Зачем бизнесуРазделение нагрузок: продукт остаётся быстрым, а аналитика — свободной считать что угодно, не мешая ему.

Главная ошибкаСчитать отчёты на проде — деградация продукта и блокировки; или, наоборот, ждать от склада транзакционной свежести.

Подробно

Проверьте себя«Почему нельзя строить дашборды прямо на продакшн-базе?» → нагрузка, блокировки, иная модель данных.

02Инженерия

Строчные против колоночных хранилищ

СутьСтрочные хранят запись целиком (быстро взять одну строку — OLTP). Колоночные хранят значения колонки подряд: для аналитики это сжатие и чтение только нужных колонок при скане миллионов строк.

Когда важноАналитический запрос трогает 3 колонки из 200 по всей таблице — колоночное хранилище читает только их.

Зачем бизнесуСкорость и стоимость: агрегации по гигабайтам за секунды вместо минут (ClickHouse, BigQuery, Snowflake, Redshift).

Главная ошибкаКолоночное под точечные записи — частые единичные update/delete в колоночном складе медленны: оно создано для чтения и пакетной загрузки.

Подробно

Проверьте себя«Почему колоночное хранилище сжимает лучше?» → в одной колонке однотипные значения, они отлично сжимаются.

03Инженерия

Нормальные формы: нормализовать или нет

СутьНормализация (1NF–3NF) убирает дублирование и аномалии вставки/обновления, разбивая данные на связанные таблицы. Денормализация — намеренное дублирование ради скорости чтения.

Когда важноНормализовать — в OLTP (целостность, частые записи). Денормализовать — в аналитике (читаем много, пишем пакетно, JOIN’ы дорого).

Зачем бизнесуЭто осознанный trade-off «целостность vs скорость чтения», а не догма. Понимать оба полюса — признак зрелости.

Главная ошибкаДогматизм — нормализовать аналитический склад до 3NF (запросы тонут в JOIN’ах) или денормализовать OLTP (аномалии обновления).

Подробно

Проверьте себя«Зачем денормализуют витрины для BI?» → убрать дорогие JOIN’ы и ускорить чтение под дашборды.

04Инженерия

Звезда, снежинка, факты и измерения

СутьРазмерное моделирование (Кимбалл): таблицы фактов (события/метрики — продажи, клики) и измерений (контекст — товар, клиент, дата). Схема «звезда» — факт в центре, измерения вокруг; «снежинка» — измерения дополнительно нормализованы.

Когда важноБазовая структура любого аналитического склада и BI-слоя — на ней строятся дашборды и кубы.

Зачем бизнесуПонятная бизнесу модель «метрика в разрезах»: выручка по региону, по категории, по времени — без знания SQL-кишок.

Главная ошибкаНеверная гранулярность факта — смешать уровни (строка заказа vs заказ) и получить задвоение сумм при агрегации.

Подробно

Проверьте себя«Что такое грануляность таблицы фактов и почему её фиксируют первой?» → одна строка = одно событие на заданном уровне.

05Инженерия

Медленно меняющиеся измерения (SCD)

СутьКак хранить изменение атрибута измерения во времени. Тип 1 — перезаписать (теряем историю). Тип 2 — новая версия строки с периодом действия (храним историю). Тип 3 — колонка «предыдущее значение».

Когда важноКлиент сменил город, товар — категорию. Вопрос: отчёт за прошлый год считать по старому или новому значению?

Зачем бизнесуКорректность исторической отчётности: SCD2 даёт «как было на тот момент», SCD1 — «как сейчас». Это бизнес-выбор.

Главная ошибкаSCD1 там, где нужна история — перезаписали атрибут и потеряли возможность воспроизвести прошлые отчёты.

Подробно

Проверьте себя«Клиент переехал — как посчитать прошлогоднюю выручку по регионам?» Ответ зависит от выбранного типа SCD.

06Инженерия

Виды хранилищ под задачу

СутьРеляционные (Postgres) — целостность и транзакции. MPP-склады (Snowflake, BigQuery) — аналитика. Озёра (object storage + Parquet) — дёшево и сыро. Lakehouse (Iceberg, Delta) — озеро со свойствами склада. NoSQL — key-value, документные, wide-column, графовые, time-series.

Когда важноВыбор хранилища = выбор под профиль нагрузки и структуру данных, а не «по моде».

Зачем бизнесуПравильный класс экономит деньги и время: граф для связей, time-series для метрик, склад для агрегаций.

Главная ошибкаОдин молоток на всё — пихать всё в реляционную БД (или, наоборот, в Mongo), игнорируя профиль доступа.

Подробно

Проверьте себя«Когда графовая БД лучше реляционной?» → когда главное в данных — связи и обходы (соцграф, фрод, рекомендации).

07Инженерия

ETL против ELT

СутьETL — преобразовать данные до загрузки в склад. ELT — сначала загрузить сырьё, преобразовать внутри мощного склада. С приходом облачных складов победил ELT.

Когда важноКогда дешёвое масштабируемое хранилище делает выгодным «загрузить всё сырьё и трансформировать SQL’ем».

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

Главная ошибкаТерять сырьё в ETL — преобразовали на лету и не сохранили исходник: новую метрику задним числом уже не посчитать.

Подробно

Проверьте себя«Почему ELT стал стандартом в облаке?» → склад дешёвый и мощный, сырьё ценно, трансформации версионируются (dbt).

08Инженерия

Пакетная обработка против потоковой

СутьBatch — обрабатывать данные порциями по расписанию (раз в час/сутки). Streaming — обрабатывать события по мере поступления (Kafka, Flink). Архитектуры Lambda (batch + stream) и Kappa (только stream).

Когда важноРешает требование к свежести: дневной отчёт — batch; антифрод, рекомендации, алерты — streaming.

Зачем бизнесуСвежесть стоит денег и сложности. Real-time нужен там, где решение принимается в секундах, иначе batch дешевле.

Главная ошибкаReal-time ради галочки — строить дорогой стриминг там, где бизнес-решение всё равно принимается раз в день.

Подробно

Проверьте себя«Нужен ли вам real-time?» → только если решение по данным принимается быстрее, чем приходит следующий batch.

09Инженерия

ACID, BASE и теорема CAP

СутьACID — строгие гарантии транзакций (банки). BASE — мягкая согласованность ради доступности и масштаба. CAP: при сетевом сбое в распределённой системе приходится выбирать между согласованностью и доступностью.

Когда важноПри выборе БД под требования бизнеса к согласованности: деньги нельзя «потерять», лайки — можно подождать.

Зачем бизнесуОбъясняет, почему «согласованность за миллисекунды на весь мир» физически невозможна без жертв — управляемый компромисс.

Главная ошибкаЖдать ACID от eventually consistent — строить финансовую логику поверх хранилища с отложенной согласованностью.

Подробно

Проверьте себя«Что выберете при сетевом разрыве — согласованность или доступность?» Зависит от цены устаревших данных для бизнеса.

10Инженерия

Качество данных и контракты

СутьШесть измерений качества: полнота, точность, согласованность, своевременность, уникальность, валидность. Data contracts фиксируют ожидания к источнику; observability следит за свежестью, объёмом, схемой, lineage.

Когда важноПостоянно: тихо сломавшийся источник отравляет все отчёты и модели ниже по потоку.

Зачем бизнесуДоверие к данным — фундамент. Один незамеченный сбой загрузки = неделя неверных решений и потерянное доверие к аналитике.

Главная ошибка«Молчаливая» поломка — нет тестов и алертов на данные, ошибку находит бизнес в отчёте, а не инженер в пайплайне.

Подробно

ПодходMedallion: bronze (сырьё) → silver (очищенное) → gold (витрины). Тесты на каждом слое: not-null, уникальность ключа, диапазоны.

Проверьте себя«Как вы узна́ете о сбое раньше бизнеса?» → тесты на данные + мониторинг свежести и объёма.

11Инженерия

Доменные знания и semantic layer

СутьИнженер кодирует семантику бизнеса: что такое «клиент», какие бизнес-ключи, валидные диапазоны, логика дедупликации. Эти определения собираются в semantic (metrics) layer — единый смысл для всех потребителей.

Когда важноКогда технически корректные таблицы оказываются бизнес-бессмысленными, а у каждой команды «своя выручка».

Зачем бизнесуБез домена инженер строит правильные, но не те данные. Semantic layer превращает данные в общий язык компании.

Главная ошибкаИнженерия в вакууме — моделировать данные, не понимая бизнес-процесс: получаются «чистые» таблицы, которым нельзя задать бизнес-вопрос.

Подробно

Проверьте себя«Кто решает, что считается активным клиентом — инженер или бизнес?» Бизнес определяет, инженер фиксирует это один раз в слое.

Data Science / ML

Предсказание и поиск паттернов там, где правила не масштабируются. Для руководителя ключевое — не алгоритмы, а как измерять качество, когда модели верить, что значит интерпретируемость и когда ML вообще не нужен.

01Data Science

Классы задач машинного обучения

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

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

Зачем бизнесуТип задачи диктует данные, метрику и сложность. Ошибка постановки дороже ошибки алгоритма.

Главная ошибкаПодмена задачи — решать классификацией то, что на деле вопрос о причинном эффекте (нужен эксперимент, а не предсказание).

Подробно

Проверьте себя«Прогноз оттока и влияние скидки на отток — одна задача?» Нет: первое — предсказание, второе — каузальный вопрос.

02Data Science

Жизненный цикл и когда ML не нужен

СутьЦикл (CRISP-DM): постановка → данные → фичи → модель → оценка → деплой → мониторинг. И железное правило: сначала простой baseline (эвристика, «последнее значение», правило).

Когда важноПеред любым ML-проектом: часто правило или SQL-эвристика дают 80% пользы за 5% стоимости.

Зачем бизнесуBaseline задаёт планку: если сложная модель не бьёт простое правило — она не нужна. Экономит месяцы.

Главная ошибкаML ради ML — тащить нейросеть туда, где хватает порога или бизнес-правила; и забыть про мониторинг после деплоя.

Подробно

Проверьте себя«Какой у вас baseline?» Нет ответа — проект не готов: не с чем сравнивать модель.

03Data Science

Метрики качества: регрессия

СутьRMSE — штрафует большие ошибки сильнее (чувствительна к выбросам). MAE — средняя ошибка в тех же единицах, устойчивее. MAPE — ошибка в процентах (но ломается у нуля). R² — доля объяснённой дисперсии.

Когда важноКогда предсказываем число (спрос, цена, время). Выбор метрики = выбор, какие ошибки для бизнеса дороже.

Зачем бизнесуRMSE если крупные промахи критичны (склад, мощности); MAE если важна типичная ошибка; MAPE для сравнимости между товарами.

Главная ошибкаМетрика без бизнес-смысла — гнаться за R², когда бизнесу важна абсолютная ошибка в штуках или рублях.

Подробно

Проверьте себя«RMSE или MAE при выбросах в данных?» MAE устойчивее; RMSE если крупные промахи нужно карать сильнее.

04Data Science

Метрики качества: классификация

СутьPrecision (из предсказанных «да» сколько верны) против Recall (из всех «да» сколько поймали), их баланс — F1. ROC-AUC — общая разделяющая способность; PR-AUC честнее при сильном дисбалансе классов.

Когда важноВсегда при дисбалансе: фрод, болезни, отток — где «да» это 1% выборки.

Зачем бизнесуPrecision дорог, когда ложная тревога стоит дорого (блокировка клиента); recall — когда дорог пропуск (упущенный фрод, болезнь).

Главная ошибкаAccuracy на дисбалансе — модель «всегда нет» даёт 99% точности и ноль пользы. Accuracy здесь обманывает.

Запомнить: при дисбалансе классов accuracy бесполезна — смотрите precision/recall и PR-AUC, а не «процент верных».

Подробно

Проверьте себя«Модель ловит фрод с accuracy 99% — это хорошо?» Скорее всего нет: спросите про recall и долю пропущенного фрода.

05Data Science

Порог под цену ошибки и калибровка

СутьМодель выдаёт вероятность; порог отсечения выбирается под матрицу стоимости ошибок (цена ложного срабатывания vs пропуска). Калибровка — чтобы «вероятность 0,8» означала реальные 80%.

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

Зачем бизнесуОдин и тот же ML-вывод при разном пороге даёт разную экономику. Порог — бизнес-решение, не дефолт 0,5.

Главная ошибкаПорог 0,5 по умолчанию — игнорировать асимметрию стоимости ошибок; и доверять некалиброванным вероятностям в деньгах.

Подробно

Проверьте себя«Откуда взялся порог 0,5?» Если «по умолчанию» — это красный флаг: порог должен идти из стоимости ошибок.

06Data Science

Переобучение и утечка данных

СутьДеление train/validation/test и кросс-валидация. Переобучение — модель выучила шум, на новых данных проваливается. Утечка (data leakage) — в фичи попала информация из будущего или о таргете. Баланс bias-variance.

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

Зачем бизнесуУтечка даёт блестящие цифры на тесте и катастрофу в проде. Распознавать её — базовый навык доверия к ML.

Главная ошибкаУтечка таргета — фича, которая в реальности доступна только после наступления события (например, «дата закрытия сделки» в прогнозе сделки).

Подробно

Проверьте себя«Модель показала AUC 0,99 — радоваться?» Сначала искать утечку: такие цифры почти всегда означают, что в фичи затёк ответ.

07Data Science

Офлайн-качество против онлайн-эффекта

СутьХорошая офлайн-метрика (AUC, RMSE) не гарантирует продуктового эффекта. Истинная проверка модели — A/B-тест в проде с бизнес-метриками и guardrails.

Когда важноПеред раскаткой: офлайн отбирает кандидатов, онлайн доказывает ценность.

Зачем бизнесуМодель с лучшим AUC может ухудшить выручку (рекомендует то, что и так купили бы). Решает онлайн-эксперимент, а не лидерборд.

Главная ошибкаРаскатка по офлайн-метрике — выкатить модель, потому что «AUC выше», без A/B-проверки влияния на бизнес.

Подробно

Проверьте себя«Новая модель лучше по AUC — катим?» Сначала A/B: влияние на бизнес-метрику, а не на офлайн-скор.

08Data Science

Интерпретируемость моделей

СутьВнутренне понятные модели (линейные, деревья) против пост-хок объяснений сложных (SHAP, LIME, важность признаков, PDP). Глобальная (как модель работает в целом) и локальная (почему такое решение по этому объекту).

Когда важноРегуляторика (кредитный скоринг обязан объяснить отказ), доверие стейкхолдеров, отладка, поиск bias.

Зачем бизнесуНеобъяснимую модель не пустят в регулируемую сферу и ей не будут доверять. Объяснимость = условие внедрения.

Главная ошибкаМиф о неизбежном выборе «точность или объяснимость» — часто простая объяснимая модель почти не уступает, а SHAP объясняет и сложную.

Подробно

Как достигатьВыбирать интерпретируемую модель, где это критично; для сложных — SHAP-объяснения каждого решения и проверка на справедливость по сегментам.

Проверьте себя«Клиент требует объяснить отказ в кредите — что покажете?» Локальное объяснение вклада факторов, а не «так решила нейросеть».

09Data Science

Каузальность против корреляции в ML

СутьОбычная модель предсказывает «кто уйдёт», но не «кого удержит скидка». Для второго нужен uplift-моделинг — оценка эффекта воздействия (treatment effect), а не вероятности события.

Когда важноКогда по предсказанию идёт вмешательство: кому звонить, кому давать промо, кого лечить.

Зачем бизнесуСкидка тем, кто и так бы остался, — слив бюджета. Uplift находит тех, на кого воздействие реально влияет.

Главная ошибкаДействовать по скор-вероятности — слать промо «склонным к покупке», хотя они купили бы и без него (нулевой или отрицательный uplift).

Подробно

Проверьте себя«Шлём промо самым склонным к покупке — верно?» Часто нет: им оно не нужно. Нужен uplift, а не склонность.

10Data Science

MLOps и дрейф моделей

СутьМодель в проде — это продукт: версионирование, воспроизводимость, реестр моделей, мониторинг. Дрейф данных (меняется вход) и дрейф концепции (меняется связь вход→выход) деградируют модель со временем.

Когда важноПосле деплоя — всегда. Мир меняется, и вчерашняя модель тихо стареет (ковид сломал все прогнозы спроса).

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

Главная ошибка«Обучили и забыли» — нет мониторинга дрейфа; модель незаметно деградирует месяцами.

Подробно

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

11Data Science

GenAI и LLM: грамотность руководителя

СутьRAG (подмешать свои данные в контекст) против fine-tuning (дообучить под стиль/формат) против промптинга. Галлюцинации, guardrails, и отдельная сложность — оценка генеративных систем (нет одной метрики, нужны LLM-судьи и наборы тестов).

Когда важноСейчас: GenAI меняет и продукт, и саму работу аналитика (text-to-SQL, авто-инсайты). Руководитель обязан иметь позицию.

Зачем бизнесуПонимать, где LLM даёт ценность, а где уверенно врёт; что дешевле — RAG или дообучение; как мерить качество ответов.

Главная ошибкаДоверять без оценки — выкатить LLM-фичу без набора тестов и guardrails: красивые демо, провал на хвосте запросов.

Подробно

Проверьте себя«RAG или fine-tuning для ответов по вашей базе знаний?» Обычно RAG: данные меняются, дообучение дорого и устаревает.

12Data Science

Метрики ранжирования и релевантности

СутьКачество поиска/ленты мерят иначе, чем классификацию: precision@k, recall@k, MAP, MRR и главное — NDCG (учитывает позицию и градации релевантности). Нужны эталоны: асессоры/Толока, side-by-side, плюс онлайн-метрики.

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

Зачем бизнесу«Выкатывать ли новую формулу ранжирования» решается набором метрик и триангуляцией offline (эталоны) + online (A/B), а не одним числом.

Главная ошибкаОдна метрика на ранжирование — гнать CTR (растёт от кликбейта) или голую долю релевантных без учёта позиции, свежести и разнообразия.

Подробно

ПримерТоп новостей оценивают по свежести, популярности, важности (асессоры) и разнообразию; формулу сравнивают через NDCG к эталону и подтверждают A/B.

Проверьте себя«Чем NDCG лучше доли релевантных в топе?» → учитывает позицию и градации релевантности, а не бинарно «релевантно/нет».

13Data Science

Антифрод и детект аномалий

СутьПоиск мошенничества и злоупотреблений: правила (быстро, прозрачно) + модели (ловят новое). Сильный дисбаланс классов (фрод — доли процента), поэтому precision/recall под цену ошибки, а не accuracy. Противник адаптируется (adversarial).

Когда важноФинтех, платежи, реклама (накрутка кликов), маркетплейсы, антиспам, антибот.

Зачем бизнесуЦена ошибки двусторонняя: пропустить фрод дорого, заблокировать честного клиента — тоже. Порог отсечения — бизнес-решение.

Главная ошибкаСтатичная модель против живого противника — обучить раз и забыть; фродстеры подстраиваются, precision/recall падают без обратной связи и переобучения.

Подробно

ПримерСкоринг транзакций: правила на явное + ML на паттерны + ручной разбор спорных + петля обратной связи от разметки.

Проверьте себя«Почему accuracy бесполезна в антифроде?» → дисбаланс: «всё чисто» даёт 99% точности и ноль пользы.

14Data Science

Системы рекомендаций

СутьПодбор релевантного контента/товаров: коллаборативная фильтрация (похожие пользователи/айтемы), контентная (по признакам), гибриды. Оценка — offline (precision@k, NDCG, MAP) + online A/B. Свои ловушки: холодный старт и popularity bias.

Когда важноE-commerce, медиа, лента, маркетплейс, стриминг — везде, где вопрос «что показать следующим».

Зачем бизнесуРекомендации двигают выручку и вовлечённость, но плохо измеренные раздувают популярное и сужают выбор (filter bubble), теряя длинный хвост.

Главная ошибкаОптимизировать только CTR/точность — рекомендовать то, что и так купили бы (нулевой uplift), усиливать popularity bias и игнорировать разнообразие, новизну и холодный старт.

Подробно

ПримерГибрид CF + контент для холодного старта; offline отбирает кандидатов, A/B решает; следят за coverage и diversity, а не только за CTR.

Проверьте себя«Почему высокий CTR рекомендаций — не всегда хорошо?» → popularity bias, нулевой uplift, схлопывание разнообразия.

Product Analytics

Понять и улучшить поведение пользователей в продукте. Ядро — экспериментальный подход: гипотеза, чистая проверка, защитимый вывод. Глубокий разбор экспериментов — в отдельном разделе exp.chu.st; здесь — каркас для руководителя.

01Продукт

Трекинг-план и таксономия событий

СутьЗаранее спроектированная схема событий и их свойств плюс разрешение идентичности (один человек на разных устройствах). Это источник правды о поведении.

Когда важноДо запуска фичи: что не залогировали — то не измерили, задним числом не восстановить.

Зачем бизнесуКачество всей продуктовой аналитики упирается в качество трекинга. Грязные события = неверные воронки и ретеншн.

Главная ошибкаХаос событий — каждый разработчик называет события по-своему, нет владельца плана; аналитика месяцами чистит вместо анализа.

Подробно

Проверьте себя«Хотим измерить новую фичу — когда ставить трекинг?» До релиза, иначе первые недели данных потеряны.

02Продукт

Воронки и точки отказа

СутьПоследовательность шагов к цели (регистрация → активация → покупка) с конверсией на каждом. Показывает, где пользователи отваливаются.

Когда важноДля поиска самого узкого места — где маленькое улучшение даёт наибольший прирост итоговой конверсии.

Зачем бизнесуФокусирует усилия: чинить шаг с худшей конверсией, а не равномерно «улучшать всё».

Главная ошибкаСмотреть только итог — видеть общую конверсию, не разложив по шагам; и забывать про окно времени и сегменты.

Подробно

Проверьте себя«Где чинить воронку в первую очередь?» На шаге с наибольшим отвалом при достаточном трафике — там рычаг.

03Продукт

Удержание и когорты

СутьRetention — доля вернувшихся через N дней; смотрится по когортам (группам по дате прихода). Кривая удержания должна выходить на плато («улыбка»), а не падать в ноль.

Когда важноГлавный индикатор product-market fit: без плато удержания рост — это наполнение «дырявого ведра».

Зачем бизнесуУдержание определяет LTV и устойчивость роста сильнее, чем привлечение. Плоское плато = живой продукт.

Главная ошибкаРастить привлечение при падающем удержании — лить трафик в продукт без плато: деньги утекают в отток.

Подробно

Проверьте себя«Кривая удержания не выходит на плато — что это значит?» Нет product-market fit; масштабировать привлечение рано.

04Продукт

Активация и «момент озарения»

СутьАктивация — момент, когда пользователь впервые получил ценность («aha moment»). Часто выражается порогом (Facebook: «7 друзей за 10 дней», Slack: «2000 сообщений в команде»).

Когда важноОнбординг — вести пользователя к активационному порогу как можно быстрее.

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

Главная ошибкаКорреляция вместо причинности — принять «активные делают X» за «заставим делать X — активируем». Порог надо проверять экспериментом.

Подробно

Проверьте себя«Нашли, что aha = добавить 3 друзей. Что дальше?» Проверить причинность экспериментом, а не просто гнать всех к порогу.

05Продукт

Вовлечённость: DAU, MAU, stickiness

СутьDAU/WAU/MAU — активные за день/неделю/месяц. Stickiness = DAU/MAU (какую долю месяца пользователь с продуктом). L7/L28 — сколько из последних дней он был активен.

Когда важноДля продуктов с ожидаемой высокой частотой (соцсети, мессенджеры); для редких сценариев DAU/MAU вводит в заблуждение.

Зачем бизнесуПоказывает глубину привычки. Stickiness 50% (продукт нужен каждый второй день) — сильный сигнал вовлечённости.

Главная ошибкаDAU/MAU не к месту — мерить «липкость» там, где продукт по природе редкий (налоги, билеты): низкий DAU/MAU тут норма, а не беда.

Подробно

Проверьте себя«Подходит ли DAU/MAU вашему продукту?» Только если ожидаемая частота высокая; иначе берите естественную частоту использования.

06Продукт

AARRR и учёт роста

СутьПиратские метрики: Acquisition → Activation → Retention → Referral → Revenue. Growth accounting раскладывает изменение активной базы на новых, вернувшихся, удержанных и ушедших (resurrected / churned).

Когда важноЧтобы видеть, за счёт чего растёт (или не растёт) база: приток новых маскирует отток старых.

Зачем бизнесу«Растём на 10%» может скрывать «теряем 30% старых, заливаем 40% новых» — это нездоровый, дорогой рост.

Главная ошибкаСмотреть нетто-рост — радоваться итоговой цифре, не разложив на компоненты притока и оттока.

Подробно

Проверьте себя«База выросла на 10% — это хорошо?» Зависит: разложите на new/resurrected/churned, чтобы увидеть здоровье роста.

07Продукт

A/B-тест: суть экспериментального подхода

СутьСлучайное разделение на контроль и тест, изменение только одной вещи, сравнение по заранее выбранному критерию (OEC — overall evaluation criterion). Рандомизация уравнивает всё прочее — отсюда причинность.

Когда важноКогда решение обратимо и есть трафик: золотой стандарт доказательства «эта фича вызвала этот эффект».

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

Главная ошибкаOEC задним числом — выбрать метрику успеха после просмотра результатов; и менять несколько вещей сразу, теряя причину.

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

Подробно

ГлубжеПолный разбор дизайнов, методов и защиты выводов — раздел exp.chu.st.

Проверьте себя«Почему именно рандомизация даёт причинность?» Она уравнивает все скрытые факторы между группами в среднем.

08Продукт

Статзначимость, мощность, размер выборки

Сутьp-value — вероятность увидеть такой эффект при отсутствии реального. Доверительный интервал — диапазон правдоподобных значений. Мощность — шанс заметить эффект, если он есть. MDE — минимальный эффект, который тест способен поймать; он задаёт размер выборки.

Когда важноДо запуска — посчитать, сколько нужно наблюдений; после — корректно прочитать результат.

Зачем бизнесуЗащищает от двух ошибок: поверить в шум и отвергнуть реальный, но недозамеренный эффект.

Главная ошибка«Незначимо = нет эффекта» — на малой выборке тест просто не смог его увидеть. И «p>0,05» не доказывает отсутствие.

Подробно

Проверьте себя«Тест незначим — фича не работает?» Не обязательно: проверьте мощность и MDE, возможно, выборки не хватило.

09Продукт

Ловушки экспериментов

СутьПодглядывание (peeking) и остановка на «значимом»; множественные сравнения (тестируем 20 метрик — одна «выстрелит» случайно); SRM — перекос распределения по группам (сломана рандомизация); эффекты новизны и привыкания; сетевые эффекты (группы влияют друг на друга).

Когда важноВ каждом эксперименте — именно эти ошибки рождают «значимые» фантомы, которые не воспроизводятся.

Зачем бизнесуРаскатанная по ложному выводу фича стоит денег и доверия к экспериментам. Гигиена = защита от самообмана.

Главная ошибкаОстановить тест на первом «значимо» — подглядывание многократно завышает ложные срабатывания.

Подробно

Проверьте себя«Что такое SRM и почему он обнуляет тест?» Перекос групп (например 55/45 вместо 50/50) означает, что рандомизация или логирование сломаны.

10Продукт

Снижение дисперсии и guardrail-метрики

СутьCUPED и стратификация уменьшают шум, используя данные до эксперимента, — тест становится чувствительнее при том же трафике. Guardrail-метрики — показатели, которые нельзя ухудшать (скорость, отписки, ошибки), даже если основная метрика выросла.

Когда важноПри дефиците трафика (CUPED ускоряет) и всегда — чтобы выигрыш не достигался ценой скрытого вреда.

Зачем бизнесуБыстрее и дешевле получать выводы; и не «выиграть конверсию», обвалив удержание или производительность.

Главная ошибкаПобеда без guardrails — раскатать рост основной метрики, не заметив просадку защитных (отписки, латентность, поддержка).

Подробно

Проверьте себя«Конверсия выросла, тест выиграл — катим?» Сначала проверьте guardrails: не упали ли удержание, скорость, жалобы.

11Продукт

Квазиэксперименты — когда нельзя рандомизировать

СутьКогда A/B невозможен (нельзя поделить пользователей, изменение глобальное), причинность приближают: difference-in-differences, regression discontinuity, синтетический контроль, switchback (переключение по времени).

Когда важноМаркетплейсы (сетевые эффекты), офлайн-изменения, цены, региональные запуски, законы.

Зачем бизнесуДаёт защитимый вывод об эффекте там, где «золотой стандарт» недоступен, — лучше, чем гадание по корреляции.

Главная ошибкаВыдавать корреляцию за эффект — «после запуска выросло» без контроля тренда и сезонности (нужен хотя бы DiD).

Подробно

Проверьте себя«Изменили цену во всём городе — как измерить эффект без A/B?» DiD против похожего города или синтетический контроль.

12Продукт

Vanity против actionable, локальные оптимумы

СутьМетрика-тщеславие (суммарные регистрации, просмотры) растёт всегда и ничего не говорит о решении. Actionable-метрика привязана к действию. Плюс риск локального оптимума: бесконечная докрутка кнопок вместо смены подхода.

Когда важноПри выборе, что показывать на дашборде и что оптимизировать командой.

Зачем бизнесуVanity-метрики создают иллюзию прогресса. Парадокс Симпсона напоминает: агрегат может врать, если не смотреть по сегментам.

Главная ошибкаОптимизировать тщеславие — гнать суммарные счётчики вверх; и доверять агрегату, в котором скрыт mix-эффект (Симпсон).

Подробно

Проверьте себя«Чем actionable-метрика отличается от vanity?» Actionable меняется от ваших действий и подсказывает следующий шаг.

13Продукт

Метрики продукта против метрик роста

СутьМетрики продукта (retention, конверсия от новых, время до ценности) показывают, работает ли продукт; метрики роста (DAU, выручка, установки) — сколько его потребляют. На метрики роста влияют маркетинг и накопленная база.

Когда важноПри сравнении версий/релизов и оценке product-market fit.

Зачем бизнесуРост маскирует гниющий продукт (льём трафик в дырявое ведро); и наоборот — продукт улучшился, а DAU просел из-за сезонности маркетинга.

Главная ошибкаСравнивать версии по DAU/выручке — вывод «новая версия лучше» по растущему DAU, который двигают закупка и база, а не качество продукта.

Подробно

Проверьте себя«Версия B дала больше DAU — она лучше?» Нет: DAU — метрика роста; сравнивайте retention и конверсию новых пользователей.

14Продукт

Срез по пост-эффектной переменной

СутьОпасно читать результат A/B в срезе, который сам зависит от воздействия (например «активные пользователи», где активность — следствие фичи). Кондиционирование на пост-эффектной переменной ломает рандомизацию и даёт ложный вывод.

Когда важноВсегда при анализе эксперимента «по сегментам», особенно если сегмент определяется поведением уже после старта теста.

Зачем бизнесу«В срезе активных метрика выросла» → раскатали на всех → общая метрика просела. Классическая ловушка ценой релиза.

Главная ошибкаСегмент-следствие — делить тест и контроль по переменной, на которую влияет сама фича: группы перестают быть сравнимыми (collider / selection bias).

Правило: срезы A/B допустимы только по переменным, зафиксированным до старта (страна, платформа, стаж), но не по тому, что меняет сама фича.

Подробно

ПримерФича повышает «активность»; в срезе активных всё растёт, но это разный состав людей в тесте и контроле — сравнение невалидно.

Проверьте себя«Переменная вашего среза определена до или после воздействия?» Если после — вывод по срезу ненадёжен.

15Продукт

Опросы, NPS и качественные данные

СутьКоличественные данные говорят «что», качественные (интервью, опросы, NPS/CSAT, записи сессий) — «почему». Триангуляция quant + qual сильнее любой стороны. Но опросы смещены: отвечают не все, и говорят не то, что делают.

Когда важноКогда поведенческие данные показывают аномалию без причины; для CX, удовлетворённости и генерации гипотез.

Зачем бизнесу«Аналитик-детектив»: цифры находят проблему, интервью объясняют её. NPS — простой барометр лояльности, но не диагноз.

Главная ошибкаОпрос как доказательство — решать по опросу без поправки на эффект отбора и разрыв «слова ≠ дела»; или копить NPS, не понимая его драйверов.

Подробно

ПримерПадение retention объясняет не дашборд, а 8–10 интервью с ушедшими пользователями.

Проверьте себя«Почему словам в опросе нельзя верить как поведению?» → эффект отбора + декларируемое ≠ реальное.

Marketing Analytics

Оптимизировать траты на привлечение и удержание и растить ценность клиента. Суть — не «сколько лидов», а «сколько инкрементальной прибыли на вложенный рубль» и как устроен путь клиента.

01Маркетинг

Юнит-экономика: CAC, LTV, окупаемость

СутьCAC — стоимость привлечения клиента. LTV — суммарная прибыль с него за всё время. Ключевые отношения: LTV/CAC (здоровый ориентир ≈ 3) и payback period — за сколько месяцев CAC возвращается.

Когда важноПрежде чем масштабировать привлечение: канал «сходится», только если LTV уверенно перекрывает CAC в приемлемый срок.

Зачем бизнесуЭто граница между прибыльным ростом и сжиганием денег. Payback важен для денежного потока: длинный payback убивает кассу даже при хорошем LTV/CAC.

Главная ошибкаLTV по выручке, а не по марже — завысить LTV, игнорируя себестоимость и отток; масштабировать убыточное привлечение.

Подробно

Проверьте себя«LTV/CAC = 5 — это хорошо?» Не всегда: может означать недоинвестирование в рост. И проверьте payback — касса важнее красивого отношения.

02Маркетинг

Воронка привлечения и её метрики

СутьПоказы → клики (CTR) → стоимость клика (CPC) или тысячи показов (CPM) → действие (CPA) → конверсия в покупку (CR). Цепочка стоимости от показа до клиента.

Когда важноДля диагностики: дорогой CAC — это дорогой клик, слабый CTR или низкая конверсия лендинга? Лечение разное.

Зачем бизнесуРаскладывает CAC на управляемые рычаги: креатив (CTR), таргетинг (CPC), посадочная (CR).

Главная ошибкаОптимизировать верх воронки — гнать дешёвые клики, которые не конвертируются: дешёвый CPC при дорогом CAC.

Подробно

Проверьте себя«CPC упал, а CAC вырос — как так?» Кликов больше, но они хуже конвертируются: проблема в качестве трафика или лендинге.

03Маркетинг

Атрибуция и её кризис

СутьМодели приписывания заслуги касаниям: last-click, first-click, линейная, time-decay, data-driven. Все они делят «кредит» за конверсию, но ни одна не отвечает на главный вопрос — что было бы без канала.

Когда важноПри распределении бюджета между каналами — и здесь атрибуция системно врёт.

Зачем бизнесуПонимать ограничение: last-click перехваливает нижние каналы (брендовый поиск, ретаргет), которые собирают уже готовых клиентов.

Главная ошибкаБюджет по last-click — резать верх воронки, потому что «он не конвертит», и переливать в каналы-сборщики готового спроса.

Суть проблемы: атрибуция отвечает «кому приписать», но не «что дало инкрементальный результат». Второе важнее — см. следующую карточку.

Подробно

Проверьте себя«Почему last-click опасен для распределения бюджета?» Хвалит каналы, ловящие уже готовых, и наказывает создающие спрос.

04Маркетинг

Инкрементальность — настоящий вопрос

СутьНе «кому приписать конверсию», а «сколько конверсий не случилось бы без этой траты». Измеряется причинно: geo-холдауты, эксперименты с отключением, marketing mix modeling (MMM).

Когда важноОсобенно после краха пользовательской атрибуции (iOS ATT, смерть сторонних кук) — точное пер-юзер отслеживание ушло.

Зачем бизнесуТолько инкрементальность показывает истинный ROI канала и спасает от оплаты конверсий, которые произошли бы и так.

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

Подробно

Проверьте себя«Как доказать ценность канала без cookie-трекинга?» Geo-холдаут или MMM — причинные методы, а не атрибуция по кликам.

05Маркетинг

ROI, ROAS, ROMI и насыщение

СутьROAS — выручка на рубль рекламы; ROMI/ROI — с учётом маржи и затрат. Критично различать средний (blended) и маржинальный ROAS: у каждого канала есть кривая насыщения — следующий рубль приносит меньше предыдущего.

Когда важноПри решении «доливать ли в канал»: средний ROAS высокий, а маржинальный уже мог уйти в минус.

Зачем бизнесуРешения о бюджете принимаются на марже, а не на среднем. Иначе масштабируешь канал за точку эффективности.

Главная ошибкаРешать по среднему ROAS — наращивать канал с хорошим средним, игнорируя падающую предельную отдачу.

Подробно

Проверьте себя«ROAS канала 400% — увеличиваем бюджет?» Только если маржинальный ROAS на следующем рубле ещё выше порога.

06Маркетинг

Идеальная оптимизация привлечения

СутьЦель — распределить бюджет так, чтобы предельная отдача (маржинальный ROI) во всех каналах сравнялась. Пока в одном канале следующий рубль приносит больше, чем в другом, — деньги надо переложить.

Когда важноПри планировании медиамикса; это портфельная задача, а не выбор «лучшего канала».

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

Главная ошибка«Всё в самый дешёвый CPA» — концентрировать бюджет в одном канале до его насыщения вместо балансировки предельной отдачи.

Подробно

Проверьте себя«Как понять, что бюджет распределён оптимально?» Когда предельный рубль в любом канале даёт одинаковую инкрементальную отдачу.

07Маркетинг

CJM — карта пути клиента

СутьCustomer Journey Map: стадии (узнавание → рассмотрение → покупка → удержание → рекомендация), касания, эмоции и боли на каждом шаге.

Когда важноЧтобы увидеть путь глазами клиента и найти разрывы между каналами и отделами, а не оптимизировать шаги изолированно.

Зачем бизнесуСвязывает маркетинг, продукт и поддержку вокруг единого опыта; вскрывает, где теряются клиенты на стыках.

Главная ошибкаCJM-картинка для презентации — нарисовать и забыть, не привязав к метрикам и реальным точкам отвала.

Подробно

Проверьте себя«Чем CJM полезнее воронки?» Добавляет эмоции, каналы и стыки между отделами — видно не только «где», но и «почему» отваливаются.

08Маркетинг

CVM и RFM-сегментация

СутьCustomer Value Management — управление ценностью базы через её жизненный цикл: сегментация (в т. ч. RFM — давность, частота, сумма покупок), модели склонности и оттока, next-best-action, реактивация.

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

Зачем бизнесуУдержать и развить существующего клиента дешевле, чем привлечь нового; CVM системно растит LTV базы.

Главная ошибкаОдно предложение на всех — массовые рассылки без сегментов и без uplift: жгут бюджет на тех, кто купил бы и так.

Подробно

Проверьте себя«Что такое RFM и зачем он?» Быстрая сегментация по поведению покупок — основа для дифференцированных предложений.

09Маркетинг

Когортный LTV, отток, реактивация

СутьLTV растёт из кривой удержания когорт; отток (churn) — обратная сторона; реактивация возвращает ушедших. Считать по когортам, а не «в среднем по больнице».

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

Зачем бизнесуРаннее ухудшение удержания новых когорт — сигнал проблемы задолго до падения выручки.

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

Подробно

Проверьте себя«Почему LTV считают по когортам?» Чтобы видеть тренд удержания свежих клиентов, а не маскирующее среднее.

10Маркетинг

Brand против performance

СутьPerformance — измеримый отклик «здесь и сейчас». Brand — отложенный спрос и снижение будущего CAC. Исследования Binet & Field: устойчивый ориентир ≈ 60% бренд / 40% performance в долгую.

Когда важноПри балансе краткосрочных продаж и долгосрочного роста; performance легко переоценить, потому что он измерим.

Зачем бизнесуТолько performance ⇒ исчерпание готового спроса и рост CAC. Бренд наполняет верх воронки и удешевляет привлечение завтра.

Главная ошибкаРезать то, что не измеряется — обнулить бренд, потому что его эффект отложен и труднее атрибутируется, и упереться в потолок performance.

Подробно

Проверьте себя«Performance окупается лучше — отключаем бренд?» Нет: измеримость ≠ полная ценность; без бренда CAC со временем растёт.

11Маркетинг

Ценовая аналитика и промо

СутьЦеновая эластичность — как спрос реагирует на цену. Промо-аналитика отделяет инкрементальные продажи от каннибализации (скидка тем, кто купил бы по полной) и сдвига спроса во времени.

Когда важноПри ценообразовании и акциях — самый быстрый рычаг прибыли и самый легко сливаемый бюджет.

Зачем бизнесуЦена влияет на прибыль сильнее объёма; неуправляемое промо часто уносит маржу без прироста новых покупателей.

Главная ошибкаСчитать промо по валовым продажам — праздновать рост в акцию, не вычтя каннибализацию и pull-forward (продажи, занятые из будущего).

Подробно

Проверьте себя«Акция дала +30% продаж — успех?» Сначала вычтите тех, кто купил бы и так, и будущий спрос, занятый акцией.

12Маркетинг

Каннибализация: каналы и продукты

СутьНовый канал или продукт может не создавать спрос, а перетягивать его у своих же. Каннибализация каналов (брендовый поиск «съедает» органику, ретаргет — прямые заходы) и продуктов (новый SKU забирает продажи старого).

Когда важноЗапуск нового канала, продукта, тарифа; оценка инкрементальности внутри собственного портфеля.

Зачем бизнесуРост канала/продукта на бумаге может быть нулевым для компании — спрос переложили из кармана в карман, да ещё и заплатили за это.

Главная ошибкаСчитать валовый эффект — праздновать продажи нового, не вычтя упавшие продажи старого и переток уже-нашего спроса (нужен холдаут).

Подробно

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

Проверьте себя«Новый продукт дал +1000 продаж — это рост компании?» Только за вычетом каннибализации старого.

13Маркетинг

Рекламные аукционы и монетизация

СутьКак площадка зарабатывает на показах: аукцион (часто второй ценой / GSP — платишь ставку следующего), ранжирование объявлений по ожидаемому доходу (ставка × вероятность клика, bid×pCTR), RTB в реальном времени. Баланс дохода и качества выдачи.

Когда важноПоисковые и рекламные платформы, маркетплейсы (ранжирование выдачи и промо-полок), ad-tech.

Зачем бизнесуМонетизация — отдельная дисциплина от привлечения (CAC/ROAS); неверный аукцион роняет либо доход, либо качество и удержание пользователей.

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

Подробно

ПримерАукцион второй цены: при CPM-инвентаре и неограниченном бюджете весь инвентарь выкупает ставка выше топовой; объявления ранжируют по bid×pCTR, а не по голой ставке.

Проверьте себя«Зачем аукцион второй цены и почему ранжируют по bid×pCTR?» → правдивость ставок + учёт качества и ожидаемого дохода.

14Маркетинг

P&L и экономика сервиса

СутьПрибыльность сервиса целиком: P&L = выручка − прямые и косвенные затраты (контент, инфраструктура, поддержка, фикс). Юнит-экономика (на пользователя/сделку) ≠ P&L (весь сервис с общими затратами). Contribution margin — что остаётся после переменных затрат.

Когда важноОценка прибыльности продукта/подписки, защита бюджета, вопрос «сходится ли сервис в целом».

Зачем бизнесуПоложительная юнит-экономика при отрицательном P&L — частая ловушка: общие и контентные затраты съедают прибыль. Решают по обоим.

Главная ошибкаЮнит-экономика вместо P&L — радоваться LTV>CAC, игнорируя косвенные затраты, и считать сервис прибыльным, когда P&L в минусе.

Подробно

ПримерПодписка: маржа на пользователе плюсовая, но лицензии на контент и инфраструктура держат P&L в минусе до масштаба.

Проверьте себя«Чем юнит-экономика отличается от P&L сервиса?» → юнит — на единицу; P&L — весь сервис с общими и косвенными затратами.

BI — Business Intelligence

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

01BI

Когда и зачем вводить метрику

СутьМетрика имеет право на жизнь, только если она двигает решение и у неё есть владелец. Иначе — разрастание метрик (metric sprawl), за которым теряется сигнал.

Когда важноПри каждом запросе «давайте отслеживать ещё и это»: сначала вопрос — какое решение изменит эта метрика.

Зачем бизнесуМеньше, но осмысленных метрик = фокус и подотчётность. Сотня показателей без владельцев = шум, которому никто не верит.

Главная ошибкаМетрика без владельца и решения — добавлять показатели «чтобы были»; дашборд превращается в обои.

Подробно

Проверьте себя«Команда просит добавить метрику — ваш первый вопрос?» «Какое решение ты примешь, когда она изменится?»

02BI

Input против output, leading против lagging

СутьOutput/lagging-метрики (выручка, отток) — итог, на который нельзя нажать напрямую. Input/leading-метрики (звонки, активации, время загрузки) — рычаги, которыми управляешь и которые предсказывают итог.

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

Зачем бизнесуУправление идёт по input-метрикам; output — это контроль результата. Lagging-цель без leading-рычагов недостижима усилием воли.

Главная ошибкаУправлять по lagging — ставить команде цель по выручке без input-метрик, которыми она реально управляет.

Подробно

Проверьте себя«Выручка — leading или lagging?» Lagging-итог; управляют им через input-рычаги (трафик, конверсия, удержание).

03BI

Дизайн метрики — спецификация

СутьУ зрелой метрики есть спека: точное определение, гранулярность, владелец, целевое значение, разрезы (сегменты) и actionability. «Активный пользователь» без определения — повод для вечных споров.

Когда важноДо того, как метрика попала на дашборд и в KPI: иначе разные команды посчитают её по-разному.

Зачем бизнесуОдно определение = один разговор о деле, а не о том, чьи цифры правильные.

Главная ошибкаМетрика без определения — «конверсия» считается пятью способами; совещания уходят на сверку цифр.

Подробно

Проверьте себя«Две команды принесли разную выручку — почему?» Почти всегда — разные определения и гранулярность, а не ошибка в данных.

04BI

Дерево метрик (driver tree)

СутьДекомпозиция верхней метрики на драйверы по принципу MECE (взаимоисключающе и исчерпывающе): Выручка = Пользователи × Конверсия × Средний чек. Дальше каждый множитель раскладывается ниже.

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

Зачем бизнесуСвязывает стратегию с ежедневной работой: каждая команда видит свой узел и как он двигает вершину.

Главная ошибкаНе-MECE декомпозиция — пересекающиеся или неполные ветви: при сложении драйверы не дают вершину, анализ рассыпается.

Подробно

Проверьте себя«Разложите выручку на драйверы». Множители, дающие при перемножении выручку и не пересекающиеся между собой.

05BI

Semantic (metrics) layer

СутьСлой, где метрики и сущности определены один раз и переиспользуются всеми инструментами (LookML, dbt metrics, Cube). Определение «выручки» живёт в коде слоя, а не в каждом дашборде.

Когда важноКогда инструментов и дашбордов много, а цифры расходятся: слой — лекарство от «у каждого свой SQL».

Зачем бизнесуЕдиный источник правды и доверие к цифрам; ускоряет self-service и делает GenAI-аналитику (text-to-SQL) безопасной.

Главная ошибкаОпределения в дашбордах — логика метрики копируется по отчётам; изменили в одном месте — разъехалось везде.

Подробно

Проверьте себя«Где должна жить формула метрики?» В semantic layer — один раз для всех потребителей, а не в каждом дашборде.

06BI

Виды дашбордов: под аудиторию и темп

СутьСтратегический (для руководства): верхнеуровневые KPI и тренды, периодичный, для «руления». Операционный: near-real-time, мониторинг и алерты, для «бега» операционки. Аналитический: drill-down и exploration, для расследования «почему».

Когда важноТип дашборда выбирается под темп решений аудитории, а не «давайте универсальный для всех».

Зачем бизнесуРуководителю — несколько KPI с трендом; оператору — живые числа и алерты; аналитику — глубину. Разные задачи.

Главная ошибкаОдин дашборд на всех — впихнуть real-time, стратегию и drill-down вместе: перегруз, которым не пользуется никто.

Подробно

Проверьте себя«Дашборд для CEO и для дежурного инженера — одинаковые?» Нет: разный темп, глубина и набор метрик.

07BI

Принципы дизайна дашборда

СутьСначала аудитория и её решение; сверху-вниз (обзор → детали); всегда контекст (цель, бенчмарк, прошлый период); высокий data-ink ratio (минимум украшательств); преаттентивные признаки (цвет, размер) для главного. «5-секундный тест»: считывается ли суть за 5 секунд.

Когда важноПри каждом дашборде — плохой дизайн прячет сигнал в шуме и убивает доверие.

Зачем бизнесуЦель дашборда — быстрое верное решение, а не «красивая картинка». Контекст превращает число в вывод.

Главная ошибкаЧисло без контекста — «выручка 5 млн» без цели и прошлого периода: непонятно, это хорошо или провал.

Подробно

Проверьте себя«Что добавить к одинокой цифре, чтобы она стала выводом?» Цель, прошлый период или бенчмарк — контекст «хорошо это или плохо».

08BI

Self-service и управление дашбордами

СутьБаланс свободы (любой строит свой отчёт) и порядка: сертифицированные («золотые») дашборды против ad-hoc, владельцы, депрекейшен неиспользуемого. Борьба с разрастанием (dashboard sprawl).

Когда важноКогда дашбордов сотни, половина дублирует друг друга и противоречит цифрами.

Зачем бизнесуSelf-service снимает узкое место аналитики, но без курирования рождает хаос версий правды.

Главная ошибкаСвобода без курирования — раздать BI всем без сертификации и чистки: «кладбище дашбордов», которым не доверяют.

Подробно

Проверьте себя«Self-service породил 300 дашбордов — что делать?» Сертификация ключевых, владельцы, депрекейшен по использованию.

09BI

BI — это не вся аналитика

СутьBI отвечает «что произошло» (отчётность, мониторинг). Аналитика идёт дальше — «почему и что делать». Это разные роли и навыки, их часто путают.

Когда важноПри оргдизайне и найме: дашборд-фабрика не заменяет аналитиков, решающих задачи.

Зачем бизнесуПонимать границу: вложиться только в BI ⇒ хорошая отчётность без инсайтов и рекомендаций.

Главная ошибкаСчитать дашборды аналитикой — ждать инсайтов от отчётности; BI показывает «что», но не объясняет «почему».

Подробно

Проверьте себя«Чем работа аналитика отличается от BI-разработчика?» BI отвечает «что», аналитик — «почему и что делать».

Data Analytics — ремесло аналитика

Базовое ремесло, на котором стоит всё: превратить бизнес-вопрос в ответ и довести до решения. Не про инструмент, а про мышление — структурировать задачу, не обмануться данными, донести вывод.

01Аналитика

Аналитический workflow

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

Когда важноВ каждой задаче: половина провалов — это блестящий анализ не того вопроса.

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

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

Подробно

Проверьте себя«С чего начинается анализ?» С вопроса и решения, которое он обслуживает, а не с выгрузки данных.

02Аналитика

Гипотезы, issue trees, MECE

СутьСтруктурировать задачу деревом вопросов (issue tree) по принципу MECE — ветви не пересекаются и покрывают всё. Двигаться гипотезами: сначала версия, потом проверка, а не «посмотрим, что в данных».

Когда важноНа больших размытых вопросах («почему падает прибыль») — дерево не даёт утонуть и пропустить ветвь.

Зачем бизнесуГипотезный подход экономит время: проверяешь самые вероятные причины первыми, а не перебираешь всё подряд.

Главная ошибкаАнализ без структуры — копать данные без гипотез и дерева: бесконечные графики, из которых не складывается ответ.

Подробно

Проверьте себя«Что значит MECE?» Ветви взаимоисключающие и вместе исчерпывающие — без пересечений и пропусков.

03Аналитика

Распределения: среднее врёт

СутьСреднее обманывает на скошенных данных и длинных хвостах; медиана и перцентили честнее. Смотреть форму распределения, а не одну точку. «Средняя температура по больнице».

Когда важноДоходы, время отклика, чек, длительность сессии — почти всё в бизнесе распределено несимметрично.

Зачем бизнесуРешения по среднему там, где правит хвост (p95 латентности, топ-1% клиентов по выручке), системно ошибочны.

Главная ошибкаОдно среднее вместо распределения — «средний чек вырос» при том, что медиана упала, а вытянул хвост из пары крупных сделок.

Подробно

Проверьте себя«Среднее или медиана для дохода?» Медиана и перцентили: доход скошен, среднее тянут редкие большие значения.

04Аналитика

Статграмотность и доверие выборке

СутьБазовый аппарат: выборка против генеральной совокупности, доверительные интервалы, проверка гипотез, размер эффекта. Маленькая выборка → широкий интервал → осторожные выводы.

Когда важноПри любом выводе «X больше Y»: различие может быть в пределах случайного шума.

Зачем бизнесуЗащищает от решений по шуму: «в этом сегменте конверсия выше» на 30 наблюдениях — чаще всего случайность.

Главная ошибкаВыводы по малой выборке — праздновать различие, которое целиком умещается в доверительный интервал.

Подробно

Проверьте себя«Сегмент из 25 человек конвертит в 2 раза лучше — действуем?» Сначала доверительный интервал: вероятно, это шум.

05Аналитика

Смещения: selection, survivorship

СутьSelection bias — выборка нерепрезентативна (опрос только активных). Survivorship bias — смотрим только на «выживших» (успешные компании, оставшиеся клиенты), теряя проигравших. Систематический перекос данных, а не случайность.

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

Зачем бизнесуСмещения ведут к уверенно неверным выводам: «наши клиенты довольны» — потому что недовольные уже ушли и в опрос не попали.

Главная ошибкаУчиться на выживших — копировать практики успешных, не видя тех, кто делал так же и провалился (классика: самолёты Вальда).

Подробно

Проверьте себя«Опросили оставшихся клиентов — они довольны. Вывод?» Осторожно: недовольные уже ушли — это survivorship bias.

06Аналитика

Root cause: «метрика упала — почему»

СутьСистемный разбор движения метрики по чек-листу: сегмент (где именно?), время (когда началось?), внешнее (рынок, сезон), mix shift (изменилась структура), смена определения, баг в данных. Сначала исключить артефакт, потом искать причину.

Когда важноСамый частый запрос к аналитике: «почему упало/выросло». От скорости и структуры разбора зависит доверие.

Зачем бизнесуСтруктура экономит часы и не даёт принять баг в данных или сезонность за реальную проблему.

Главная ошибкаХвататься за первую версию — не проверив, не сломалось ли логирование и не изменилось ли определение метрики.

Подробно

Проверьте себя«Конверсия упала на 5% — первые три проверки?» Баг в данных / смена определения → сегмент и время → внешние факторы и mix.

07Аналитика

Mix shift и парадокс Симпсона

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

Когда важноКогда «средняя конверсия упала», хотя в каждом сегменте она выросла — просто вырос трафик из слабого сегмента.

Зачем бизнесуБез разбивки по сегментам легко принять mix-эффект за реальную деградацию и «лечить» не то.

Главная ошибкаВерить агрегату — делать вывод по общей цифре, не проверив, не сменилась ли структура (доли сегментов, каналов, гео).

Подробно

Проверьте себя«Общая конверсия упала, в каждом сегменте — выросла. Как?» Сменились веса: больше трафика из сегмента с низкой базой (Симпсон).

08Аналитика

Storytelling with data

СутьДоносить вывод под аудиторию: рекомендация вперёд (BLUF — bottom line up front), принцип пирамиды Минто (ответ → аргументы → данные), правильный выбор графика, язык решений, а не таблиц.

Когда важноНа «последней миле»: верный анализ без донесения не меняет ни одного решения.

Зачем бизнесуРуководитель действует по понятому выводу, а не по самому точному. Подача = условие влияния.

Главная ошибкаВести от данных к выводу — заставлять занятого стейкхолдера пройти весь ваш путь анализа вместо «вот вывод, вот почему».

Подробно

Проверьте себя«С чего начать презентацию анализа для CEO?» С рекомендации и вывода, а не с методологии и данных (BLUF / пирамида).

09Аналитика

Оценки и прикидки (sizing)

СутьУмение прикинуть порядок величины «на салфетке» (back-of-envelope), проверять цифры на здравый смысл (sanity-check), декомпозировать оценку на понятные множители.

Когда важноКогда нужен быстрый ответ «это вообще про миллион или про миллиард», до полноценного анализа; и чтобы ловить абсурдные результаты.

Зачем бизнесуБыстрая прикидка отсекает заведомо нежизнеспособные идеи за минуты и страхует от ошибок на порядок в выгрузках.

Главная ошибкаПринять число без sanity-check — выдать результат, отличающийся от реальности на порядок, потому что «так посчитал SQL».

Подробно

Проверьте себя«Запрос вернул выручку вдвое больше годовой выручки компании — что делаете?» Не публикуете: sanity-check провален, ищете задвоение.

10Аналитика

Прогнозирование

СутьОценка будущего из истории: разложить ряд на тренд, сезонность и шум; начинать с наивных базлайнов (последнее значение, «прошлый год × рост»), потом усложнять. Прогноз без интервала неполон.

Когда важноПланирование спроса, бюджета, мощностей, найма; финансовые таргеты.

Зачем бизнесуТочность прогноза = деньги (закупка, склад, штат); честный интервал неопределённости важнее красивой точечной цифры.

Главная ошибкаСложная модель без базлайна и интервала — ML-прогноз, не бьющий «прошлый год × сезонность»; и точечный прогноз без диапазона.

Подробно

Проверьте себя«Ваш прогноз лучше наивного «как в прошлом году с поправкой на сезон»?» Если нет — сложная модель не нужна.

11Аналитика

Оценки по Ферми и экономика «на салфетке»

СутьПрикинуть порядок величины через декомпозицию на понятные множители (рынок, юнит-экономика, окупаемость закупки трафика). Цель — не точность, а быстрый разумный ответ и проверка на здравый смысл.

Когда важноИнтервью и стратегия: «выгодно ли покупать трафик», «какой объём рынка», «хватит ли маржи», «какой CPM выкупит инвентарь».

Зачем бизнесуОтсекает заведомо нежизнеспособные идеи за минуты до дорогого анализа и ловит ошибки на порядок.

Главная ошибкаТочность вместо порядка — тонуть в данных, когда нужна прикидка; или прикидывать без проверки допущений (мусорные множители → мусорный ответ).

Правило закупки: трафик «сходится», только если выручка с привлечённого за разумный срок больше, чем стоимость клика ÷ конверсию в установку/платёж.

Подробно

ПримерКлик 10 коп., конверсия в установку 10% → CAC ≈ 1 ₽; если пользователь приносит 1 ₽/день и живёт недели — выгодно.

Проверьте себя«Покажите расчёт окупаемости закупки трафика за 30 секунд» — типичный вопрос на собеседовании.

12Аналитика

План против факта: анализ отклонений

СутьСравнение факта с планом/прогнозом/прошлым периодом и разложение отклонения на драйверы: эффект цены × объёма × микса (price/volume/mix). Не «на сколько отклонились», а «из-за чего».

Когда важноЕжедневно в финансах, продажах, операциях; в любом ритуале обзора метрик.

Зачем бизнесуОтклонение без декомпозиции — тревога без действия; разложение указывает, что именно чинить (упал объём? просела цена? сместился микс?).

Главная ошибкаОтклонение без причины — констатировать «минус 8% к плану» без разложения на драйверы; и сравнивать с плохим планом, не пересматривая базу.

Подробно

ПримерВыручка ниже плана: объём вырос, но микс сместился в дешёвый сегмент и средняя цена упала — лечить микс, а не объём.

Проверьте себя«Метрика ниже плана — назовите вклад цены, объёма и микса по отдельности».

13Аналитика

Сегментирующие вопросы — рефлекс №1

СутьПервая реакция аналитика на любой агрегат — разрезать его: где? у кого? когда? на какой платформе? в каком сегменте? «Среднее по больнице» почти всегда прячет ответ в разрезах.

Когда важноЕжедневно — это самый частый и дешёвый диагностический приём.

Зачем бизнесуПравильный вопрос «в каком срезе?» экономит часы и сразу сужает поиск причины; половина инсайтов — это просто верная разбивка.

Главная ошибкаСпорить об агрегате — обсуждать общую цифру, не спросив «а по сегментам?»; агрегат скрывает и проблему, и её причину (см. Симпсон).

Подробно

Пример«Конверсия упала» → разрез по платформе показывает: просел только Android после релиза.

Проверьте себя«Прежде чем объяснять движение метрики — в каких срезах вы её посмотрели?»

14Аналитика

Дизайн метрик с нуля и измерение качества

СутьКак измерить то, у чего нет очевидной метрики (качество поиска, UX, «эффективность» использования ресурса, новый сервис): определить цель → подобрать прокси и эталоны → оценить, насколько метрике можно доверять и как её обманут.

Когда важноНовый продукт или фича, оценка алгоритма, вопрос «какие метрики на дашборд сервиса».

Зачем бизнесуБез продуманной метрики команда оптимизирует случайность или тщеславие; хорошая метрика actionable и устойчива к накрутке.

Главная ошибкаУдобная метрика вместо верной — мерить то, что легко считать (клики), а не то, что отражает ценность; и не подумать, как метрику обманут.

Подробно

ПримерКачество ранжирования: эталоны асессоров + поведение + A/B; для каждой метрики — источник и степень доверия.

Проверьте себя«Как измерить качество фичи, у которой нет готовой метрики — и как её можно накрутить?»

Growth Analytics

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

01Рост

Зачем нужна Growth Analytics

СутьСвязать разрозненные усилия (маркетинг + продукт + монетизация) в единую модель роста и системно искать, где жать. Это про систему и петли, а не про отдельные «фишки».

Когда важноКогда рост важнее «своей зоны» каждого отдела, а узкое место кочует между привлечением, активацией и удержанием.

Зачем бизнесуБез сквозного взгляда команды локально оптимизируют свои метрики, а общий рост стоит. Growth смотрит на систему целиком.

Главная ошибкаКоллекция хаков — путать growth с набором трюков вместо системного процесса поиска и проверки рычагов.

Подробно

Проверьте себя«Чем growth отличается от маркетинга?» Кросс-функционален и про всю петлю (включая продукт и удержание), а не только привлечение.

02Рост

Модель и уравнение роста

СутьБизнес как система: рост базы = новые + реактивированные − ушедшие; North Star раскладывается на input-метрики. Модель количественно связывает рычаги с результатом.

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

Зачем бизнесуПоказывает, что даёт больше — снизить отток на 1 п. п. или поднять привлечение на 10%; часто удержание выгоднее.

Главная ошибкаРасти только привлечением — лить в верх воронки, игнорируя отток: дорогой рост, упирающийся в «дырявое ведро».

Подробно

Проверьте себя«Что даст больше роста — +10% привлечения или −1 п. п. оттока?» Зависит от модели; на удержании эффект часто компаундится.

03Рост

Петли роста против воронок

СутьВоронка линейна и затухает (залил трафик — кончился). Петля (loop) реинвестирует выход во вход: вирусная, контентная, платная, sales-петля. Петли компаундятся, воронки — нет.

Когда важноПри проектировании устойчивого, а не разового роста: откуда берётся следующий пользователь из предыдущего.

Зачем бизнесуПетли дают самоподдерживающийся рост с убывающей стоимостью; воронка требует постоянной внешней подпитки деньгами.

Главная ошибкаМыслить только воронкой — строить рост на покупке трафика, не выстроив петлю, которая порождает новый спрос из текущих пользователей.

Подробно

Проверьте себя«Чем петля лучше воронки?» Выход петли питает её вход — рост компаундится, а не затухает с окончанием бюджета.

04Рост

AARRR и приоритизация ICE/RICE

СутьКарта рычагов — пиратские метрики (Acquisition → Activation → Retention → Referral → Revenue). Поток идей приоритизируется по ICE (Impact × Confidence × Ease) или RICE (+ Reach), чтобы тестировать самое выгодное первым.

Когда важноКогда гипотез роста десятки, а ресурсов мало: нужна прозрачная очередь, а не «чья идея громче».

Зачем бизнесуДисциплина приоритизации максимизирует выученные уроки и эффект на единицу усилий.

Главная ошибкаТестировать по интуиции — брать идеи по симпатии, без оценки охвата, эффекта и стоимости проверки.

Подробно

Проверьте себя«Что в ICE/RICE и зачем Confidence/Ease?» Чтобы не гнать дорогую низкоуверенную идею вперёд дешёвой и вероятной.

05Рост

High-tempo testing — движок роста

СутьРост — это не отдельные эксперименты, а темп: много дешёвых проверок в единицу времени с быстрым циклом «гипотеза → тест → вывод → следующая». Главная метрика процесса — скорость обучения.

Когда важноКогда заранее неизвестно, что сработает (а это почти всегда): выигрывает не угадавший, а быстрее перебравший.

Зачем бизнесуБольше качественных проверок ⇒ больше находок. Это и есть конкурентное преимущество в эпоху дешёвых идей.

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

Подробно

ГлубжеДизайны и защита выводов на высоком темпе — раздел exp.chu.st.

Проверьте себя«Главная метрика growth-команды?» Скорость качественного обучения (валидных тестов в неделю), а не число запусков.

06Рост

Рычаги: активация и удержание — фундамент

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

Когда важноПеред тем как масштабировать привлечение: чинить удержание раньше, чем заливать трафик.

Зачем бизнесуУлучшение удержания усиливает все остальные рычаги сразу (LTV, виральность, окупаемость) — это рычаг с наибольшим плечом.

Главная ошибкаЧинить привлечение при дырявом ведре — самый дорогой и частый способ «расти» в минус.

Подробно

Проверьте себя«С какого рычага начать рост?» Обычно с удержания/активации: усиливают все остальные и определяют, есть ли вообще что масштабировать.

07Рост

PLG, freemium и expansion

СутьProduct-led growth — продукт сам привлекает и удерживает (freemium, trial, виральность), в отличие от sales-led. Ключ к экономике подписки — expansion: NRR (net revenue retention) и GRR (gross). NRR > 100% = база растёт даже без новых клиентов.

Когда важноВ SaaS и подписках: где модель роста (PLG vs sales-led) определяет всю воронку и метрики.

Зачем бизнесуВысокий NRR — самый здоровый рост: существующие клиенты доплачивают и расширяются. Дешевле любого привлечения.

Главная ошибкаГнать новых при низком NRR — заливать привлечение в продукт, из которого деньги вытекают через отток и даунгрейды.

Подробно

Проверьте себя«Что значит NRR 120%?» База существующих клиентов за год выросла в доходе на 20% за счёт расширения, даже без новых.

08Рост

Привычка и петли вовлечения

СутьУстойчивое удержание держится на привычке: модель Hook (триггер → действие → переменное вознаграждение → инвестиция) и engagement loops, возвращающие пользователя.

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

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

Главная ошибкаТёмные паттерны вместо ценности — строить «привычку» на манипуляциях; даёт краткий всплеск и долгий отток и репутационный ущерб.

Подробно

Проверьте себя«Чем переменное вознаграждение усиливает привычку?» Непредсказуемость отклика повышает вовлечённость (как лента/уведомления).

09Рост

Где growth уместен, а где карго-культ

СутьGrowth-подход (быстрые эксперименты, петли, PLG) расцветает в high-frequency / low-friction бизнесах: consumer, SaaS, маркетплейсы. В enterprise с долгим циклом и малым числом крупных сделок он работает слабо.

Когда важноПеред тем как копировать «growth как в Facebook»: подходит ли он вашей модели вообще.

Зачем бизнесуПонимать границы метода — признак зрелости: где A/B и петли уместны, а где решают отношения и сложные продажи.

Главная ошибкаКарго-культ роста — внедрять high-tempo A/B там, где сделок десятки в квартал: статистики нет, метод не работает.

Подробно

Проверьте себя«Где growth-подход не сработает?» В enterprise с долгим циклом и малым числом сделок — нет объёма для экспериментов.

10Рост

Баланс спроса и предложения (двусторонние рынки)

СутьНа маркетплейсе растят обе стороны согласованно: ликвидность (быстро ли спрос находит предложение), здоровье каждой стороны, take rate, GMV, доля 1P/3P. Перекос убивает: лишний спрос без предложения = пустой поиск и отток.

Когда важноМаркетплейсы, платформы, two-sided бизнесы (такси, доставка, объявления, найм).

Зачем бизнесуИнвестировать надо в дефицитную сторону; метрики ликвидности (fill rate, время до матча, доля удачных поисков) важнее общего GMV.

Главная ошибкаКачать одну сторону — лить спрос, когда узкое место — предложение (или наоборот): деньги на привлечение уходят в неудовлетворённость и отток.

Подробно

ПримерВ такси утром не хватает водителей: привлечение пассажиров только ухудшает время подачи и бьёт по обеим сторонам.

Проверьте себя«Какая сторона у вас дефицитна — и почему инвестиции туда, а не в рост спроса?»

11Рост

Оценка рынка: TAM/SAM/SOM и нишевый выход

СутьTAM (весь рынок) ⊃ SAM (доступный вам сегмент) ⊃ SOM (реально достижимая доля). Считается top-down (от рынка) и bottom-up (от юнитов) со сверкой. Выход — через нишу, где ценность в 10× сильнее (Facebook → Гарвард, Amazon → книги).

Когда важноСтратегия, новый продукт, инвест-кейс, приоритизация рынков.

Зачем бизнесуОтделяет «рынок на триллион» (TAM-сказка) от реально достижимого; нишевый захват эффективнее лобовой атаки на весь рынок.

Главная ошибкаТолько top-down TAM — продавать «1% от огромного рынка» без bottom-up проверки достижимости; и бить во весь рынок вместо плацдарма-ниши.

Подробно

ПримерBottom-up: число клиентов × частота × чек, сверить с top-down оценкой рынка — расхождение вскрывает кривое допущение.

Проверьте себя«Чем SOM отличается от TAM и почему инвесторы не верят в «1% рынка»?»

AI-аналитика

AI как усилитель аналитика в 2026: что делегировать, где он уверенно врёт, как меняется роль и как мерить AI-инициативы. Не отдельная магия, а новый инструмент со своими сильными сторонами и рисками. Грамотность по самим моделям (RAG, fine-tuning) — в карточке GenAI/LLM.

01AI

Промт-инжиниринг для аналитики

СутьКачество ответа AI = качество запроса. Структура промта: роль + контекст/данные + конкретная задача + формат вывода + ограничения; примеры (few-shot); итеративное уточнение. Те же «сегментирующие вопросы», но к модели.

Когда важноЕжедневно в 2026: черновики анализа, SQL, гипотезы, ресёрч, объяснения.

Зачем бизнесуХороший промт ускоряет рутину в разы; плохой даёт уверенный мусор, который дороже, чем ничего.

Главная ошибкаРасплывчатый промт — «проанализируй данные» без роли, контекста, цели и формата; и принять первый ответ без итерации и проверки.

Подробно

Пример«Ты аналитик. Вот схема таблиц … Нужен SQL для weekly retention по когортам, верни запрос + краткое пояснение и допущения».

Проверьте себя«Из чего состоит хороший промт?» → роль, контекст, задача, формат, ограничения + итерация.

02AI

AI против человека: что делегировать

СутьAI силён в объёме, черновиках, рутине, переборе и первом приближении; человек незаменим в постановке задачи, контексте, суждении, ответственности и проверке. Решение — не «или-или», а распределение по задаче и цене ошибки.

Когда важноПри выстраивании процессов аналитики в эпоху AI; дедлайны, масштаб.

Зачем бизнесуПравильное распределение кратно ускоряет; неверное либо тормозит (всё руками), либо роняет качество (всё AI без проверки).

Главная ошибкаКрайности — «AI сделает всё» (галлюцинации в проде) или «AI — игрушка» (упустить кратный рост скорости).

Подробно

ПримерAI пишет черновик дашборда и SQL — человек проверяет логику метрик и принимает решение.

Проверьте себя«Что нельзя делегировать AI?» → постановку вопроса, суждение в неоднозначности и ответственность за решение.

03AI

Риски AI: галлюцинации и проверяемость

СутьLLM уверенно выдаёт правдоподобную ложь (галлюцинации), чувствителен к формулировке, не знает свежего и приватного без подачи. Защита: проверяемость (источники, прогон кода/цифр), guardrails, человек в контуре на критичном.

Когда важноВсегда, когда вывод AI влияет на решение или попадает наружу.

Зачем бизнесуНедопроверенный AI-вывод = риск дорогой ошибки и репутации; цена проверки ниже цены ошибки на важном.

Главная ошибкаДоверие без проверки — брать цифры и факты от модели как истину; особенно опасно при авторитетном тоне на узких вопросах.

Правило: чем выше цена ошибки решения, тем обязательнее человек в контуре и сверка AI-вывода с источником.

Подробно

ПримерLLM «посчитала» метрику по описанию и ошиблась в определении — без semantic layer и прогона цифр это незаметно.

Проверьте себя«Как поймёте, что AI галлюцинирует на вашем вопросе?» → проверяемые источники и контрольный расчёт.

04AI

Text-to-SQL и почему он усиливает semantic layer

СутьAI переводит вопрос на естественном языке в SQL — снимает рутину и демократизирует доступ. Но без единых определений (semantic layer) модель уверенно соберёт «выручку» неправильно. Text-to-SQL повышает цену порядка в данных, а не снижает.

Когда важноПри внедрении self-service аналитики и AI-ассистентов поверх данных.

Зачем бизнесуУскоряет получение ответов бизнесом, но только поверх доверенного слоя метрик; иначе масштабирует ошибки.

Главная ошибкаText-to-SQL на хаосе — подключить AI к сырым таблицам без semantic layer: красивые, уверенные и неверные цифры.

Подробно

Проверьте себя«Почему text-to-SQL повышает, а не снижает важность semantic layer?» → без единых определений LLM уверенно соберёт метрику неверно.

05AI

Агентная аналитика и меняющаяся роль

СутьAI-агенты делают многошаговые задачи (сами пишут запросы, ищут аномалии, готовят черновик инсайта). Роль аналитика смещается от «написать SQL» к «поставить вопрос, проверить, интерпретировать, отвечать за вывод». Авто-инсайты находят кандидатов, а не истину.

Когда важноГоризонт 1–3 года при планировании функции, найма и инструментов.

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

Главная ошибкаАвтопилот без штурмана — доверять авто-инсайтам и агентам без верификации и владельца решения; они генерируют гипотезы, а не проверенные факты.

Подробно

ПримерАгент находит «аномалию», но это смена определения метрики; человек ловит артефакт.

Проверьте себя«Как меняется найм аналитиков в эпоху агентов?» → меньше за SQL, больше за вопросы, суждение и домен.

06AI

AI в продукте против AI в процессе аналитики

СутьДве разные вещи: AI как фича продукта (рекомендации, генерация, ассистент для пользователя — мерится продуктовыми метриками и A/B) и AI как инструмент работы аналитика (ускорение анализа — мерится продуктивностью). Их путают в метриках и рисках.

Когда важноПри планировании AI-инициатив и их оценке.

Зачем бизнесуAI-фичу оценивают эффектом на пользователя (как любую фичу), а AI-инструмент — продуктивностью команды; смешение ведёт к неверным KPI.

Главная ошибкаОдни мерки на оба — оценивать AI-фичу «по ощущению команды» или AI-инструмент «по выручке»: разные цели — разные метрики.

Подробно

ПримерЧат-ассистент в продукте проверяют A/B на удержание/конверсию; AI-copilot аналитика — по времени до инсайта.

Проверьте себя«Это AI-фича для пользователя или AI-инструмент для команды — и чем тогда мерить?»

Руководство функцией аналитики

То, что отличает руководителя аналитики от сильного аналитика: зачем функция существует, как она устроена, как связана со стратегией и как доказать её ценность. Это ядро разговора на собеседовании на Head of Analytics.

01Руководство

Зачем бизнесу аналитика

СутьФункция, которая повышает качество и скорость решений и создаёт прямую ценность через данные-продукты (ML в продукте, персонализация). Множитель, а не «отдел отчётов».

Когда важноВсегда; критично, когда решения принимают «на интуиции», а цена ошибки растёт вместе с масштабом — один неверный выбор приоритета стоит кварталов.

Зачем бизнесуОдин инсайт меняет решение, которое двигает деньги; плюс автоматизация решений в продукте. Ценность измеряется не объёмом данных, а сдвигом исходов.

Главная ошибка«Фабрика отчётов» — аналитика меряет всё, но не меняет ни одного решения: закрывает запросы вместо задач.

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

Подробно

На интервьюСформулируйте ценностное предложение функции в одну фразу: «повышаем ожидаемую ценность решений — вероятность верного выбора × ставку минус стоимость анализа».

ПримерДашборд, которым никто не пользуется, против A/B-теста, развернувшего фичу с измеренным эффектом на выручку. Второе — работа аналитики, первое — её имитация.

Проверьте себя«Как вы докажете, что аналитика окупается?» → ведёт к карточке «Ценность аналитики».

02Руководство

Лестница зрелости аналитики

СутьДве параллельные шкалы. По типу вопросов: описательная (что было) → диагностическая (почему) → предиктивная (что будет) → прескриптивная (что делать). По операционной модели: реактивные отчёты → self-service → предиктивная → встроенная в решения.

Когда важноПри построении дорожной карты функции — нельзя прыгнуть на ML, не наведя порядок в данных и определениях.

Зачем бизнесуЗадаёт последовательность инвестиций и защищает от «карго-культа ИИ» поверх грязных данных: каждая ступень опирается на предыдущую.

Главная ошибкаData science на болоте — строить предсказания поверх отсутствующего data engineering и единых определений. «AI-инициатива», которая упирается в то, что «выручка» считается пятью способами.

Подробно

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

Проверьте себя«С чего начать, если данным нельзя доверять?» Правильный ответ — контракты на данные, качество и semantic layer, а не модели.

03Руководство

Операционная модель: центр, команды, гибрид

СутьТри способа разместить аналитику: централизованная (центр компетенций), децентрализованная (аналитики внутри продуктовых команд) и гибридная — hub-and-spoke (центр держит платформу и стандарты, «спицы» сидят в командах).

Когда важноПри оргдизайне и масштабировании; выбор зависит от стадии и размера компании.

Зачем бизнесуБаланс двух сил: единые стандарты, карьера и одна правда (центр) против контекста, скорости и согласованности с командой (embedded).

Главная ошибкаКрайности — чистый центр превращается в очередь тикетов, оторванную от контекста; чистая децентрализация даёт пять определений выручки и нулевой рост людей.

Вопрос-ловушка: «какая модель правильная» — нет универсально правильной; она зависит от стадии. На масштабе обычно побеждает hub-and-spoke.

Подробно

ПримерЦентрализованная платформа данных и стандарты + embedded-аналитики в командах с пунктирной линией подчинения в центр (dotted-line). Лучшее из двух миров.

Проверьте себя«Как дать командам скорость, не потеряв единые определения?» → semantic layer + hub-and-spoke.

04Руководство

Под-функции дата-организации

СутьКарта ролей: data engineering (трубы и хранилище), analytics engineering (моделирование и semantic layer), BI (self-service и дашборды), data analytics (инсайты и решения), data science (предсказание), ML engineering (модели в проде), data platform и governance.

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

Зачем бизнесуУ ролей разные навыки и SLA. Смешение их в одном человеке на масштабе ведёт к выгоранию «и швец, и жнец» и к тому, что не делается ничего по-настоящему.

Главная ошибкаНайм «единорога» вместо команды дополняющих ролей; или наём data scientist, когда на самом деле болит data engineering.

Подробно

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

Проверьте себя«Чем analytics engineer отличается от BI-разработчика и от data engineer?» → следующая карточка.

05Руководство

Analytics Engineering — соединительная ткань

СутьСлой между инженерией данных и аналитиками: превращает сырые таблицы в чистые, версионированные, протестированные модели и единый слой метрик (эпоха dbt). Отвечает за «как мы считаем», а не за «где лежит».

Когда важноКогда «у каждого свой SQL для выручки» и дашборды расходятся в цифрах; когда аналитики тонут в дублирующей подготовке данных.

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

Главная ошибка«Это просто SQL» — без моделирования, тестов и документации semantic layer не появляется, и расхождения возвращаются.

Подробно

Примерdbt-модели по слоям bronze / silver / gold плюс слой метрик, где «активный пользователь» определён один раз для всех потребителей.

Проверьте себя«Где должно жить определение метрики — в дашборде или в слое?» Ответ: в слое.

06Руководство

Кому подчиняется аналитика

СутьЛиния подчинения (CEO, CDO, CTO, CFO, CPO) определяет мандат функции и её нейтральность как независимого источника правды о метриках.

Когда важноПри формировании функции и в борьбе за влияние и бюджет.

Зачем бизнесуПод CFO — финансовая дисциплина и нейтральность; под CTO — близко к данным, но дальше от бизнес-повестки; под CEO или CDO — кросс-функциональный мандат и независимость метрик.

Главная ошибкаСпрятать аналитику в одной бизнес-функции — тогда она обслуживает её повестку и теряет роль независимого арбитра правды.

Подробно

Проверьте себя«Почему отчётность по метрикам должна быть независима от тех, кого эти метрики оценивают?» → конфликт интересов и подгонка цифр (gaming).

07Руководство

Стратегический цикл (Strategic Loop)

СутьЗамкнутый контур: стратегия → цели → метрики → таргеты → инициативы → измерение → обучение → корректировка. Аналитика замыкает петлю обратной связи между «что задумали» и «что вышло».

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

Зачем бизнесуПревращает данные в управляемость: решения корректируются по факту регулярно, а не раз в год на стратсессии.

Главная ошибкаРазорванная петля — метрики собирают, но решения по ним не пересматривают (отчёт ради отчёта); или цели поставлены без метрик, по которым видно движение.

Подробно

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

Проверьте себя«Где в вашем цикле петля чаще всего рвётся?» Честный ответ про конкретный разрыв ценится выше «у нас всё работает».

08Руководство

KPI против OKR

СутьKPI — постоянные метрики здоровья, которые держат в норме. OKR — амбициозные цели на срок: Objective (куда) плюс 3–5 измеримых Key Results (по чему поймём, что дошли). Это не синонимы.

Когда важноПри постановке целей функции и компании, при каскадировании сверху вниз.

Зачем бизнесуKPI отвечает «всё ли в порядке», OKR — «куда прыгаем». Нужны оба: одни health-метрики делают организацию инертной, одни цели — слепой к рискам.

Главная ошибкаKR как список задач (output), а не результатов (outcome); «сэндбэггинг» заведомо лёгких целей; пятнадцать KR; путаница health-метрики с целью.

Не путать: KR «выпустить фичу» — это output, факт релиза. Настоящий KR звучит как сдвиг метрики: «retention D30 12% → 20%».

Подробно

ПримерO: «Стать инструментом по умолчанию для задачи X». KR: retention D30 12% → 20%; NRR 105% → 115%; активация 40% → 55%. Все три — исходы, не действия.

Проверьте себя«Чем KPI отличается от Key Result?» KPI живёт постоянно, KR — целевой сдвиг на период.

09Руководство

North Star и дерево метрик

СутьОдна метрика-«полярная звезда», выражающая ценность, доставляемую пользователю, разложенная на 3–5 input-метрик. Дерево метрик — мост от стратегии к ежедневной работе команд.

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

Зачем бизнесуВыравнивает усилия: каждая команда видит свой input-рычаг и понимает, как её работа двигает общий исход.

Главная ошибкаВыручка как North Star — оптимизируют извлечение денег, а не доставленную ценность; или выбирают метрику-тщеславие, которая растёт, но ничего не значит.

Подробно

ПримерSpotify — время прослушивания; маркетплейс — число успешных сделок. Декомпозиция: успешные сделки = покупатели × частота × конверсия корзины.

Проверьте себя«Чем North Star отличается от выручки и почему это важно?» → закон Гудхарта: цель-метрика перестаёт быть честной метрикой.

10Руководство

Ритуалы и каденс

СутьРегулярные форумы превращают данные в решения: еженедельный обзор бизнеса (WBR), месячный и квартальный обзоры (MBR / QBR), разбор метрик, форум разбора экспериментов, циклы планирования.

Когда важноЧтобы метрики не просто «висели на дашборде», а регулярно смотрелись и приводили к действиям.

Зачем бизнесуКаденс создаёт дисциплину обратной связи и подотчётность владельцев метрик: у каждого числа есть человек и ритм его обсуждения.

Главная ошибка«Чтение слайдов» — WBR без решений, владельцев и фокуса на аномалиях; либо метрики вообще без ритуала, который заставляет на них реагировать.

Подробно

ПримерWBR в стиле Amazon: фокус на отклонениях от ожидания и вопросе «что делаем», а не на статусах «всё идёт по плану».

Проверьте себя«Чем хороший разбор метрик отличается от статус-митинга?» Первый кончается решениями, второй — пересказом.

11Руководство

Приоритизация и приём задач

СутьКак функция выбирает работу: явный приём задач (intake), оценка ценность × усилия (RICE / ICE), привязка к OKR, баланс реактивного и проактивного (условно 70/20/10).

Когда важноКогда запросов больше, чем рук — то есть всегда.

Зачем бизнесуЗащищает от «очереди тикетов» и направляет ограниченные силы на рычаги наибольшей ценности, а не на самые громкие запросы.

Главная ошибка«SQL-обезьяна» — аналитика как сервис-деск, выполняющий выгрузки вместо решения задач; всё реактивно, проактивных инсайтов ноль.

Красный флаг: принять запрос «дай выгрузку» без вопроса «какое решение ты примешь» — прямой путь в фабрику выгрузок.

Подробно

ПримерПереформулировать «дай отчёт по оттоку» в «какое решение по удержанию вы примете и при каком числе?» — и часто отчёт оказывается не нужен.

Проверьте себя«Как вы говорите стейкхолдеру нет?» → ведёт к карточке «Стейкхолдеры».

12Руководство

Аналитика как продукт

СутьДашборды, датасеты и модели — это продукты со своими пользователями, ценностным предложением, SLA, жизненным циклом и депрекейшеном. Сюда же решение build vs buy по инструментам.

Когда важноПри росте числа артефактов — иначе организация обрастает «кладбищем дашбордов», которым никто не доверяет.

Зачем бизнесуФокус на освоении (adoption) и ценности, а не на количестве; меньше поддержки и технического долга, выше доверие.

Главная ошибка«Построили и забыли» — плодить дашборды без владельца и срока жизни; покупать или строить инструмент без оценки совокупной стоимости и реального освоения.

Подробно

ПримерСертифицированные («золотые») дашборды против ad-hoc; ежеквартальная чистка артефактов без просмотров и без привязанных решений.

Проверьте себя«Как понять, что дашборд пора удалить?» Нет просмотров и нет решений, которые он питает.

13Руководство

Культура данных: data-driven против data-informed

СутьЦель — не слепое «data-driven» (данные вместо суждения), а «data-informed»: данные плюс контекст плюс суждение. Культура = доверие к данным + грамотность + привычка спрашивать «что говорят цифры».

Когда важноВнедрение аналитики проваливается не на технике, а на культуре и освоении — это «последняя миля».

Зачем бизнесуБез культуры лучшие инсайты не меняют решений: инсайт без доверия и привычки действовать остаётся слайдом.

Главная ошибкаHiPPO (мнение самого высокооплачиваемого) переигрывает данные; либо обратная крайность — «данные сказали» как способ снять с себя ответственность за суждение.

Подробно

ПримерОбучение грамотности работе с данными, доступный self-service, публичное признание решений, принятых по данным, — культура растёт на примерах, а не на лозунгах.

Проверьте себя«Чем data-informed лучше data-driven?» Сохраняет место для суждения и ответственности там, где данных недостаточно.

14Руководство

Управление данными (Data Governance)

СутьУправление данными как активом: единые определения (semantic layer), сертифицированные метрики, SLA на качество, каталог и lineage, доступы, приватность (GDPR, 152-ФЗ), этика.

Когда важноКогда расходятся цифры, растут риски приватности и масштабируется доступ к данным.

Зачем бизнесуДоверие к данным — фундамент всего. Без него команды спорят о том, чьи цифры верные, вместо того чтобы спорить о решениях.

Главная ошибкаБюрократия или хаос — governance как комитеты ради комитетов, тормозящие всех; либо его полное отсутствие: хаос определений и утечки персональных данных.

Принцип: governance, который замедляет всех ради контроля, умирает. Цель — «мощёная дорога» (paved road), а не шлагбаум.

Подробно

ПримерОдин владелец на метрику, бэйдж «сертифицировано» на доверенных дашбордах, маскирование персональных данных по умолчанию.

Проверьте себя«Где грань между governance и бюрократией?» Governance ускоряет правильное использование; бюрократия замедляет любое.

15Руководство

Стейкхолдеры и влияние без полномочий

СутьАналитика влияет без формальной власти: партнёрство с продуктом, маркетингом, финансами и руководством, управление ожиданиями, перевод между бизнесом и техникой, умение говорить «нет».

Когда важноВсегда — ценность аналитики реализуется только через решения других людей.

Зачем бизнесуЛучший анализ бесполезен, если стейкхолдер ему не доверяет и не действует. Это та самая «последняя миля» между инсайтом и эффектом.

Главная ошибка«Принёс правильный ответ — сделал работу» — на деле нужно довести до освоения и изменения поведения; либо обратное — стать «yes-man» под все запросы и потерять фокус.

Подробно

ПримерРекомендация вперёд (принцип пирамиды Минто), язык денег и решений вместо языка метрик и таблиц — стейкхолдер слышит «что делать», а не «что я посчитал».

Проверьте себя«Стейкхолдер игнорирует ваш вывод — что делаете?» Сильный ответ — про доверие и формат, а не про «принесу ещё цифр».

16Руководство

Команда, грейды и карьерные треки

СутьT-образные люди (широкая база плюс одна глубина), баланс универсалов и специалистов; две карьерные лестницы — экспертный трек (IC) и менеджмент; грейды, матрица навыков, роль «переводчика» между аналитикой и бизнесом.

Когда важноПри росте команды и удержании сильных аналитиков.

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

Главная ошибкаЕдинственный путь роста — в менеджеры — так теряют лучших аналитиков, делая из них посредственных руководителей; либо найм «единорогов» вместо команды дополняющих ролей.

Подробно

ПримерStaff / principal analyst как вершина экспертного трека, равная по грейду и оплате менеджеру, — сигнал, что глубина ценится не меньше управления.

Проверьте себя«Как растить сильного аналитика, не делая его плохим менеджером?» → экспертный трек с реальным влиянием и грейдом.

17Руководство

Как измерять ценность самой аналитики

СутьКаверзный вопрос без точной формулы. Прокси: влияние на решения, освоение артефактов, время до инсайта (time-to-insight), доверие и качество данных, удовлетворённость стейкхолдеров, посчитанный эффект инициатив.

Когда важноПри защите бюджета функции и приоритизации — особенно в кризис, когда «непонятные» команды режут первыми.

Зачем бизнесуБез меры ценности аналитика выглядит статьёй затрат. С прокси-метриками она становится управляемой инвестицией.

Главная ошибкаМерить выработкой — числом дашбордов и закрытых тикетов вместо влияния на исходы; или не мерить вовсе, надеясь, что ценность «и так очевидна».

Честный ответ на интервью: ROI аналитики мерить трудно — и признание этого есть часть зрелости. Назовите прокси и границы, не делайте вид, что есть точная формула.

Подробно

ПримерЖурнал ключевых решений с пометкой «повлияла аналитика»; A/B-тесты с посчитанным эффектом на деньги — портфель доказанного влияния за квартал.

Проверьте себя«Совет директоров просит ROI аналитики — ваш ответ?» Сильный кандидат даёт прокси и честные границы, а не выдуманное число.

18Руководство

Тренды и собственная позиция

СутьРуководитель обязан иметь позицию по трендам: GenAI в аналитике (text-to-SQL, авто-инсайты, меняющаяся роль аналитика), real-time и стриминг, data mesh против централизованного склада, semantic layer, reverse ETL (операционная аналитика), decision intelligence.

Когда важноНа интервью и при планировании платформы на 2–3 года вперёд.

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

Главная ошибкаХайп или слепота — гнаться за data mesh «потому что модно» без зрелости под него; или игнорировать сдвиг, который уже идёт (GenAI меняет работу аналитика прямо сейчас).

Подробно

Пример позиции«Text-to-SQL снимает рутину, но повышает цену semantic layer: без единых определений модель уверенно выдаёт неверные цифры». Это и есть точка зрения, а не пересказ хайпа.

Проверьте себя«Как GenAI меняет роль аналитика — и что это значит для найма?» Сдвиг от написания SQL к постановке вопросов, проверке и интерпретации.

121 карточка в 10 семьях. Фильтруйте по семье и по уровню (База / Продвинутый / Эксперт), ищите по тексту (понятие, метрика, ошибка), разворачивайте «Подробно» — там «Проверьте себя» с вопросами под собеседование. Карточки связаны перекрёстными ссылками «См. также»: экспериментальный блок соединяет Продукт ↔ Рост ↔ ML, дерево метрик — BI ↔ Руководство, инкрементальность — Маркетинг ↔ ML.