Аналитики больше не нужны!

• Загрузите отчёт в нейронку, и она всё объяснит.
• Подключите Google Analytics и спрашивайте словами.
• Дашборд за два клика.

Если вы хоть раз пробовали, вы знаете, как это выглядит на деле.

• Отчёт она объяснит. Уверенно, с выводами. Только не совсем про вашу компанию.
• На вопрос словами ответит. Числом, которое никто в команде не узнаёт.
• Дашборд соберёт за два клика. А выяснять, что на нём посчитано, вы будете два дня.

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

Почему так выходит

Раньше, когда с метриками что-то шло не так, как ожидалось, мы шли обсуждать это друг к другу.

Теперь каждый идёт к своему Клоду, GPT, Gemini (подчеркните нужное).

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

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

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

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

Всё, чего нет в данных или в запросе, он либо достраивает сам, либо отвечает так, будто ничего не было. Вы объясняете сообщение за сообщением.

В новом чате всё заново.

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

А потом ещё поддерживать актуальность...

Проверяли это и без нас.

Ребята из Cube задали сто вопросов по ретейл-базе трём моделям: Claude Opus 4.7, Claude Sonnet 4.6 и GPT-5.4. Когда модели видели только структуру базы, верных ответов было 46–51%. С одним файлом на 4 КБ, написанным руками, все три дошли примерно до 68%.

Перепроверять всё ещё надо, но работать уже можно.

Держать файл стоит там, откуда Клод прочитает его в любом новом чате: в проекте, в инструкциях или файлах проекта. В ChatGPT это проект или свой GPT, в Gemini — Gem.

Что писать в такой файл дальше.

1. Чтобы говорил о тех же метриках, что и вы

Если Клоду не объяснить, что у вас значит метрика, переспрашивать он не станет. Выберет сам.

Определение и формула

Это база

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

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

Ошибки в расчёте при этом не будет. Он всё посчитает правильно, только по своей формуле.

Поэтому в карточку пишем формулу: что именно в числителе и что в знаменателе.

Синонимы и сокращения

Это база

Спрашиваешь «какая у нас конверсия за неделю?», а в ответ приходят штуки, а не проценты.

И Клод по-своему прав. В рекламных кабинетах «конверсии» — это количество целевых действий. А вы имели в виду conversion rate, долю.

Сами вы при этом называете её как придётся. Сегодня «конверсия», завтра «CR», в отчёте «конверсия в заказ». Клоду надо знать, что всё это одна метрика.

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

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

Конверсия в покупку
Синонимы: конверсия, CR, CVR, конверсия в заказ
Формула: Оплаченные заказы ÷ Сессии
Не путать: с количеством конверсий, с конверсией в лид и в корзину

Теперь Клод хотя бы говорит о том же, о чём вы. Следующий шаг, чтобы и считал так же.

2. Чтобы считал так, как принято именно у вас

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

Единицы измерения

Это база

Конверсия была 2%, стала 2,5%. Клод пишет: «выросла на 25%».

Посчитано верно. Только у вас такие изменения принято мерить в процентных пунктах, и в отчёте это +0,5 п.п.

«Плюс 25%» на планёрке звучит как прорыв.
«Плюс 0,5 п.п.» как обычная неделя.

Нюансы расчёта

Продвинутый уровень

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

Боты, свой трафик из офиса, тестовые заказы. Вы их давно отфильтровываете и уже не помните об этом. Клод не знает.

В понедельник налетели боты. В ваших отчётах их нет, конверсия стабильна. А Клод считает по сырой выгрузке, видит провал и выдаёт список гипотез про чекаут и цены.

Ищет причину падения, которого не было.

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

Примеры расчёта

Продвинутый уровень

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

Клод сверяется с ним сам. Если по тем же числам у него выходит другое, значит, считает он не так, как вы. И это видно сразу, а не когда цифры уже ушли в отчёт.

Допустимые агрегации

Продвинутый уровень

Спрашиваешь, какая средняя конверсия по трём каналам. Клод складывает три процента и делит на три.

А трафик в каналах очень разный:

• поиск — 10 000 сессий, конверсия 3%
• рассылка — 800 сессий, 6%
• новый канал на тесте — 40 сессий, 15%

Среднее арифметическое выходит 8%. Настоящая конверсия по трём каналам — 3,3%: все заказы делим на все сессии.

Новый канал с шестью заказами весит в таком среднем столько же, сколько поиск.

С периодами то же самое: конверсия за неделю не равна среднему из семи дневных.

В карточку добавляется:

Единица: %, изменения — в п.п.
Не учитываем: ботов, внутренний трафик, тестовые заказы, отмены и возвраты
Дата заказа: по дню оформления
Пример: 10 000 сессий, 230 оплаченных заказов → 2,3%
Агрегация: складываем заказы и сессии, потом делим; проценты не усредняем

Число теперь сходится с вашим. Дальше — чтобы Клод правильно его читал.

3. Чтобы давал корректную интерпретацию

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

Сущность метрики

Это база

Что конверсию надо растить, Клод догадается сам. А вот какие значения для вас нормальные, он не знает.

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

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

Без коридора нормы Клод не отличит рекорд от поломки.

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

Разрезы по умолчанию

Это база

Общая конверсия за месяц стоит на месте. Клод пишет, что всё стабильно.

А внутри мобильная упала, десктоп вырос, и в сумме вышел ноль. Что-то сломалось на телефонах, но в среднем этого не видно.

Поэтому в карточке стоит перечислить разрезы, в которых вы смотрите метрику всегда, даже если вопрос звучит как «а в целом»:

• устройство
• канал
• новые и вернувшиеся покупатели

Тогда Клод проверит их до того, как скажет «всё стабильно».

Запреты применения

Продвинутый уровень

Клод видит, что у рассылки конверсия заметно выше, чем у рекламы, и советует рекламу урезать.

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

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

Или он сравнивает эту неделю с той же неделей прошлого года, а там была распродажа.

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

Дозревание данных

Продвинутый уровень

Спрашиваешь, что вчера с конверсией. Клод видит просадку и начинает искать причину.

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

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

Клоду нужно знать, когда число можно считать окончательным.

Дописываем в карточку:

Направление: растить; коридор 2–4%, скачок выше — сначала проверить трекинг
Разрезы по умолчанию: устройство, канал, новые и вернувшиеся
Не сравнивать: рассылку с рекламой
               периоды до переезда на новый сайт (март)
               распродажи с обычными неделями
Дозревание: день считаем окончательным через 3 дня

Теперь Клод понимает, что видит. Самое сложное — объяснить, почему так вышло.

4. Чтобы правильно объяснял причины отклонений

Объясняя, почему конверсия сдвинулась, Клод опирается на связи между метриками. Какие из них настоящие, он без вас не знает.

Тип связи

Профи уровень

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

А на деле на складе закончился ходовой недорогой товар. Часть людей не нашла его и ушла, поэтому конверсия упала. Те, кто всё-таки купил, взяли аналог подороже: заказов меньше, но каждый в среднем дороже, поэтому чек вырос.

На обе метрики повлиял стокаут. А друг на друга они не влияют: высокий чек сам по себе никого не отпугивал.

Клод принял совпадение за влияние и пошёл снижать цены, хотя товар надо было просто вернуть на полку.

Чтобы так не выходило, в карточке записывают, с чем метрика связана и как:

• тождество — связь по формуле, арифметика. Конверсия = заказы ÷ сессии: заказов меньше при тех же сессиях, значит, конверсия ниже, проверять тут нечего;
• влияние — подвинешь одно, изменится другое. Стокаут двигает конверсию, и это можно проверить на данных.

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

Знак связи

Профи уровень

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

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

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

Когда в карточке записаны оба знака, Клод первым делом проверит порог.

Лаг эффекта

Профи уровень

Когда у ваших товаров не было отзывов, вы попросили покупателей их оставить. Как только отзывы появились на страницах товаров, конверсия выросла. Связь подтвердилась: больше отзывов — выше конверсия.

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

Ждёте. Конверсия стоит.

Клод: отзывам нужно время, подождём неделю. Через неделю тоже ничего. Подождём месяц.

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

Лаг говорит не только сколько ждать, но и когда ждать уже нечего.

Механизм связи

Профи уровень

Почему связь, которая один раз сработала, во второй раз промолчала?

Чтобы ответить, надо договорить фразу «отзывы влияют на конверсию, потому что…».

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

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

Это видно и в исследованиях. По данным Spiegel Research Center (2017), вероятность покупки товара с пятью отзывами на 270% выше, чем у товара без отзывов. А после первых пяти польза каждого следующего быстро падает.

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

Без механизма Клод видит только «больше отзывов — выше конверсия» и советует собирать ещё. Там, где их уже сотни.

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

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

Связи:
  Конверсия = Заказы ÷ Сессии — тождество
  Влияют:
    Уровень стокаутов: минус, сразу
      как: не нашёл нужный товар и ушёл
    Порог бесплатной доставки: минус, сразу (на средний чек — плюс)
      как: корзина чуть ниже порога, доплата за доставку, уход
    Количество отзывов: плюс, сразу
      как: снимают сомнение перед покупкой; заметно, пока отзывов у товара мало
    Стоимость доставки: минус
    Время загрузки страницы: минус
    … и т.д.
  Не влияет: Средний чек

Финал

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

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

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

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

А коллегу всё-таки иногда зовите. Коллективный разум, он такой.

Формально не придраться.

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

Абсурд, не так ли?

Такая разбивка отвечает на вопрос «откуда взялось число».

В этом есть небольшая польза. Когда метрика просела, вы хотя бы понимаете, что поехало, числитель или знаменатель.

Но не более. За счёт чего именно двигать метрику, из неё не видно.

Эту же метрику можно разложить иначе: на части, которыми кто-то в компании реально управляет.

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

Средний чек

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

Выглядит она обычно так:

Средний чек = Выручка ÷ Заказы

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

Поэтому в задачи такая декомпозиция и не превращается.

Вдобавок она склеивает разные ситуации. Заказ на 5 000 рублей — это один дорогой товар или пять дешёвых?

Формула отвечает одинаково.

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

Так выходит не всегда, но приятно.

«Поднять средний чек» перестаёт быть одной задачей и становится четырьмя. У каждой свой владелец и свой срок.

Работает это и в обратную сторону.

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

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

Конверсия

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

Чаще всего вот так:

Конверсия = Покупки ÷ Сессии

Число есть, а места потери нет.

Где именно упала конверсия? На карточке, в корзине, на оплате? С одной формулой ответа не найти.

Но хуже другое. Общая конверсия может стоять на месте, пока внутри всё меняется и компенсируется: на одном шаге стало лучше, на другом хуже, в сумме ноль.

Все три работают в одну сторону: растёт любая микроконверсия — растёт общая конверсия. Если, конечно, рост одной не компенсируется другой.

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

Но покупать после этого стали реже → конверсия в оплату упала.

Общая конверсия не изменилась.

Точка отвала просто переехала на шаг ниже — люди как уходили из-за доставки, так и уходят.

Выбор здесь только один: на каком шаге их терять.

Выручка

Выручку вроде и раскладывать незачем — формулу все знают наизусть.

Вот эту:

Выручка = Заказы × Средний чек

И здесь та же беда — обе части результаты.

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

На этих четырёх останавливаться не обязательно.

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

И вбок тоже. Первые три части — это заказы, разложенные через клиентскую базу. Но заказы можно разложить и через трафик:

Заказы = Трафик × Конверсия

А это уже второй раздел с его тремя шагами.

Выручка — метрика верхнего уровня, под ней помещается почти всё остальное. Со стороны клиентов вы увидите базу и активность, со стороны трафика — сессии и воронку. Обе раскладки верные, просто отвечают на разные вопросы.

CAC

Это единственная метрика здесь, которую хотят снижать, а не растить. Раскладывают её при этом ровно так же, как остальные.

Берут расходы и делят на клиентов:

CAC = Расходы на привлечение ÷ Новые клиенты

Если CAC вырос, то подорожал трафик или испортилась воронка?

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

Вот здесь тип влияния перестаёт быть формальностью.

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

Дорогой трафик бывает выгоднее дешёвого.

Валовая маржа

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

Начинают обычно с этого:

Валовая маржа = (Выручка − Себестоимость) ÷ Выручка

Отношение двух больших чисел. Видно, какая доля выручки осталась, но не видно, где утекла остальная.

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

Типичная история: наценка нормальная, а маржа низкая.

По формуле понятно только, что себестоимость великовата, и все дружно идут давить поставщика.

По раскладке видно, что давить надо промо или возвраты. А закупка тут ни при чём.

Удержание

Удержание чаще всего просто считают и смотрят на динамику.

А если декомпозируют, то по привычке:

Удержание = Повторные клиенты ÷ Всего клиентов

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

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

Посмотрите на них ещё раз. 3 из 4 описывают первую покупку, а не то, что было после неё.

• Взял два товара и больше — возвращается чаще. Значит, рычаг в кросс-сейле на входе, а не в рассылках потом.
• Пришёл по глубокой скидке — удержание хуже. Скидка на вход покупает выручку сегодня за счёт базы завтра.
• Вернул первый заказ — второго может и не быть. Тут многое зависит от того, как прошёл сам возврат.

Выходит, удержание закладывается на первом заказе.

И работать надо с ним, а не с теми, кто уже вернулся.

Финал

Базовая разбивка не бесполезна. Она, как правило, отвечает на вопрос о прошлом.

Часто для операционного отчёта этого достаточно, а вот для диагностического нет.

Формула не может сказать, за счёт чего метрику двигать. В ней нет ни одной части, за которую отвечает конкретный человек.

Так что раскладывайте дальше, пока по каждой части не станет понятно, кто и что с ней делает.

Иначе получаются те же числа, только помельче.

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

Например, «нужен дашборд по поддержке» – это тема.

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

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

В этой статье разбираем, как за 5 шагов собрать диагностический дашборд под задачу на примере удовлетворённости клиентов поддержкой.

Шаг 1. Выбрать задачу

Задача – это работа, которую пользователь делает регулярно и будет делать дальше, есть у него дашборд или нет. У неё 3 признака.

1. У неё есть триггер. Что-то её запускает: наступил понедельник, закрылся месяц, прилетел алерт о падении метрики или кто-то на созвоне сказал, что оценки просели. Пока триггера нет, человек дашборд и не открывает, это нормально.
2. Повторяется. Триггер срабатывает не один раз, а регулярно: каждую неделю, каждый месяц или после закрытия периода. Под разовое расследование дашборд собирать не нужно, там дешевле один раз выгрузить данные и посчитать всё руками.
3. Заканчивается решением. Человек не просто смотрит на цифры, а после этого что-то делает: идёт к команде, меняет приоритеты, заводит задачу. Если после просмотра ничего не происходит, то это не работа, а любопытство.

Как найти задачу

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

Что стоит спросить:

• В какой момент вы про это вспоминаете? Здесь ищем триггер. Ответ будет вроде «на понедельничном созвоне», «когда руководитель спрашивает» или «когда приходят жалобы». Это и есть момент, ради которого дашборд открывают.
• Что вы в этот момент хотите понять? Здесь появляется первая формулировка задачи. Пока в общих словах, но уже не просто «поддержка», а «нормально ли мы отрабатываем» или «почему клиенты недовольны».
• Что делаете дальше, чтобы разобраться? Это реальная последовательность действий: куда человек идёт, что открывает, что с чем сравнивает. Тот самый маршрут, который дашборд должен повторить.
• А в чём обычно оказывается дело? Самый полезный вопрос: в ответ человек перечислит привычные подозрения вроде «обычно это возвраты» или «чаще всего кто-то из новеньких». Это его рабочие гипотезы, из них дальше вырастают метрики и разрезы. Записывайте дословно, пригодится на шагах 3 и 5.
• Чем всё обычно заканчивается? Это проверка на решение. Если в ответ звучит «ну, посмотрели и дальше работаем», то задачи нет, а есть привычка смотреть.

Знаете, как человек решает задачу сейчас, – считайте, что полдела сделано. Этот маршрут и переносим в дашборд: не изобретаем новый путь, а делаем существующий быстрее.

Одна задача = один дашборд

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

Поддержка

• Исследовать удовлетворённость клиентов службой поддержки
• Оценить, справляется ли команда с потоком обращений
• Оценить, насколько эффективно работает бот в поддержке

Продажи

• Выяснить, из-за чего упала выручка в этом месяце
• Найти товары, из-за которых снижается маржа
• Локализовать место, где мы теряем клиентов в воронке

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

Дальше мы будем собирать дашборд под одну из этих задач. Возьмем эту – исследовать удовлетворённость клиентов службой поддержки.

Шаг 2. Выбрать ключевую метрику

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

Задача → Ключевая метрика

• Исследовать удовлетворённость клиентов службой поддержки (наш выбор) → Индекс удовлетворенности клиентов (CSAT) (открыть на карте метрик)
• Оценить, справляется ли команда с потоком обращений → Среднее время ожидания (открыть на карте метрик)
• Оценить, насколько эффективно работает бот в поддержке → % авто-решенных обращений (открыть на карте метрик)

Кандидатов на роль ключевой метрики обычно несколько, и тут легко ошибиться.

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

Лучше подойдёт «Среднее время ожидания» – по ней видно, стали клиенты ждать дольше или нет.

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

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

Смотрим на примере

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

Шаг 3. Собрать поддерживающие метрики

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

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

Дальше открывайте карту метрик и проверяйте, не пропустили ли вы что-то влияющее. Смотрите на те метрики, что стоят в 1–3 шагах от ключевой. Дальше связь идёт через столько промежуточных звеньев, что по движению метрики уже не понять, при чём тут ключевая.

Оставшихся кандидатов разбираем по 3-м группам.

Действие — рычаги, то, на что можно повлиять напрямую.

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

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

Результат — объём потока, сколько всего стоит за ключевой метрикой.

Это количество обращений для оценки поддержки, количество заказов для среднего чека, количество сессий для конверсии. Такая метрика тоже нужна всегда: падение оценки с 4,8 до 4,2 — это провал на 1000 отзывов и флуктуация на 10.

Диагностика — метрики, на которые нельзя повлиять напрямую, но которые показывают здоровье процесса.

Часто такая метрика работает зонтиком над группой рычагов: «Соблюдение SLA» само по себе не управляемо, зато сразу говорит, держим ли мы норматив вообще. Поэтому и правило про 1–3 шага для них мягче, ведь они описывают процесс более масштабно, а не просто отдельное звено.

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

Смотрим на примере

Получилось 9 метрик:

Действие — время первого ответа, время до решения, время обработки обращения, доля решённых обращений, % авто-решённых обращений, оценка процесса возврата.

Результат — количество обращений.

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

Шаг 4. Добавить метрики-противовесы

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

Противовесы — это метрики, по которым видно цену действия. Работают они в паре с метриками действия (рычаги):

Влияем на Что может ухудшиться «Доля обращений без оператора»: дорабатываем бота, чтобы разгрузить людей «Доля переоткрытых обращений»: бот закрыл диалог, а клиент вернулся с тем же вопросом «Норматив ответа (SLA)»: сокращаем, чтобы клиенты ждали меньше «Индекс удовлетворённости команды»: норматив держат за счёт сотрудников, и они выгорают

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

Смотрим на примере

Противовесов два.

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

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

Шаг 5. Определить разрезы

Метрики отвечают на вопрос «за счёт чего», а разрезы – на вопрос «где именно». Ответ, ради которого собирался дашборд, выглядит как пара: проблемная метрика × проблемный разрез.

Кандидатов ищите в двух местах:

• В ответах пользователя. Какие гипотезы он проверяет обычно, из раза в раз («чаще всего дело в возвратах», «сначала смотрю по каналам»), и как режет данные в выгрузках.
• В карточках метрик. У каждой метрики есть список разрезов, в которых её имеет смысл смотреть. У нас такой список будет собран в Атласе.

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

Что показывать в самих разрезах

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

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

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

Почему нужна фильтрация

Собранный так дашборд пользователь проходит одним из двух маршрутов.

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

Обратный. Ключевая просела, а поддерживающие все ровные. Это не значит, что всё хорошо: они посчитаны по всем срезам сразу, и срез, где нормально, «вытягивает» тот, где плохо. Тогда идём с другой стороны: ищем разрез, в котором просела ключевая метрика, фильтруем по нему весь дашборд и смотрим поддерживающие заново, уже внутри этого среза. Там проблемная метрика обычно и обнаруживается.

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

Смотрим на примере

Разрезов 4, и каждый применим ко всем метрикам набора:

Тип обращения. Вопрос про доставку и вопрос про возврат обрабатываются по-разному, и ломается обычно что-то одно.

Канал. Чат, почта и телефон живут по своим правилам: в чате ждут ответа минуту, а в почте сутки.

Специалист. Показывает, проблема общая или у конкретных людей.

Участие специалиста. Обращение закрыл бот или подключался человек. Здесь видно, справляется автоматизация или только откладывает вопрос.

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

Финал

Дашборд не заменяет мышление, а упрощает его. Человек всё так же проверяет свои гипотезы, но при этом не собирает данные руками и не ждёт выгрузку два дня.

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

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

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

Выручка. ROAS. LTV. Отток. Средний чек (AOV). Конверсия (CR).

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

То, что сдерживает магазин с 300 заказами, совсем не то же самое, что сдерживает магазин с 10 000.

По мере роста объёма заказов меняется и узкое место.

Количество заказов — это индикатор сложности системы.

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

Стадия 1 — Выживание

Диапазон заказов: <500 заказов в месяц

Это этап, когда всё одновременно кажется возможным и неопределённым.

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

Вы всё ещё изучаете:

• кто на самом деле покупает
• почему они покупают
• что заставляет их сомневаться
• на что они жалуются

Это хаотично. И это нормально.

На этом этапе цель — не масштаб, а ясность.

Людям действительно нужен этот продукт по этой цене в таком формате?

Фокус

• Конверсия (CR) — действительно ли трафик конвертируется?
• Стоимость привлечения клиента (CAC) — покрывает ли первая покупка расходы на привлечение? А если не первая, то какая?
• NPS, отзывы — клиенты действительно довольны или просто покупают один раз?

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

• Пожизненная ценность клиента (LTV) — поведение повторных покупок ещё не стабилизировалось.
• Отток (Churn) — слишком мало данных, чтобы делать выводы.
• Сложный когортный анализ — устойчивые паттерны ещё не сформированы.

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

Стадия 2 — Монетизация

Диапазон заказов: 500–1 500 заказов в месяц

Теперь вы уже не гадаете, будут ли покупать.

Будут.

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

Меняется сам вопрос.

Уже не «Будет ли это продаваться?»

А «Можно ли это масштабировать с прибылью?»

Выручка может расти. Но маржинальность, скидки и эффективность рекламы становятся важнее, чем сам факт роста.

Фокус

• Средний чек (AOV) — покупают ли клиенты достаточно в рамках одной транзакции?
• Окупаемость рекламы (ROAS) — способен ли рост сам себя окупать?
• Оборачиваемость запасов — движется ли склад в здоровом темпе?

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

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

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

Стадия 3 — Удержание

Диапазон заказов: 1 500–3 000 заказов в месяц

К этому моменту бизнес уже не хрупкий.

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

Новые клиенты по-прежнему приносят выручку.

Но зависимость только от привлечения становится дорогой. CAC постепенно растёт. Скидки начинают казаться необходимыми. Для того же роста требуется больше усилий.

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

Фокус

• Пожизненная ценность клиента (LTV) — какую ценность клиент приносит за всё время взаимодействия?
• Отток (Churn) / Доля повторных покупок — возвращаются ли клиенты стабильно?
• Структура трафика — какие каналы приводят клиентов с наибольшей долгосрочной ценностью?

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

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

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

Стадия 4 — Масштабирование

Диапазон заказов: 3 000–10 000 заказов в месяц

Рост больше не проблема.

Проблема — справиться с ростом.

Заказы идут. Каналы диверсифицированы. Удержание измеримо. Выручка ощутима.

Но система начинает ломаться.

Служба поддержки перегружена. Сроки доставки колеблются. Планирование запасов усложняется. Небольшие неэффективности становятся дорогими. То, что раньше работало «вручную», ломается под объёмом.

На этом этапе риск — не в нехватке спроса.

А в операционном напряжении.

Фокус

• Доля повторных покупок — возвращаются ли клиенты при увеличении объёма?
• Срок выполнения заказов — остаётся ли скорость обработки стабильной?
• Метрики экспансии — масштабируются ли новые рынки, каналы или продуктовые линии устойчиво?

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

• Чистая оптимизация привлечения — дополнительный трафик не решит проблем в системе.
• Микронастройка рекламных креативов — мелкие улучшения вторичны по сравнению со стабильностью.
• Подход “постоянного эксперимента” раннего этапа — структура важнее скорости тестов.

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

Стадия 5 — Система

Диапазон заказов: >10 000 заказов в месяц

На этом этапе рост уже не хрупкий — он структурный.

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

Вы больше не оптимизируете отдельные элементы.

Вы управляете системой.

Фокус

• Эффективность цепочки поставок — поддерживают ли производство, запасы и логистика стабильный рост?
• Метрики глобальной и рыночной экспансии — прибыльны ли новые регионы и операционно устойчивы ли они?
• Сила бренда и долгосрочное позиционирование — снижает ли бренд зависимость от платного трафика?

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

• Микрооптимизация отдельных кампаний — локальные победы больше не двигают систему.
• Изолированные улучшения метрик — рост должен быть согласован между функциями.
• Краткосрочные всплески — устойчивость важнее быстрых скачков.

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

Финальные мысли

Ошибка — не в том, что вы отслеживаете «не те» метрики.

Ошибка — в том, что вы отслеживаете правильные метрики в неправильное время.

• Маленький магазин, зацикленный на LTV.
• Растущий бренд, игнорирующий отток.
• Крупный бизнес, который всё ещё думает, что маркетинг исправит операционные проблемы.

У каждого этапа — своё ограничение.

И рост не появляется от одновременной оптимизации всего.

Он появляется тогда, когда вы находите то, что действительно сдерживает вас — прямо сейчас.

Но почти никто не объясняет, как её выбрать.

Что вообще делает метрику «ключевой»?
Важность? Влияние на выручку? Зона ответственности? Скорость изменения?

Без чётких критериев выбор превращается в гадание.

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

В этом и проблема.

Почему команды ошибаются

Обычно это не одна большая ошибка.

Команды просто пропускают несколько базовых проверок и в итоге выбирают не ту метрику.

• Выбирают самую верхнеуровневую метрику
  Звучит серьёзно, но она слишком далеко от того, на что команда реально может повлиять.
• Игнорируют временной горизонт
  Работают две недели и берут LTV.
• Путают «важное» с «управляемым»
  Выручка важна. Это не значит, что именно она должна быть ключевой метрикой прямо сейчас.
• Выбирают метрику, которую не контролируют
  То, что она есть в дашборде, не значит, что вы можете на неё повлиять.

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

Фаза 1. Выбор кандидата в ключевую метрику

Шаг 1. Определите фокус

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

Нужно явно выбрать, над чем вы работаете:

• привлечение (acquisition)
• удержание (retention)
• эффективность продукта (product performance)
• операционные процессы (operations)
• что-то ещё

Ключевая метрика должна относиться к этому фокусу.

Если ваш фокус — привлечение, то доля повторных покупок (Repeat Purchase Rate) не может быть ключевой.

Если ваш фокус — трение на этапе оплаты, то Выручка (Revenue) слишком далеко от проблемы.

Что сделать на этом шаге

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

Шаг 2. Определите режим работы

Перед выбором метрики нужно понять, в каком режиме вы работаете.

Вы чините сломанную систему?
Или пытаетесь улучшить уже стабильную?

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

В режиме улучшения она может быть более агрегированной.

Неверно выбранный режим — неверный уровень метрики.

Если резко упала конверсия, количество заказов (Orders) слишком далеко от проблемы.

Если всё стабильно, отслеживать долю добавлений в корзину (Add to Cart Rate) — слишком узко.

Что сделать на этом шаге

• Решите: вы исправляете проблему или улучшаете результат?
• Уберите метрики, не соответствующие режиму.

Шаг 3. Определите желаемый результат

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

Без чётко сформулированного результата метрика отрывается от цели.

Ключевая метрика должна отражать конкретное изменение в системе:

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

Что сделать на этом шаге

• Сформулируйте результат как изменение в системе.
• Перечислите метрики, которые это отражают.
• Уберите остальные.

Шаг 4. Задайте временной горизонт

Ключевая метрика не существует «вне времени».

Она должна направлять решения в конкретном периоде.

Этот период зависит от:

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

Выберите реалистичный горизонт: 1–2 недели, месяц или квартал.

Короткий горизонт — тактический результат.
Более длинный — более стратегический сдвиг.

Что сделать на этом шаге

• Выберите чёткий временной горизонт.
• Сопоставьте его с ресурсами.
• Уберите метрики, не подходящие под этот горизонт.

Шаг 5. Проверьте скорость обратной связи

Теперь, когда горизонт определён, проверьте, может ли метрика реально измениться в этом интервале.

Спросите: если мы изменим что-то сегодня, как быстро должна сдвинуться метрика?

• Быстро — дни
• Средне — недели
• Медленно — месяцы

Скорость обратной связи должна соответствовать горизонту решений.

Если метрика движется слишком медленно — исключите её.

Что сделать на этом шаге

• Оцените, как быстро может измениться каждая метрика.
• Сравните с выбранным горизонтом.
• Уберите метрики без своевременной обратной связи.

Фаза 2. Проверка кандидата

Шаг 6. Проверьте качество метрики

Ключевая метрика должна быть надёжной.

Если вы не доверяете числу, вы не можете принимать по нему решения.

Перед финальным выбором проверьте:

• Всегда ли она считается одинаково?
• Достаточно ли данных для выявления реальных изменений?
• Можно ли её разложить по сегментам и понять причину изменения?

Если на любой вопрос ответ «нет» — метрика не готова быть ключевой.

Что сделать

• Проверьте логику расчёта.
• Оцените объём данных.
• Проверьте, можно ли сегментировать.

Шаг 7. Определите драйверы

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

Если вы не можете объяснить, что на неё влияет, вы не сможете её системно улучшать.

Вопрос простой:

Можно ли разложить метрику на понятные драйверы?

Если влияние выглядит абстрактным — метрика слабый кандидат, даже если важная.

Что сделать

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

Шаг 8. Проверьте управляемость

Наличие драйверов — недостаточно.

Теперь строго спросите:

• Что мы реально можем изменить в этом горизонте?
• Где можем действовать без долгих согласований и внешних зависимостей?

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

Что сделать

• Просмотрите драйверы.
• Определите, какие из них управляемы в выбранном горизонте.
• Уберите метрики, зависящие от внешних факторов.

Если осталось больше одной метрики

Это нормально.

Выберите ту, которая:

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

Это и будет ключевая метрика.

Дополнительно: добавьте 2–3 защитные метрики

Оптимизируя одну метрику, можно ухудшить другие.

Ключевая метрика должна задавать фокус, но не ломать систему.

Спросите: что может пострадать, пока мы её улучшаем?

Оптимизируйте ключевую метрику. Контролируйте защитные.

Зафиксируйте выбор

Запишите одним предложением:

В течение [периода] наша ключевая метрика — [метрика].
Она даёт самый чёткий сигнал того, что мы достигаем [результат].
Защитные метрики: A, B, C.

В завершение

Выбор ключевой метрики — это управленческое решение.

На определённый период вы выбираете один сигнал прогресса.
Вы выстраиваете действия вокруг него.
Вы контролируете защитные метрики.

Если метрика выбрана неправильно — усилия будут направлены не туда.

Если правильно — решения становятся очевидными.

Им не хватает понимания, что с ними делать.

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

И почему это происходит гораздо чаще, чем кажется.

Метрики без решений — это просто числа

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

Они бесполезны потому, что после их изменений ничего не происходит.

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

Метрика перестаёт вести к решениям, когда:

• нет согласованной реакции на рост или падение
• её смотрят изолированно, без связанных метрик и разрезов
• она не привязана к конкретному вопросу или зоне ответственности

В таком виде метрика может показать, что что-то изменилось, но не объясняет, что с этим делать, и нужно ли что-то.

Почти любая метрика может стать полезной. Но только если она связана с контекстом, сравнениями и аналитическими вопросами.

Пока этого нет, она остаётся наблюдением, а не входом в действие.

И без следующего шага даже корректная метрика превращается в шум.

Как выглядят «метрики без решений» на практике

Пример 1: Общий трафик

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

Она даёт простое, верхнеуровневое понимание того, сколько пользователей приходит на сайт.

Сама по себе она редко ведёт к решениям.

Почему она не ведёт к решениям

• она слишком агрегированная
• не показывает, откуда именно пришли изменения
• не указывает на следующий шаг

Что делает её decision-driven

• разбить трафик по источникам, чтобы увидеть, где именно произошло изменение
• сравнить источники по объёму, чтобы сфокусироваться на действительно важном
• посмотреть динамику по каждому источнику, чтобы понять, это реальное изменение или шум

Пример 2: Заказы

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

В отличие от трафика, она уже ближе к деньгам и результатам бизнеса. И именно поэтому её легко переинтерпретировать.

Почему она не ведёт к решениям

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

Что делает её decision-driven

• смотреть заказы вместе со средним чеком, чтобы понять, за счёт чего меняется выручка
• разделять заказы новых и возвращающихся клиентов, чтобы увидеть, где именно проблема
• добавлять прибыль или маржу на заказ, чтобы не оптимизировать количество заказов в ущерб рентабельности

Пример 3: Общее количество клиентов в базе

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

Проблема в том, что само по себе это число неоднозначно.

Почему она не ведёт к решениям

• не разделяет активных и неактивных клиентов
• смешивает новых, возвращающихся и ушедших клиентов в один показатель
• не показывает, растёт ли база на самом деле или просто накапливает историю

Что делает её decision-driven

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

Пример 4: LTV (Customer Lifetime Value)

LTV часто воспринимают как стратегическую north-star-метрику.

Она обещает одно число, которое отражает ценность клиента во времени. И именно это обещание делает её опасной.

Почему она не ведёт к решениям

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

Что делает её decision-driven

• смотреть LTV вместе с количеством активных клиентов, чтобы понимать реальный масштаб ценности
• разбивать LTV по когортам, чтобы видеть, какие клиенты её формируют
• связывать LTV с её драйверами (повторные покупки, средний чек, срок жизни), чтобы понимать, на что можно влиять
• сравнивать LTV с CAC, чтобы оценивать, насколько рост прибыльный и устойчивый

Почему дашборды не помогают с решениями

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

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

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

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

В лучшем случае дашборд отвечает на вопросы:

• какое сейчас значение метрики?
• изменилась ли она?
• на сколько?
• по сравнению с каким периодом?

Это полезно, но ограниченно.

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

• связанные метрики рядом друг с другом
• осмысленные разрезы для ключевых показателей
• сравнения, которые объясняют, почему произошло изменение
• динамика на разных временных горизонтах, а не только один дельта-показатель

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

Что делает метрику decision-driven

Метрика начинает иметь смысл только тогда, когда её роль понятна заранее.

Перед тем как отслеживать метрику, должно быть ясно:

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

Если хотя бы на один из этих вопросов нет ответа, метрика не готова к использованию.

Не менее важно и то, как эта метрика выглядит в аналитике. Decision-driven-метрика почти никогда не показывается одним числом.

Как минимум ей нужны:

• текущее значение и его изменение во времени
• понятная динамика, а не одна дельта
• связанные метрики рядом, а не на других экранах
• значимые разрезы, которые помогают объяснить причины изменений

Без этого контекста даже хорошо определённая метрика снова превращается в мониторинг. А с контекстом она становится точкой входа в решение.

Итог

Метрика не становится полезной потому, что она точная или популярная.

Она становится полезной только тогда, когда напрямую связана с решением и действиями, которые за ним следуют.

Поэтому аналитика должна начинаться не с вопроса
«Что нам измерять?»

А с вопроса
«Какие решения нам нужно принимать?»

Пока метрики явно не связаны с этими решениями, они остаются числами — точными, аккуратными и в основном бесполезными.

• Команда CRO работает над ростом конверсии.
• Команда email — над количеством заказов из рассылок.
• Команда удержания клиентов — над повторными покупками.
• Команда поддержки — над скоростью обработки обращений.

Каждая команда улучшает свои метрики.

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

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

Конверсия сайта → Монетизация

Команда CRO отвечает за рост конверсии сайта и оптимизацию пути к покупке.

Чтобы увеличить конверсию, команда:

• добавляет агрессивные скидки
• использует триггеры срочности («только сегодня», «последний шанс»)
• включает поп-апы и элементы давления

Локальный эффект

→ Конверсия сайта ↑

Побочный эффект

Те же самые тактики:

• смещают спрос в сторону более дешёвых заказов
• снижают готовность клиентов платить полную цену
• приучают аудиторию ждать скидок

→ Средний чек ↓
→ Выручка на пользователя ↓

Конверсия сайта → Логистика

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

Чтобы повысить конверсию, команда:

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

Локальный эффект

→ Конверсия сайта ↑

Побочный эффект

Те же действия:

• увеличивают долю низкомаржинальных заказов
• ухудшают окупаемость доставки
• проталкивают заказы ниже порога прибыльности

→ Стоимость обработки заказа ↑
→ Маржа ↓

Email → Удержание

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

Чтобы повысить вовлечённость, команда:

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

Локальный эффект

→ Открываемость писем ↑
→ Кликабельность писем ↑
→ Количество заказов из email ↑

Побочный эффект

То же смещение:

• увеличивает долю заказов со скидкой
• формирует промо-зависимое поведение
• ослабляет спрос по полной цене

→ Доля заказов со скидкой ↑
→ Средний чек ↓

Управление запасами → Конверсия сайта

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

Чтобы оптимизировать затраты на склад, команда:

• снижает страховые остатки по товарам
• держит запасы близко к минимально необходимому спросу
• ставит эффективность затрат выше доступности товара

Локальный эффект

→ Затраты на хранение ↓

Побочный эффект

Те же решения:

• увеличивают частоту отсутствия товара на складе
• разрывают связь между трафиком и наличием товара
• превращают готовые к покупке сессии в тупик

→ Доля out-of-stock ↑
→ Конверсия карточек товаров ↓

Поддержка → Удержание

Под давлением растущего объёма обращений команда поддержки фокусируется на скорости и операционной эффективности.

Чтобы сократить время обработки тикетов, команда:

• внедряет шаблоны ответов
• усиливает автоматизацию и автоответы
• оптимизирует процессы под быстрое закрытие обращений

Локальный эффект

→ Время решения обращений ↓

Побочный эффект

Те же изменения:

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

→ CSAT ↓
→ Доля повторных покупок ↓
→ Участие в реферральных программах ↓

Платная реклама → Конверсия сайта

В погоне за ростом кликабельности команда performance-маркетинга усиливает креативы и офферы.

Чтобы увеличить CTR, команда:

• использует кликбейт-заголовки
• завышает скидки и обещания
• формирует ожидания, которым лендинги не соответствуют

Локальный эффект

→ Кликабельность рекламы ↑

Побочный эффект

Те же креативы:

• приводят низкоинтентный и нерелевантный трафик
• создают разрыв между обещанием в рекламе и реальностью на сайте
• превращают первый клик в мгновенный выход

→ Показатель отказов ↑
→ Конверсия карточек товаров ↓
→ Общая конверсия сайта ↓

Почему улучшение одной метрики вредит другим

У всех этих конфликтов одна и та же причина.

Когда ставятся задачи, команды редко задумываются, какие ещё метрики затронут их действия.

Оптимизация планируется локально.
Эффект измеряется локально.
Всё за пределами зоны ответственности остаётся невидимым.

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

Не хватает не усилий и дисциплины, а контекста:

• привязки задач и гипотез к метрикам, на которые они влияют
• взгляда на метрики в связке, а не по отдельности
• явного понимания компенсаций и влияний
• оптимизации системы, а не отдельных участков

Решение не в большем количестве метрик.
Решение в связи действий с метриками и метрик между собой.

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

Заключение

Цель не в том, чтобы перестать оптимизировать.

Цель — перестать оптимизировать вслепую.

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

Потому что падение конверсии может означать совершенно разные вещи:

• ухудшилось качество трафика
• перестали конвертить карточки товаров
• пользователи сомневаются после добавления в корзину
• выросло трение на чекауте
• появились проблемы со скоростью или наличием товаров

Если смотреть только на саму конверсию, ты не поймёшь, какой из этих сценариев произошёл.

Поэтому угадывание почти никогда не работает.

Вместо этого используйте алгоритм.

Он не пытается «повысить конверсию».
Он помогает понять, где именно она ломается.

Логика простая: проверка → ответ → следующий шаг.

Шаг 0. Убедись, что падение конверсии реальное

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

Сравни корректные периоды

• сравни периоды одинаковой длины
• не сравнивай неполные недели с полными

Учти сезонность и микс трафика

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

Проверь, что определение конверсии не менялось

• не менялись ли чекаут, оплата или логика трекинга
• не менялась ли логика статусов заказов

Учти задержки в данных

• в последние дни часть покупок может ещё не попасть в отчёты
• перепроверь конверсию без последних 24–72 часов

Исключи очевидные технические проблемы

• быстро пройди базовую воронку: карточка товара → добавление в корзину → корзина → чекаут → оплата
• посмотри, нет ли всплесков ошибок на этапе оплаты

Если после этого падение остаётся, идём дальше.

Шаг 1. Разбей конверсию по устройствам и браузерам

Вопрос: падение конверсии сконцентрировано на конкретном устройстве или браузере?

• в основном на одном устройстве / браузере
• равномерно на всех

Устройство / браузер   | Δ Конверсии
-----------------------------------
Мобильные              | █████◀◀◀      -16%
Десктоп                | █████████◀    -3%

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

Чаще всего это признак проблемы, которая мешает пользователю совершать действия именно в этой среде.

Что проверить

• корректно ли срабатывают события добавления в корзину и чекаута
• нет ли проблем с версткой или взаимодействием
• нет ли ошибок оплаты, ограниченных этим устройством или браузером

Если падение равномерное

Переходи к Шагу 2.

Шаг 2. Разбей конверсию по каналам и источникам

Вопрос: конверсия сильнее просела в отдельных каналах или источниках?

• да, в конкретных каналах / источниках
• нет, падение равномерное

Канал / источник       | Δ Конверсии
-----------------------------------
Платная реклама        | █████◀◀◀        -14%
Органика               | ██████████◀     -3%
Email                  | ████████▶       +1%

Если падение есть в отдельных каналах

Обычно это означает изменение качества трафика или ожиданий пользователей.

Что проверить

• менялись ли креативы или сообщения
• на какие страницы ведёт этот трафик
• не изменился ли таргетинг или микс аудиторий

Если падение равномерное

Переходи к Шагу 3.

Шаг 3. Проверь конверсию в добавление в корзину

Вопрос: пользователи стали реже добавлять товары в корзину?

• да, конверсия в добавление в корзину снизилась
• нет, она стабильна или выросла

Метрика                         | Изменение
-------------------------------------------
Конверсия в добавление в корзину | █████◀◀   -9%

Если конверсия в добавление в корзину снизилась

Проблема, скорее всего, до корзины: в поиске, выборе или карточках товаров.

Переходи к Шагу 4.

Если конверсия стабильна или выросла

Основное трение, вероятно, возникает позже.

Переходи к Шагу 5.

Шаг 4. Проверь конверсию из просмотра карточки товара в добавление в корзину

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

• да, эта конверсия снизилась
• нет, она стабильна или выросла

Категория / товар     | Δ Конверсии (карточка → корзина)
--------------------------------------------------------
Кроссовки             | ███████◀◀◀   -18%
Аксессуары            | ██◀            -4%

Если конверсия снизилась

Разбей её по категориям и товарам.

Если падение сконцентрировано — это обычно локальная проблема конкретных позиций.

Что проверить

• недоступные варианты (размеры, цвета, конфигурации)
• пропавшую или изменённую информацию
• проблемы с фото, видео, ценами или условиями

Если падение равномерное — это похоже на системную проблему карточек товаров.

Если конверсия стабильна или выросла

Карточки товаров вряд ли главный источник проблемы.

Переходи к Шагу 5.

Шаг 5. Проверь долю брошенных корзин и чекаутов

Вопрос: пользователи стали чаще бросать корзину или чекаут?

• да, доля брошенных корзин выросла
• нет, она стабильна или снизилась

Метрика                     | Изменение
---------------------------------------
Доля брошенных корзин       | ██████▶▶   +12%

Если доля выросла

Трение усилилось на этапе корзины или чекаута.

Что проверить

• на каких шагах выросло число выходов
• концентрируются ли выходы на доставке или оплате
• не появились ли новые условия или дополнительные стоимости

Если доля стабильна или снизилась

Корзина и чекаут не главная причина.

Переходи к Шагу 6.

Шаг 6. Проверь долю добавлений в избранное

Вопрос: пользователи стали чаще сохранять товары вместо добавления в корзину?

• да, доля добавлений в избранное выросла
• нет, она стабильна или снизилась

Метрика                                | Изменение
----------------------------------------
Конверсия в добавление в изобранное    | █████▶▶   +10%

Если доля выросла

Пользователи проявляют интерес, но откладывают решение.

Что проверить

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

Если доля стабильна или снизилась

Сомнения на этом этапе вряд ли объясняют падение.

Переходи к Шагу 7.

Шаг 7. Найди страницы с аномальным ростом выходов

Вопрос: есть ли страницы, где выходы выросли заметно сильнее?

• да, есть конкретные страницы
• нет, рост равномерный

Страница                  | Δ Доли выходов
------------------------------------------
Чекаут — доставка         | █████▶▶   +11%
Карточка товара           | ██▶        +3%

Если есть конкретные страницы

Это признак локального трения, часто ближе к чекауту.

Что проверить

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

Если явного паттерна нет

Скорее всего, падение вызвано несколькими факторами одновременно.

Переходи к Шагу 8.

Шаг 8. Проверь скорость загрузки страниц

Вопрос: страницы стали загружаться медленнее?

• да, скорость ухудшилась
• нет, всё стабильно или быстрее

Тип страницы              | Δ Времени загрузки
----------------------------------------------
Карточки товаров          | ███▶▶     +0.8 c
Чекаут                    | ██▶       +0.4 c

Если скорость ухудшилась

Это может мешать пользователям доходить до добавления в корзину или чекаута.

Что проверить

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

Если скорость стабильна

Переходи к Шагу 9.

Шаг 9. Проверь среднее число просмотренных страниц за сессию

Вопрос: пользователи стали просматривать меньше страниц?

• да, стали
• нет, стали больше
• показатель не изменился

Метрика                         | Изменение
-------------------------------------------
Среднее число страниц за сессию | █████◀◀   -15%

Если стали просматривать меньше

Пользователи не уходят вглубь сайта и реже доходят до товаров.

Что проверить

• изменились ли входные страницы
• есть ли разрыв между ожиданиями трафика и первой страницей
• не мешают ли поиск, фильтры или навигация

Если стали просматривать больше

Пользователи изучают сайт, но не решаются купить.

Что проверить

• хватает ли информации для выбора
• есть ли популярные варианты в наличии

Если показатель не изменился

Переходи к Шагу 10.

Шаг 10. Проверь количество просмотров карточек товаров за сессию

Вопрос: пользователи достаточно часто доходят до карточек товаров?

• нет, стали реже
• да, стали чаще

Метрика                             | Изменение
------------------------------------------------
Просмотры карточек товаров за сессию | █████◀◀   -12%

Если стали реже

Проблема, вероятно, в discovery и навигации.

Что проверить

• использование поиска, фильтров, сортировки
• пути к карточкам товаров
• где пользователи отваливаются раньше

Если стали чаще

Переходи к Шагу 11.

Шаг 11. Проверь долю товаров вне наличия

Вопрос: отсутствие товаров начало блокировать покупки?

• да, доля out of stock выросла
• нет, всё стабильно

Категория            | Доля Out of Stock
---------------------------------------
Топ-товары           | █████▶▶   +14%
Аксессуары           | ██▶        +3%

Если доля выросла

Пользователи хотят купить, но не находят доступные варианты.

Что проверить

• какие топовые товары или варианты ушли в out of stock
• концентрируется ли проблема в ключевых категориях
• находят ли пользователи альтернативы

Если доля стабильна

Скорее проблема не в наличии, а в уверенности при выборе.

Переходи к Шагу 12.

Шаг 12. Комбинируй подходы, чтобы увидеть реальную причину

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

На этом этапе перестань смотреть на метрики по отдельности и начни комбинировать срезы:

• устройство / браузер × конверсия в добавление в корзину
• канал × конверсия из карточки товара в добавление в корзину
• категория / товар × конверсия из карточки товара в добавление в корзину
• страница выхода × устройство
• среднее число страниц за сессию × канал
• отсутствие товара в наличии × категория

Именно здесь обычно и появляется настоящий паттерн, который объясняет падение конверсии.

Итоги

Конверсия не падает «мистически». Она становится непонятной только тогда, когда не ясно, что проверять дальше.

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

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

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

Заказов стало больше.
Прибыль снизилась.

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

Продажи ≠ Прибыль.

Продажи зависят от объёма:

Продажи = Заказы × Средний чек

Прибыль — это то, что остаётся после всех расходов:

Прибыль = Продажи − Расходы

Поэтому рост заказов сам по себе не гарантирует лучших результатов.

На прибыль влияет не только количество заказов, но и:

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

Заказы могут расти, а прибыль — падать.

Не потому, что «что-то сломалось», а потому что заказы — это лишь одна часть системы.

Почему заказы — рискованный KPI

Заказы измеряют активность, а не ценность.

Увеличить количество заказов довольно просто:

• скидки,
• бесплатная доставка,
• платный трафик,
• снижение порогов покупки.

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

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

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

Дальше — самые распространённые причины, почему так происходит.

#1 Заказы растут из-за скидок

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

Что делать, если подтвердилось

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

#2 Заказы растут, но в заказах меньше товаров

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

Что делать, если подтвердилось

• Пересмотреть пороги бесплатной доставки и минимального заказа
• Стимулировать бандлы и покупки нескольких товаров
• Не оптимизировать частоту заказов в ущерб размеру корзины

#3 Заказы растут, но доминируют низкомаржинальные товары

Рост заказов происходит за счёт более дешёвых или менее маржинальных товаров.

Что делать, если подтвердилось

• Ограничить промо для низкомаржинальных товаров
• Строить бандлы и апселлы вокруг высокомаржинальных позиций
• Анализировать рост заказов по группам маржинальности, а не только по объёму

#4 Заказы растут, но растёт и стоимость обработки одного заказа

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

Что делать, если подтвердилось

• Отслеживать издержки на заказ, а не только суммарно
• Пересмотреть правила бесплатной доставки и минимальные пороги
• Сегментировать издержки по регионам, размеру корзины и типам заказов

#5 Заказы растут через каналы со скрытыми комиссиями за каждый заказ

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

Что делать, если подтвердилось

• Считать прибыль на заказ после комиссий
• Сравнивать каналы по эффективности, а не по количеству заказов
• Масштабировать партнёрства только с положительной юнит-экономикой

#6 Заказы выглядят нормально, но прибыль исчезает позже

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

Что делать, если подтвердилось

• Анализировать прибыль по когортам заказов
• Найти товары и каналы с высокими пост-продажными издержками
• Корректировать промо и правила привлечения для заказов с высоким риском возвратов

Итоги

Заказы — не плохая метрика.

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

Когда заказы растут, а прибыль падает, проблема почти всегда не в объёме.

Чаще всего — в структуре:

• какие заказы растут,
• насколько они прибыльны,
• и во что они реально обходятся бизнесу.

Цель — не больше заказов. Цель — прибыльные заказы.

Потому что AOV может снижаться по совершенно разным причинам:

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

Поэтому вместо догадок используйте этот алгоритм.

Он специально сделан простым: проверили → ответили → пошли к следующему шагу.

Шаг 0. Убедитесь, что падение реальное

Перед тем как разбираться, почему упал AOV, убедитесь, что вы не объясняете шум.

• Сравнивайте корректные периоды
• Сравнивайте периоды одинаковой длины (например, последние 14 дней vs предыдущие 14 дней).
• Если обычно сравниваете неделя-к-неделе — не сравнивайте неполную неделю с полной.
• Учитывайте сезонность
• Если бизнес сезонный, дополнительно сравните с тем же периодом прошлого года (YoY).
• «Падение» может быть нормой, если вы выходите из пикового сезона или промо-недели.
• Проверьте промо и тайминг кампаний
• Были ли в прошлом периоде общая распродажа, запуск у инфлюенсера, всплеск платного трафика или email-распродажа?
• Если да, ваш «базовый уровень» мог быть искусственно завышен.
• Ищите выбросы
• Один необычно крупный заказ (B2B, почти-опт, внутренний тестовый заказ) может исказить AOV.
• Посчитайте AOV с учётом и без учёта топ-1–5 самых крупных заказов.

Если после этих проверок падение сохраняется — идём дальше.

Шаг 1. Разделите AOV на первые и повторные покупки

Вопрос: где упал AOV?

• только в первых покупках
• только в повторных покупках
• во всех покупках

Тип покупки        | Δ AOV
--------------------------------------------
Первая покупка     | █████████◀◀◀   -20%   ($120)
Повторная покупка  | ████████████▶   +1%   ($160)

Если AOV упал только в повторных покупках

Ваша стратегия удержания может возвращать людей, но с более «слабой корзиной».

Что проверить

• Работают ли email / SMS / push / ретаргетинг так, как задумано?
• Какие товары вы продвигаете существующим клиентам?
• Не сместилось ли поведение из «премиум» в «дешёвую дозакупку»?

Дальше всё равно продолжайте с Шага 3 (проблемы повторных покупок тоже могут идти от цены/количества/скидок).

Если AOV упал только в первых покупках

Переходите к Шагу 2.

Если AOV упал во всех покупках

Переходите к Шагу 3.

Шаг 2. Для первых покупок: разрежьте AOV по каналам и источникам

Вопрос: AOV упал…

• только в одном канале/источнике, или
• равномерно во всех каналах?

Канал              | Δ AOV (первая покупка)
--------------------------------------------
Paid Social        | █████████◀◀◀   -22%   ($98)
Google Ads         | ███████████◀◀   -4%   ($124)
Органика           | ████████████◀   -2%   ($131)

Если AOV упал только в одном канале/источнике

Обычно это указывает на качество трафика или несоответствие оффера.

Что проверить

• креативы и сообщения (не начали ли вы привлекать «охотников за скидками»?)
• лендинги и товарные страницы, куда ведёт реклама
• какой товарный микс продвигается в этом канале

Если AOV упал равномерно во всех каналах

Переходите к Шагу 3.

Шаг 3. Проверьте среднюю цену товара (API)

AOV может падать просто потому, что люди покупают более дешёвые товары.

Вопрос: упала ли API (Average Price per Item)?

Метрика                 | Δ AOV и API
--------------------------------------------
Средний чек (AOV)       | ██████████◀◀◀   -11%   ($132)
Средняя цена за товар   | █████◀◀          -9%    ($44)

Если API упал

Переходите к Шагу 4.

Если API не изменился

Переходите к Шагу 5.

Шаг 4. Если средняя цена (API) упала: разрежьте по категориям

Вопрос: API упал…

• сильнее в конкретных категориях, или
• равномерно по всем категориям?

Категория          | Δ Средняя цена за товар
--------------------------------------------
Аксессуары         | ██◀◀◀         -19%   ($18)
Одежда             | ██████◀        -2%    ($62)
Обувь              | █████████▶     +1%    ($91)

Если API упал в основном в отдельных категориях

Это указывает на проблему на уровне категории: цена или товарный микс.

Что делать

• подумать о повышении цены самых дешёвых товаров в этой категории
• или ввести минимальное количество к покупке (если это подходит вашей модели)

Если API упал равномерно по всем категориям

Падение цены системное (скидки, промо-стратегия, общий сдвиг микса).

К промо-проверкам (Шаги 8–9) вернёмся позже, но также переходите к Шагу 5 — эффекты по количеству товаров могут накладываться на цену.

Шаг 5. Проверьте среднее количество товаров в заказе (AIO)

Если цена за единицу почти не изменилась, AOV может падать потому, что люди покупают меньше товаров в заказе.

Вопрос: упал ли Average Items per Order (AIO)?

Метрика                 | Δ AOV и AIO
--------------------------------------------
Средний чек (AOV)       | ██████████◀◀◀   -11%   ($132)
Среднее кол-во товаров  | ████████◀◀      -10%   (2.1)

Если AIO упал

Что проверить

• рекомендации товаров (показываются ли они, релевантны ли, заметны ли?)
• где стоит cross-sell (корзина, PDP, checkout)
• логика бандлов и модули “frequently bought together”

Если AIO не изменился

Переходите к Шагу 6.

Шаг 6. Разрежьте количество единиц товаров (AUI) по категориям

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

Вопрос: есть ли категории, где Average Units per Item (AUI) упал сильнее?

Категория          | Δ Среднее кол-во единиц
--------------------------------------------
Добавки            | █████████◀◀◀   -18%   (1.6)
Уход за кожей      | ██◀             -2%    (1.1)
Уход за волосами   | ██◀             -4%    (1.2)

Если AUI упал в основном в отдельных категориях

Что делать

• попробовать стимулы за количество (например, скидка при покупке больше среднего по категории)
• сделать бандлы, которые соответствуют типичному поведению в этой категории

Если AUI меняется равномерно по всем категориям

Переходите к Шагу 7.

Шаг 7. Найдите товары, которые чаще всего покупают одиночной покупкой

Это практичный способ найти «одинокие» товары, которые редко провоцируют допродажи.

Вопрос: есть ли товары, которые чаще всего покупают как единственный товар в заказе?

Товар              | Δ Доля заказов с 1 товаром
--------------------------------------------
Подарочная карта   | ██████████▶▶▶   +14 п.п.  (84%)
Чехол для телефона | ███████▶▶       +9 п.п.   (71%)
Базовая футболка   | ███▶            +4 п.п.   (66%)

Если доля single-item заказов заметно выросла

Что делать

• собрать бандлы вокруг этих товаров
• добавить комплементарные товары рядом с ними (PDP, корзина, post-add-to-cart)

Если single-item поведение стабильно

Переходите к Шагу 8.

Шаг 8. Проверьте долю заказов с промокодами

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

Вопрос: выросла ли доля заказов с промокодами?

Тип заказа         | Δ Доля
--------------------------------------------
С промокодом       | ███▶▶        +12 п.п.  (38%)
Без промокода      | ██████◀◀     -12 п.п.  (62%)

Если доля заказов с промокодами выросла

Что делать

• посчитать прибыльность промо-кампаний с промокодами
• понять, какие промо «покупают выручку», но убивают маржу и AOV

Если использование промокодов стабильно

Переходите к Шагу 9.

Шаг 9. Проверьте среднюю скидку

Вопрос: выросла ли средняя скидка на заказ?

Метрика                 | Δ
--------------------------------------------
Средняя скидка в заказе | ███████▶▶   +5 п.п.   (14%)
Средний чек (AOV)       | ██████████◀◀◀   -11%   ($132)

Если Average Order Discount вырос

Что делать

• выделить заказы со скидкой выше средней
• найти, чем они отличаются:
• первые vs повторные
• канал
• категория / набор товаров
• конкретный промокод / кампания

Если Average Order Discount стабилен

Переходите к Шагу 10.

Шаг 10. Комбинируйте разрезы, чтобы найти реальный паттерн

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

Например:

• Скидка × новый vs повторный
• Средняя цена × категория × канал
• Количество товаров × канал
• Количество единиц товара × категория × скидка

Падение AOV часто происходит из-за двух накладывающихся драйверов, а не одного.

Итог

AOV не падает случайно.

Обычно «ломается» что-то под ним: цена, количество товаров, скидки или конкретный сегмент.

Этот алгоритм помогает перестать гадать и шаг за шагом дойти до причины, пока она не станет очевидной.