Анализ воронок
Моделирование воронок, пошаговая против сквозной конверсии, окна, множественный вход и разбор просадок.
8 вопросов
JuniorТеорияОчень частоЧто такое воронка конверсии и чем пошаговая конверсия отличается от сквозной?
Что такое воронка конверсии и чем пошаговая конверсия отличается от сквозной?
Воронка — это упорядоченная последовательность шагов, которые пользователь проходит к цели. Пошаговая конверсия — доля тех, кто переходит с одного шага на следующий; сквозная — доля тех, кто завершает весь путь. Сквозная равна произведению пошаговых, поэтому доли перемножаются, а не усредняются.
Типичные ошибки
- ✗Усреднять пошаговые доли вместо их перемножения для сквозной конверсии
- ✗Считать воронку неупорядоченным набором событий, а не последовательностью
- ✗Полагать, что сквозная конверсия равна проценту самого слабого шага
Уточняющие вопросы
- →Если два шага конвертируют по 50%, какова сквозная конверсия по обоим?
- →Почему добавление шага в воронку может только снизить сквозную конверсию?
JuniorТеорияЧастоЧто делает событие конверсией и почему «нажал кнопку Купить» — это не то же, что «купил»?
Что делает событие конверсией и почему «нажал кнопку Купить» — это не то же, что «купил»?
Событие конверсии — залогированное действие, отмечающее нужный исход: завершённую подтверждённую покупку, а не намерение купить. «Нажал Купить» — лишь намерение: оплата ещё может не пройти, а пользователь уйти. Считают серверное событие заказа, задав его один раз и применяя единообразно на каждом шаге.
Типичные ошибки
- ✗Считать клик-намерение завершённой покупкой
- ✗Доверять клиентскому клику больше, чем подтверждённому сервером заказу
- ✗Переопределять событие конверсии по-разному на каждом шаге
Уточняющие вопросы
- →Почему клиентский клик «Купить» может завышать счёт против серверного заказа?
- →Как задать событие подтверждённой покупки, чтобы все шаги сходились?
JuniorТеорияЧастоВоронка идёт 1000 → 600 → 300 → 60 пользователей. Каковы пошаговые доли, сквозная и наибольшая просадка?
Воронка идёт 1000 → 600 → 300 → 60 пользователей. Каковы пошаговые доли, сквозная и наибольшая просадка?
Пошаговые доли — 600/1000 = 60%, 300/600 = 50% и 60/300 = 20%. Сквозная — 60/1000 = 6%, равная 0.6 × 0.5 × 0.2 — произведению пошаговых. Самая низкая доля у последнего шага, 20%, но наибольшая абсолютная потеря на первом, теряющем 400 пользователей.
Типичные ошибки
- ✗Усреднять или суммировать пошаговые доли вместо перемножения для сквозной
- ✗Считать, что шаг с низшей долей теряет и больше всего людей в абсолюте
- ✗Читать сквозную конверсию как долю единственного худшего шага
Уточняющие вопросы
- →Какой шаг теряет больше всего людей в абсолюте и почему это не последний?
- →Как изменится сквозная доля, если последний шаг удвоится до 40%?
MiddleКодЧастоПостройте упорядоченную воронку view → cart → purchase из сырого лога событий
Постройте упорядоченную воронку view → cart → purchase из сырого лога событий
Сводят лог к одной строке на пользователя с первым временем каждого шага через MIN(event_time) FILTER (...) с GROUP BY user_id. Затем считают на шаг с условиями порядка и окна: cart после view, purchase после cart, каждый в пределах 7 дней от первого view — делая каждый шаг строгим подмножеством верхнего.
Типичные ошибки
- ✗Считать строки событий вместо дедупа до уникальных пользователей на шаг
- ✗Считать принадлежность к шагу без условий порядка или окна
- ✗Опираться на разрыв по модулю, допуская покупку раньше её cart
Уточняющие вопросы
- →Почему
MIN(event_time) FILTER (...)на пользователя держит счётчики монотонными? - →Как привязать окно 7 дней к соседнему шагу, а не к входу в воронку?
MiddleДебаггингЧастоПочините запрос воронки, показывающий больше покупок, чем добавлений в корзину
Почините запрос воронки, показывающий больше покупок, чем добавлений в корзину
Две ошибки завышают purchased: он берёт COUNT(*), поэтому повторы считаются многократно, и считает всех покупателей — включая купивших через «Buy Now», не положив в корзину. Дедупят до уникальных пользователей и требуют, чтобы покупка шла за первым cart в окне. Тогда она — строгое подмножество carted.
Типичные ошибки
- ✗Брать COUNT(*), из-за чего повторные покупки завышают шаг
- ✗Считать всех покупателей, включая тех, кто ни разу не клал в корзину
- ✗Считать, что покупка всегда подразумевает предшествующий по порядку cart
Уточняющие вопросы
- →Почему прямые покупки «Buy Now» могут ломать монотонность воронки?
- →Как окно конверсии не пускает несвязанную позднюю покупку в счёт?
MiddleДизайнЧастоВаша воронка оформления — view → cart → shipping → payment → confirmation. За последнюю неделю конверсия shipping → payment упала с 70% до 58%, тогда как все прочие шаги держатся, и никакой релиз это не объясняет. У вас есть полный лог событий с user_id, шагом, временем, устройством, браузером, версией приложения, страной и способом оплаты. Опишите, как вы диагностируете просадку — что проверяете первым, как решаете, реальное это изменение поведения или артефакт данных/трекинга, и как локализуете причину до конкретного сегмента, прежде чем предлагать фикс.
Ваша воронка оформления — view → cart → shipping → payment → confirmation. За последнюю неделю конверсия shipping → payment упала с 70% до 58%, тогда как все прочие шаги держатся, и никакой релиз это не объясняет. У вас есть полный лог событий с user_id, шагом, временем, устройством, браузером, версией приложения, страной и способом оплаты. Опишите, как вы диагностируете просадку — что проверяете первым, как решаете, реальное это изменение поведения или артефакт данных/трекинга, и как локализуете причину до конкретного сегмента, прежде чем предлагать фикс.
Сначала исключают артефакт трекинга — проверяют объём событий, недавний деплой или смену SDK и не перестало ли событие оплаты логироваться. Затем режут шаг shipping→payment по устройству, браузеру, версии приложения, стране и способу оплаты: просадка в одном сегменте указывает на конкретный сломанный путь, а равномерная — на глобальное изменение.
Типичные ошибки
- ✗Прыгать к гипотезам до проверки, что данные реальны и полны
- ✗Ранжировать сегменты по конверсии без учёта размера выборки и шума
- ✗Считать просадку шага непременно артефактом, а не реальным поведением
Уточняющие вопросы
- →Как отличить реальную просадку поведения от переставшего логироваться события?
- →Почему взвешивать просадку сегмента на его объём пользователей до действий?
MiddleДизайнЧастоВоронка идёт 100000 визитов → 60000 просмотров товара → 12000 корзин → 6000 покупок, и каждая покупка стоит 50 долларов. Команда реалистично может поднять конверсию ровно одного шага на 20% относительно. У шага view → cart самая крутая просадка. Объясните, как вы решаете, какой шаг улучшать ради наибольшей дополнительной выручки, почему крупнейшая просадка — не автоматически верная цель, и что вы посчитаете, чтобы ранжировать шаги по возможности.
Воронка идёт 100000 визитов → 60000 просмотров товара → 12000 корзин → 6000 покупок, и каждая покупка стоит 50 долларов. Команда реалистично может поднять конверсию ровно одного шага на 20% относительно. У шага view → cart самая крутая просадка. Объясните, как вы решаете, какой шаг улучшать ради наибольшей дополнительной выручки, почему крупнейшая просадка — не автоматически верная цель, и что вы посчитаете, чтобы ранжировать шаги по возможности.
Ранжируют шаги по дополнительным покупкам от каждого подъёма на 20%, а не по величине просадки. Подъём раннего шага разбавляют все нижележащие доли, а подъём в конце воронки конвертируется почти напрямую в покупки. Считают доп. конверсии каждого шага до покупки, оценивают в 50 долларов и берут наибольшее.
Типичные ошибки
- ✗Приравнивать крупнейшую просадку к крупнейшей возможности по выручке
- ✗Игнорировать, что подъём раннего шага разбавляют все нижележащие доли
- ✗Ранжировать шаги по доле конверсии, а не по дополнительным покупкам
Уточняющие вопросы
- →Почему подъём на 20% в конце воронки конвертируется почти напрямую в покупки?
- →Как объём трафика шага меняет то, какой подъём даёт больше выручки?
SeniorДизайнИногдаВаш PM настаивает, что продуктовая воронка — чистый линейный путь signup → activate → subscribe, но данные показывают, что пользователи входят на разных шагах, активируются до регистрации через приглашения, возвращаются к шагам не по порядку, а часть подписывается спустя месяцы. Наивная линейная воронка за фиксированный календарный месяц выдаёт низкую, нестабильную конверсию. Объясните, как вы смоделируете воронку, которая не строго линейна и имеет множественный вход, и опишите, что окно конверсии делает с числом — в частности, почему недавние вошедшие делают его хуже, чем оно есть.
Ваш PM настаивает, что продуктовая воронка — чистый линейный путь signup → activate → subscribe, но данные показывают, что пользователи входят на разных шагах, активируются до регистрации через приглашения, возвращаются к шагам не по порядку, а часть подписывается спустя месяцы. Наивная линейная воронка за фиксированный календарный месяц выдаёт низкую, нестабильную конверсию. Объясните, как вы смоделируете воронку, которая не строго линейна и имеет множественный вход, и опишите, что окно конверсии делает с числом — в частности, почему недавние вошедшие делают его хуже, чем оно есть.
Моделируют как упорядоченные пары шагов с окном конверсии, а не один жёсткий путь: закрепляют вход на настоящем шаге, допускают несколько точек входа, требуют, чтобы нижележащие шаги шли в окне. Окно право-цензурирует недавних вошедших — у них ещё не было полного окна — поэтому их учёт тянет долю вниз; мерят только когорты, чьё окно истекло.
Типичные ошибки
- ✗Загонять реально многовходовое, беспорядочное поведение в жёсткий линейный путь
- ✗Смешивать недавних, право-цензурированных вошедших с истёкшими когортами
- ✗Расширять окно вместо когортирования, чтобы убрать смещение цензурирования
Уточняющие вопросы
- →Как вы выберете длину окна конверсии для этой воронки?
- →Почему замер только истёкших когорт стабилизирует заявленную долю?
