Конверсия: 3,80% → 2,67%
ПУЛЬС ПРОДАЖ / CASE 01 Учебный сценарий
Трафика больше.
Продаж меньше.
Что сломалось?
Как за общим падением конверсии найти конкретную точку потерь — и выбрать, что проверять первым.
01 / СИГНАЛ
−7,4 млн ₽
при росте трафика на 20%
За два сопоставимых периода по 28 дней выручка снизилась с 57 до 49,6 млн ₽. Средний чек вырос. Главный отрицательный вклад — снижение конверсии.
ГЛАВНЫЙ ВЫВОД
Первой проверяем мобильную оплату
В сценарии переход от оформления к оплаченному заказу на мобильных падает с 50% до 25%. Предыдущие шаги стабильны. Это локализация потерь; техническая причина пока не установлена.
Как превратить вывод в действие ↗03–30 августа → 31 августа–27 сентября 2026 · по 28 дней · все данные синтетические
02 / РАЗЛОЖЕНИЕ ВЫРУЧКИ
Одна просадка.
Три разных вклада.
Выручка = сессии × конверсия × средний чек. Меняем факторы по очереди и показываем, как сошлась разница.
Последовательная подстановка: трафик → конверсия → чек. Вклады зависят от порядка; сумма точно равна изменению выручки. Это арифметическое объяснение, не оценка причинного эффекта.
01
Рост трафика маскирует проблему. При прежних конверсии и чеке он добавил бы 11,4 млн ₽. Но снижение конверсии даёт вклад −20,4 млн ₽.
03 / СОСТАВ АУДИТОРИИ
Нас подвёл трафик
или сам путь?
Доля мобильных сессий выросла с 60% до 66,7%. У этого сегмента изначально ниже конверсия. Отделим изменение состава от изменения внутри сегментов.
Новые доли устройств, прежние конверсии
Изменение конверсий при новых долях
Посмотреть расчёт декомпозиции
До: 40% × 5% + 60% × 3% = 3,80%. При новом составе: ⅓ × 5% + ⅔ × 3% = 3,67%. После: ⅓ × 5% + ⅔ × 1,5% = 2,67%.
Эффект состава: 3,67 − 3,80 = −0,13 п. п. Изменение внутри сегментов: 2,67 − 3,67 = −1,00 п. п. Порядок: сначала состав, затем сегментные конверсии.
04 / ИНТЕРАКТИВНАЯ ДИАГНОСТИКА
Найдите место
разрыва.
● До● ПослеШирина полосы — доля от сессий в своём периоде
Числа — сессии, последовательно достигшие шага. Процент справа — переход с предыдущего шага. В модели максимум один оплаченный заказ на сессию.
05 / РЕШЕНИЕ
Локализовали потери.
Теперь проверяем причину.
Агрегированная воронка не различает сбой оплаты, потерю события и изменение состава покупателей. Следующий шаг — собрать различающие свидетельства.
| Гипотеза | Что проверить | Когда менять решение |
|---|---|---|
| Потеря события покупки | Сверить оплаченные заказы в backend с событиями по order_id, периоду и устройству | Если заказы есть, а события потеряны — исправлять измерение и пересчитывать воронку |
| Ошибка мобильной оплаты | Логи шлюза, коды ошибок, браузеры и способы оплаты; воспроизведение на устройствах | Если есть совпадающий рост ошибок — исправить подтверждённый дефект |
| Изменился состав покупателей | Каналы, новые/повторные покупатели, сумма корзины и способы оплаты | Если падение объясняется составом — пересмотреть сегментацию и приоритет гипотез |
ПЕРВЫЕ 48 ЧАСОВ · ПЛАН
Сверить → локализовать → воспроизвести
Аналитик проверяет полноту данных и сегменты. Разработчик и QA — путь оплаты и логи. Владелец продукта принимает решение после сверки фактов.
Известный дефект исправляем. Для изменения интерфейса без доказанного дефекта заранее проектируем эксперимент.
КРИТЕРИЙ ПРОВЕРКИ
Оплаченные заказы, а не клики
Основная метрика — доля пользователей с оплаченным заказом; защитные — ошибки оплаты и возвраты. Для эксперимента нужны пользовательские данные, расчёт выборки и фиксированный горизонт.
Таблица сессий этого кейса не позволяет оценить значимость пользовательского A/B-теста.
06 / ЦЕНА ВОПРОСА
Каков масштаб
возможности?
Смоделируйте восстановление мобильного перехода «оформление → оплата». Трафик, число оформлений и средний чек фиксированы на уровне второго периода.
Без восстановленияДо прежних 50%
Дополнительная выручка за 28 днейСценарная оценка, не прогноз и не достигнутый результат. Без себестоимости, возвратов и затрат на изменение.
07 / МОЖНО ПРОВЕРИТЬ
Открытая логика.
Честные границы.
Этот кейс демонстрирует метод диагностики. Все числа заданы в генераторе; никакой клиентский рост или реальное внедрение здесь не заявлены.
Данные, определения и проверка качества
Единица строки — период × устройство. Каждый период содержит 28 дней и одинаковый набор дней недели. Это не исключает сезонность в реальном проекте. Сессия относится к одному периоду и устройству. Оформление и оплата происходят внутри той же сессии.
Конверсия = оплаченные заказы / сессии. Средний чек = выручка / оплаченные заказы. Выручка — стоимость оплаченных заказов до возвратов; прибыль не оценена. Нет пользовательских идентификаторов, каналов, ошибок и логов — причины по ним не проверены.
Автоматически проверены монотонность воронки и сходимость разложения выручки. В реальном проекте дополнительно обязательны сверка с backend, проверка дублей и полноты событий. Здесь такие проверки не заявлены как выполненные.
Исходная таблица сценария
Что могло бы опровергнуть вывод
Если backend показывает стабильную долю оплат на мобильных, подозрение смещается к измерению. Если снижение исчезает после детализации по способам оплаты и каналам, первичная сегментация недостаточна. Если покупки стали завершаться в следующей сессии, требуется другое окно воронки.
✓
Результат работы в кейсе: локализован участок потерь, отделён эффект состава трафика, определены проверки альтернативных причин и рассчитан диапазон сценарного эффекта. Следующий результат должен появиться после проверки на реальных данных.
НАТАЛЬЯ ВЕТОШКИНА / АНАЛИТИКА ДЛЯ РЕШЕНИЙ
У вашей воронки
тоже есть вопросы?
Такой подход помогает связать качество данных, поведение пользователей и приоритеты продукта.
Профиль и контакты ↗Ещё один взгляд: dashboard и Data Art ↗