KPI — это показатели здоровья продукта, которые вы держите в норме постоянно. OKR — амбициозные цели на квартал, ради которых команда напрягается и делает рывок. KPI отвечает на вопрос «всё ли работает как надо прямо сейчас», OKR — «куда мы хотим прыгнуть и на сколько». Разница не в формуле метрики (одна и та же цифра может быть и тем, и другим), а в том, как вы её используете: как норму, которую нельзя ронять, или как планку, до которой ещё тянуться. Аналитик в обоих случаях делает похожую работу — считает baseline, помогает выбрать реалистичную цель и трекает прогресс, — но логика у этих двух инструментов разная, и когда их путают, команда либо гонится за недостижимым, либо расслабляется на цифрах, которые давно пора было улучшать.
Дальше разберу это по-человечески: где граница, когда что брать, что конкретно делает аналитик и почему «KPI как OKR» — самая частая и дорогая ошибка.
Что такое KPI и что такое OKR простыми словами?
KPI (key performance indicator) — это метрика, за которой вы следите на регулярной основе, чтобы понимать, здоров ли продукт или процесс. Конверсия из регистрации в оплату, доля успешных платежей, время ответа саппорта, DAU, retention 7-го дня — всё это KPI. У них нет «финиша». Вы не закрываете конверсию, вы держите её в приемлемом коридоре месяц за месяцем. Упала — тревога, выросла — хорошо, но работа продолжается.
OKR (objectives and key results) — это способ ставить цели. Objective — это качественная амбициозная формулировка «чего хотим добиться» («сделать онбординг таким, чтобы новичок доходил до первого успеха за минуты»). Key results — 2-4 измеримых результата, по которым мы поймём, что objective достигнут: «поднять долю активированных за первую неделю с 24% до 40%», «снизить долю бросивших онбординг с 55% до 35%». OKR ставят на квартал (иногда на год для стратегических), и у них есть срок и амбиция. Классическая установка: если вы стабильно закрываете OKR на 100%, значит цели поставлены слишком робко. Здоровый уровень достижения — где-то 60-80%, и это не провал, а норма для «растягивающих» целей.
Короткая формула, чтобы не забыть: KPI — это про «не сломать», OKR — про «прорваться».
В чём главная разница между OKR и KPI?
Проще всего показать разницу через несколько осей.
Горизонт. KPI живут вечно, их смотрят на дашборде каждую неделю годами. OKR живут квартал, потом их пересобирают.
Амбиция. KPI хочется удержать на текущем уровне или чуть выше — это baseline здоровья. OKR специально ставят с запасом, чтобы было некомфортно. Если target в OKR выглядит легко достижимым, это плохой target.
Реакция на невыполнение. Не выполнили KPI — это инцидент, что-то сломалось, надо чинить. Не дотянули OKR до 100% — это ожидаемо, разбираем, что мешало, и переносим или корректируем.
Количество. KPI у большого продукта могут быть десятки — по каждой подсистеме. OKR намеренно держат в узде: 3-5 objectives на команду на квартал, иначе фокус размывается.
Одна и та же цифра может играть обе роли в разное время. Пример: доля успешных платежей — это классический KPI здоровья, вы держите её высокой всегда. Но если она просела до 88% из-за проблем с провайдером, на квартал вы можете сделать её OKR: «поднять success rate платежей с 88% до 97%». Как только вернули и стабилизировали — она снова уезжает в фоновые KPI, и вы просто следите, чтобы не падала. Метрика та же, инструмент разный.
Когда использовать OKR, а когда KPI?
Берите KPI, когда процесс уже работает и задача — не дать ему деградировать. Аптайм, скорость загрузки, доля ошибок, базовая конверсия воронки, отток. Это гигиена. Их не нужно «достигать», их нужно мониторить и реагировать на аномалии.
Берите OKR, когда есть амбициозное изменение, которого сейчас нет и которое требует сфокусированных усилий нескольких людей. Запустить новую механику активации, вырастить выручку сегмента, перестроить онбординг. OKR хорош там, где нужно направить команду в одну точку на квартал и договориться, как мы поймём успех.
На практике они уживаются вместе. У команды есть панель KPI, за которой она следит фоново, и 2-3 OKR, на которые тратит основную энергию квартала. Важное правило: OKR не должен ломать KPI. Если вы гоните выручку (OKR), но при этом обрушили долю успешных платежей или задрали отток — это провал, даже если цифра выручки красивая. Поэтому в OKR почти всегда добавляют «health metrics» или guardrail-метрики: показатели, которые нельзя ухудшать, пока вы гонитесь за целью. Это как раз ваши KPI, работающие ограничителями.
Если хочется потренировать это на живых продуктовых ситуациях, разборы такого типа есть в кейсах — там как раз задачки в духе «вот цель, вот метрики, что берём в target и что ставим в guardrail».
Как аналитик участвует в OKR и KPI?
Тут начинается ваша прямая работа, и она распадается на три этапа: baseline, target, трекинг.
Baseline — где мы сейчас. Прежде чем ставить любую цель, надо честно измерить текущее значение. Не «на глаз», а с определением метрики: за какой период, по какой когорте, что считаем событием. Половина плохих OKR рождается из того, что baseline никто нормально не посчитал, и цель ставят от балды.
Target — куда реалистично дотянуться. Аналитик не должен просто соглашаться с «хотим x2». Ваша роль — показать, что вообще двигало метрику раньше, какой был максимальный недельный рост, есть ли сезонность, и предложить target, который амбициозен, но не фантастичен. Хороший разговор звучит так: «за последний год лучший квартал дал +18% к активации, если мы хотим +60% — назовите, за счёт какого рычага, иначе это не цель, а пожелание».
Трекинг — движемся ли мы. Дальше нужен дашборд или регулярный срез, который показывает attainment: сколько процентов от target уже набрали, и в тренде ли мы к дедлайну. Здесь же ловятся ситуации, когда метрика растёт, но не за счёт того, что вы делали (например, сезонный всплеск маскирует то, что ваша фича не работает).
Эти же навыки — определить метрику, посчитать baseline, обосновать target — очень любят спрашивать на собеседованиях, и не только в продуктовых секциях. Подборка вопросов на метрики и продуктовое мышление есть в разделе вопросов для интервью.
Как посчитать baseline и обосновать target?
Покажу на примере. Допустим, objective — «улучшить монетизацию новых пользователей», а key result — про недельную выручку. Первым делом смотрим baseline: какая типичная неделя была за последний квартал.
-- baseline: недельная выручка за последние 90 дней
select
date_trunc('week', paid_at) as week,
sum(amount) as revenue,
count(distinct user_id) as paying_users
from payments
where status = 'paid'
and paid_at >= now() - interval '90 days'
group by 1
order by 1;Дальше не берём среднее вслепую — смотрим на разброс. Если недели скачут, median честнее, чем mean, потому что один выброс (крупная годовая оплата) не задирает картину.
import pandas as pd
paid = payments[payments.status == "paid"].copy()
paid["week"] = paid["paid_at"].dt.to_period("W")
weekly = paid.groupby("week")["amount"].sum()
baseline = weekly.median() # типичная неделя, устойчива к выбросам
best_week = weekly.max() # чего в принципе достигали
stretch = round(baseline * 1.3) # амбициозный, но не с потолка
print(f"baseline={baseline:.0f}, лучшая неделя={best_week:.0f}, target={stretch}")Логика обоснования target простая и защищаемая: вот типичная неделя, вот исторический потолок, вот предлагаемая планка — она выше типичной, но в пределах того, что уже случалось при хорошем стечении обстоятельств. Такой target можно отстоять перед командой, потому что за ним стоят данные, а не хотелка.
Хотите поиграть с такими запросами руками, не поднимая свою базу — есть SQL-тренажёр с задачами на агрегацию и когорты и Python-тренажёр на pandas. Если SQL пока шатается, короткий заход — первый урок SQL-курса, там как раз агрегации и группировки, без которых baseline не посчитать.
Почему нельзя превращать KPI в OKR?
Это самая частая ошибка, и выглядит она безобидно. Команда берёт свой обычный KPI — например, DAU или конверсию — и пишет в OKR: «удержать DAU на уровне 10 000». Формально это measurable key result. По сути это мусор, и вот почему.
OKR должен двигать продукт вперёд, в нём заложена амбиция и рычаг. «Удержать» — это не движение, это гигиена, место которой на панели KPI. Когда «удержание нормы» попадает в OKR, происходит две плохие вещи. Первая: команда закрывает OKR на 100%, ничего по сути не изменив, и создаётся иллюзия прогресса — цель «достигнута», а продукт стоит на месте. Вторая: настоящие амбициозные цели вытесняются, потому что квартальный слот занят охраной статус-кво.
Обратная ошибка тоже встречается: взять растягивающую цель и повесить на неё жёсткий спрос как за KPI. Не закрыли OKR на 100% — премию режем, людей ругаем. Итог предсказуемый: в следующем квартале все ставят заведомо лёгкие цели, которые точно закроют, и весь смысл «растягивающих» OKR умирает. OKR перестаёт быть про амбицию и становится ещё одним планом, который надо выполнить на 100%.
Практический тест, который я держу в голове: если формулировка начинается со слов «удержать», «поддерживать», «не допустить падения» — это почти наверняка KPI, и в OKR ему не место. Если начинается с «поднять», «вырасти», «запустить и довести до» — это кандидат в OKR. И отдельно: у здорового OKR всегда есть guardrail из KPI, иначе цель можно достигнуть, сломав что-то соседнее.
Как OKR и KPI связаны с North Star и деревом метрик?
Здесь всё складывается в одну картину. North Star Metric — это одна главная метрика, которая отражает ценность, которую продукт приносит пользователю (например, число активных команд, а не просто регистраций). North Star не двигают напрямую — она слишком высокоуровневая. Её раскладывают в дерево метрик: North Star распадается на драйверы (активация, вовлечение, удержание, монетизация), те — на подметрики, и так до конкретных вещей, на которые команда реально влияет.
KPI живут по всему этому дереву как датчики здоровья на каждом уровне: следят, чтобы ни один узел не деградировал. OKR — это точечное усилие: команда выбирает один-два узла дерева, которые сильнее всего сдвинут North Star в этом квартале, и ставит на них амбициозные key results. То есть дерево метрик — это карта, KPI — датчики на карте, а OKR — маршрут, по которому вы решили ехать в этом квартале.
Хорошая проверка связности: каждый key result должен трассироваться до North Star через дерево. Если вы не можете объяснить, как рост вашего KR подвинет главную метрику продукта, скорее всего вы гонитесь за локальным числом ради числа. И наоборот, если ваши KPI не покрывают ветки дерева, вы рискуете тихо просесть там, куда никто не смотрит. Разбор конкретных метрик и их формул — в справочнике метрик, а потренировать построение дерева и выбор target можно на тестовых заданиях, где дают продуктовую вводную и просят разложить её на измеримые показатели.
Что чаще всего ломается на практике?
Соберу типичные грабли, чтобы было куда свериться. Первое — baseline посчитан по другому определению метрики, чем target. Померили активацию как «сделал любое действие», а цель поставили по «дошёл до ключевого действия» — и весь квартал спорите, выполнен OKR или нет. Определение метрики фиксируйте до постановки цели, письменно.
Второе — нет guardrail. Команда разогнала одну цифру, обрушив соседнюю, и формально молодцы. Всегда добавляйте 1-2 health-метрики, которые нельзя ухудшать.
Третье — слишком много OKR. Пять objectives по три key result — это пятнадцать целей, то есть отсутствие целей. Фокус: 2-3 objective на команду.
Четвёртое — привязка премий к 100% выполнению растягивающих OKR. Это убивает амбицию быстрее всего, люди начинают занижать планку. Спрос за KPI — да, за OKR — с пониманием, что 70% это нормально.
Пятое, чисто аналитическое — трекать абсолютное значение без учёта тренда и сезонности. Метрика выросла на 15%, а рынок в этом квартале рос сам на 20% — значит вы фактически отстаёте, а не побеждаете. Всегда держите рядом контекст: что делал показатель без ваших усилий.
Если разобрались с разницей и хотите закрепить руками — цельные задачи на подсчёт baseline, конверсий и когорт лежат в SQL-тренажёре, а всё это и продвинутые метрики без ежедневных лимитов открываются в Pro. Но начать вполне можно и с бесплатной части: понимание OKR и KPI — это в первую очередь про голову, а не про инструмент.