Воронки конверсий — популярный инструмент, который сейчас используется почти в любом коммерческом продукте.
Считается, что эта штука быстро и гибко отвечает на разные важные практические продуктовые вопросы.
Предлагаю вместе проговорить границы применимости воронок и рассмотреть методологию, которая может эффективно дополнить уже существующие у вас инструменты анализа пользовательского поведения.
Дисклеймеры
Данная статья - обобщение выступления на конференции Матемаркетинг-2025.
Ниже будет много примеров, которые сделаны по мотивам продуктовых ситуаций в компании Литрес. У нас сложный и интересный продукт. В контексте данного разговора, мы - типичный e-commerce среднего размера. Поэтому истории, которые мы будем рассматривать, должны быть понятны как небольшим стартапам, так и большим экосистемам.
Некоторые примеры будут споровождаться численными значениями метрик. Но все метрики условные. Это лишь примеры, которые не имеют никакого отношения к реальным данным никаких компаний. Все сходства - совпадения.
Продукт глазами пользователя
Давайте представим себе типичный путь пользователя в продукте.
Должно получиться как-то так:
Где-то в недрах рынках есть замечательная аудитория. Так или иначе она нахолдит наш замечательный продукт, быстро понимает его преимущества, легко расстаётся с деньгами, получает все блага данного продукта, понимает его ценность, с радостью возвращается и охотно продолжает цикл повторных продаж, привнося всё больше и больше в наши любимые три буквы LTV.
Ну или не так всё круто, но суть та же. Какая-то часть продукта (или все) может быть не такой хорошей, тогда метрики в этой часть будут чуть хуже. И это будет слабое место продукта. Туда надо отправить максимум ресурсов для улучшения ситуации.
И самое интересное в том, что такая картина мира вполне себе подтверждается на данных. Так что на этом этапе абстракции всё ок.
Проблема в том, что на таком уровне сложно принимать решения. Поэтому логично рассматривать более подробную ка��тину:
Тут - тот же пользовательский путь "из головы", но происходит две важные вещи: детализация и делегирование.
Продукт не просто делится на части, каждая часть "помещается в клетку", этой клетке назначается ответственный, ответственному - KPI, рамки, в которых нужно работать. Причём рамки эти максимально простые: нужно "протащить" максимум аудитории через свой участок с минимальными потерями. У каждого участка есть свой кусочек конверсии, итоговая конверсия - просто произведение этих участков.
Дальше строятся длинные воронки вроде такой:
Ну а дальше - дело техники. Итоговая конверсия - это просто произведение конверсий на промежуточных этапах. Там, где эти конверсии проседают - там у нас bottleneck, там надо чинить. Смотрим результат починки в A/B-тесте, если конверсия выросла - значит, мы сделали продукт лучше.
Вот на этом этапе картина иделаьного мира и реальное пользовательское поведение на данных расходятся. Причём сразу по многим аспектам.
Давайте разберём, что же пошло не так.
Наивные воронки
Начём с первой проблемы: воронки, в целом, норм, но мы не всегда работаем с настоящими воронками. Как же "царь" может быть "ненастоящим"?
Давайте рассмотрим простой пример:
У нас есть Яндекс.Метрика, мы в ней насчитали за какой-то период всего 3000 сессий, класс. Ещё у нас есть никак не связанная с Метрикой CRM-система. В ней мы насчитали за какой-то период всего 800 покупок. Ну что, вот у нас есть воронка "визит => покупка" с конверсией 800 / 3000 = 26%. Мы - идеальны!
Надеюсь, в таком утрированном примере понятно, что жизнь немного сложнее и текущая "воронка" не совсем отображает действительность.
Мы называем такие воронки "наивными". Они вроде есть, они что-то показывают, но они "ненастоящие". К сожалению, обстоятельства скаладываются так, что с ними приходится иметь дело чаще, чем нам бы хотелось. Работаем с тем, что есть, главное - понимать, чем мы пренебрегаем и как это может по нам ударить.
Признаки "наивной воронки"
Разные источники данных
В примере выше мы сравнивали сессии (совокупности хитов, связанные по времени) и покупки (строчки в таблице покупок). Это разные единицы измерения. И ни один из них не связан напрямую с пользователем (живым человеком, который принимает решения): на одного пользователя в день может прийтись несколько покупок и десяток сессий. Результат любой арифметической операции с такими величинами будет неожданным, гарантирую вам.
Иногда бывает так, что можно сравнивать разные единицы измерения. Но в контексте воронок это редко происходит от хорошей жизни. Если вы попали в такую ситуацию, будьте особенно аккуратны когда происходит изменение структуры трафика (например, когда начался сезонный рост\падение). И смотрите долгорочные тренды. Например, доля кук на одного живого пользователя в современных браузерах неизменно со временем растёт.
Нет единого процесса
В примере выше нет никакой интеграции между Метрикой и CRM-системой. По большому счёту у нас нет вооб��е никакой гарантии, что эти множества вообще пересекаются хотя бы на одном человеке.
Понятно, что сделать единый "сквозной" процесс по всем правилам достаточно сложно, а часто - не нужно. Но неплохо иметь хотя какие инструменты проверки связности систем.
Например, можно сделать событие покупки в Метрике. Да, оно будет неточным, данные в Метрике и CRM никогда не сойдутся копейка в копейку. Но хочется понимать порядок расхождения. И, желательно, видеть динамику: если одна метрика падает, неплохо бы увидеть и паденние второй.
Можно сделать и обратный процесс: пробросить внутренний user_id в метрику. Тогда можно по логам посмотреть путь конкретного пользователя и понять, что именно он записан в CRM. Это сложно, это муторно, но это даёт нам не просто гарантию связности, но и возможности локализовать проблемы на уровне конкретных пользователей и транзакций, когда (не если!) возникнут проблемы, баги или значительные расхождения.
А ещё лучше, конечно же, сделать оба процесса.
Нет окна конверсии (или оно бесконечное)
В примере выше нет дат, за которые метрики считались. Здравый смысл, конечно, подсказывает, что неплохо бы взять метрики за один и тот же период времени. По одной картинке мы не можем быть в этом уверенными.
Опустим пока сложности с определением точного времени в разных системах и особенностях клиент-серверного взаимодействия. Давайте зададим более простой и более бизнесовый вопрос. Допустим, вчера пользователь был у нас на сайте. И покупка у нас тоже есть, но, вот какая беда, так получается, что они была до визита. Можно ли собрать эти два процесса в одну воронку? Нет, конечно. Воронка на то и воронка, что сначала был первый шаг, а потом - второй.
Или другой пример. Визит был вчера, а покупка отобразилась сегодня. Надо ли её засчитывать? Тут зависит от специфики воронки и бизнеса в целом. Иногда необходимо выдержать широкое окно (время медду первым и вторым событием). Например, пару недель для атрибуции медийной рекламы - это нормально. А иногда мы можем "засчитать" только очень узкое окно. Например, десятки секунд между кликом по кнопке и срабатыванием тригера этой кнопки.
В любом случае, нам нужно точно знать время между событиями. Если его у нас нет, если мы его не измеряем - мы отказывается от такого понятия, как окно конверсии. И рискуем получить серьёзные проблемы.
Иногда окно конверсии можно "доверить" внешним системам (трекерам или аналитическим системам). Но если у вас нет даже теоретической возможности проверить логику их работы, то вы не являетесь владельцами собственных данных. И тогда неоптимальное измерение конверсии - наименьшее из ваших проблем.
Иногда неизвестное и неизмеряемое время конверсии лечится большим количеством промежуточных событий. Но это повышает всю сложность системы и имеет определённые минусы.
И, конечно, бесконечное окно конверсии фактически запрещает вам смотреть динамику ваших конверсий: она всегда будет убывающей. Но не потому, что продукту плохо. Просто у пользователя, который пришёл год назад, был год, чтобы совершить полезное действие, а у пользователя, который пришёл вчера - всего сутки.
Нет когорт
Когорты (люди, которые пришли в продукт в одно и то же время) забывают чаще всего. Казалось бы, какая разница, когда ты пришёл, вот есть ты, пользователь, вот есть утюг, пользователю нужен утюг - покупай.
Увы, новые и старые пользователи реагируют на продукт очень по-разному. Спешу напомнить, что "тот самый" сканадальный релиз Кинопоиска успешно прошёл A/B-тестирование и проказал отличные метрики на новых пользователях. Но старых спрашивать не стали. Вышло громко. У ��ас может выйти тихо, вы просто не увидите роста выручки, который могли получить, если бы построили "правильную" воронку.
А если мы много чего продаём?
Схема выше на данных может соответствуовать действительности только для очень простого продукта. Например, для интернет-магазина, который продаёт эти самые утюги и только их.
И то недолго. Рано или поздно вы всё равно захотите или ваши поставщики предложат вам продавать не только утюги, но ещё и фены, плойки, микроволновки.
И как только у вас будет больше одного SKU, вся схема значительно усложнится.
У вас будет более сложная навигация, потому что среди этого набора SKU теперь надо чего искать.
И у каждого товара будут свои конверсии, свои воронки. И что такое итоговая конверсия?
И, конечно, сильно усложняется маркетинг. Раньше можно было просто рекламировать утюги. А тут теперь выбор: компания на утюги, компания на микроволновки или брендовая компания, а пользователь сам уже выберет, что ему нужно.
А по компании на микроволновки всё ещё покупают утюги. Это хорошо или плохо?
А почему в микроволновках конверсия такая низкая? Это у нас товар такой плохой? Товар хороший, но его никто не видит? Или наш уважаемый маркетинг не умеет привлекать аудиторию?
Понятно, что все эти вопросы решаемы. Понятно, что товары можно собирать в категории, растить бренд. И даже, может быть, получить дополнительные продажи на синергии.
Но обратите внимание на то, как простое и логичное усложнение лишь одного этапа привело к уложнению процессов по всей цепочке.
Вопросы навигации
А ещё у вас, наверняка, есть несколько каналов навигации. Кто-то использует Google для поиска карточки конкретного утюга у вас на сайте. Наверное, у вас есть и внутренний поиск, а ещё каталог. А вот вы недавно рекомендательную систему запилили, она ведь у всех есть, чем вы хуже?
Как будет выглядеть CJM тогда?
У этих каналов навигации будут не просто разные конверсии, у них будут разные по структуре воронки. Где-то из двух шагов, где-то и 6 может набраться. Конечно же, у этих каналов навигации будут свои ответственные, которые будут драйвить собственные метрики.
И будет велик солблазн считать, что маркетинг - это такая многофункциональная шахта, которая майнит пользователей, которые "созданы" для того или иного канала. Но это не так. Пользователь приходит к вам не за каналом навигации, а за продуктом. И он выбирает такой канал, который кажется ему здесь и сейчас наиболее удобным. Изменится ситуация - изменится и поведение. Изменение в одном канале повлияет на поведение в остальных.
Но увидеть это на классических воронках очень сложно. В лучшем случае посмотрим итоговое влияние на LTV, но это не самый универсальный ответ.
Все эти проблемы тоже, конечно, решаемыю Это всё можно чинить, строить правильные воронки исходя из здравого смысла. Лучшие из нас могут оценивать эффекты на систему целиком.
Но ещё не всё.
Фундаментальная проблема воронок
Давайте рассмторим пример того же простого интернет-магазина по продаже утюгов.
Допустим, у них вот такая основная воронка:
Скажите, достаточно ли этой информации для того, чтобы понять, где у нас проблема? Ведь именно это мы вроде ждём от воронок.
Но если мы не аккумулируем опыт, а просто решаем математическую задачу "поднятие какой конверсии на 1% приведёт к маскимизации выручки", то нам нужно идти и "чинить" конверсию из карточки товара в чекаут (4 столбик).
Но вообще это далеко не самая оптимальная рекомендация. Переход с карточки товара в чекаут - это место, где пользователь принимает решение расстаться с деньгами. Какая-то просадка на этом этапе нормальна. В том числе потому, что на этом этапе отваливаются поисковые боты, парсеры и люди, не имевшие изначальной цели купить. Литрес часто используют как площадку для поиска хороших книг, чтобы скачать их потом на пиратском ресурсе.
Более того, если мы подключим данные по рынку (или иные бенчмарки), то поймём, что конверсия в 15% на этом этапе - это хорошая (если не отличная) конверсия. Тот человек, который сделал такую карточку товара - молодец. Если, конечно, он не занимался каким-то читерством вроде продажи товаров ниже себестоимости. У этого человека имеет смысл поучиться, какие-то элементы переиспользовать. А вот значительно ещё улучшить эту конверсию у вас, скорее всего, не получится. Объективно сложно "починить" тот элемент, что работает лучше всего в системе.
Но поняли мы это всё не по графику.
А вот bounce rate (отвел из маркетинга в первую сессию, 2 столбец на графике выше) в 40% - это катастрофа. Так сильно его испортить - это надо постараться. Это что-то вроде непропускаемой видеорекламы сразу на входе. А поверх - принять куки, приглашение зарегистрироваться и ещё пару поп-апов. Или другая гипотеза: какой-то маркетинговый источник ведёт ну совсем нерелевантную аудиторию
И это мы тоже поняли не по графику.
Рекомендация при этом простые. В первом случае - отлючить всё, что можно законно отключить и бесит лично вас. Можно без A/B-тестов. Если вам нужно было разрешение, то вот оно: если у вас такие отказы, я разрешаю вам сразу отключить то, что вам очень хочется отключить.
Во втором случае рекомендация тоже простая: посмотреть отказы в разбивке по каналам. Если есть канал, который сильно "фонит", внести в нём корректировки вплоть до отключения и перезапуска. Это не обязательно косяк маркетологов, бывает так просто складывается жизнь. Например, в Литрес высокие отказы на карточках книг, по которым недавно сняли фильмы или сериалы. Механика простая: человек посмотреть что-то хотел, вбил в поиске, а ему читать предлагают. Возмутительно!
Итак, если бы смотрели только на график, то пошли бы чинить там, где всё работает хорошо. Но с подключением внешней информации мы быстро локализуем проблему и формирует рекомендации по тому, как сделать продукт лучше.
Как же так вышло? К сожалению, это неизбежно. Процессы в продукте могут сложными, поэтому одной воронки недостаточно для поиска слабых мест или точек роста. Воронкам нужны бенчмарки, коридоры, в которых понятно, что ситуация хорошая или плохая. Где их брать? Это вечная проблема. Что-то мы знаем на опыте, что-то нам могут подсказать коллеги, которые работали в другом продукте. Чуть-чуть бенчмарков есть в интернете. Мы сами можем их генерировать: сравнивать сегменты между собой, придумывать контрольный процесс. Или просто смотреть динамику конверсий.
Но универсального решения не существует. И чем более сложный у нас процесс, чем больше факторов взаимодейтсвует, чем сильнее этот процесс отличается от других продуктов, тем сложнее находить бенчмарки под все наши воронки.
Мы будет стараться, мы будет включать данные рынка, наш опыт и здравый смысл и как-то с этим справимся.
Но есть ещё одна проблема. А кто вам вообще сказал, что люди вообще действуют рационально?
Нерациональное поведение пользователя
Давайте просто примем этот факт: люди нерациональны. Мы все - нерациональны. Нас много, у нас есть привычки, интересы, мы регулярно принимаем решения на эмоциях. Бывает так, что это выходит нам боком. Но ещё чаще это выходит боком для продуктов, которые созданы с расчётом на "рациональное" поведение пользователей.
Ниже я покажу пару примеров реальных пользовательских историй. Настоятельно рекомендую периодически посматривать вебвизор или, ещё лучше, смотреть пользовательские логи. Это отличный инструмент для того, чтобы понять свой продукт и увидеть очень много отчаяния.
Первый пример
Пользователь пришёл на карточку книги, которая ему (как мы теперь знаем) достаточно интересна. Но не купил.
Конечно же у нас есть популярный блок "с этой книгой часто читают". А раз есть блок, значит, по нему нажимают. Но что-то пошло не так и пользователя мы потеряли.
Потом - ура! Он вернулся, в рекомендациях ему показали ту же книгу и он её благополучно купил.
Велика вероятность, что на переходе между карточкой книги и "похожими книгами" что-то пошло не так. Сложно на этих данных сказать, что именно, но как будто какая-то проблема с UX.
Насколько серьёзной должна быть проблема, чтобы мы с помощью только стандартного набора воронок её локализовали? Конечно, у многих есть опытные продакты и аналитики, которые могут посмотреть на окна и кнопки и понять, на какой участок цепочки нужно посмотреть внимательно. Но это же тоже простой пример, а бывают гораздо сложнее.
Ещё один момент. В итоге покупка была сделана с помощью механики рекомендательной системы. По воронкам этой части продукта всё будет замечательно: пришёл человек, ему показали, он купил. Но мы сейчас видим, что это минимум второе касание с данной книгой. Не выйдет ли так, что мы переоценим в данном случае эффективность нашего рекомендательного алгоритма?
И последний вопрос. Можем ли мы сказать, сколько нам стоит такой отвал? В данном случае нам повезло, пользователь вернулся сам и активировался рекомендательной системой. А если бы его по рекламе пришлось бы возвращать? Не вышло бы так, что его стоимость привлечения удвоилась бы? А смогли бы мы это корректно посчитать?
Второй пример
Тут тоже интересно. Пользователь долго бродил по каталогу, искал себе интересный детектив. Но не смог ничего выбрать. В какой-то момент он увидел рекламу книги по саморазвитию и успешно купил её.
Ну тут вроде просто две не связанные между собой воронки. Пользователь махнул рукой на одну свою потребность и пошёл закрывать другую. Или нет? Может быть, между этими запросами есть какая-то неявная связь?
Может ли здесь быть точка роста у продукта? Коммерческая реклама контента по саморазвитию сейчас дорогая. Может быть, проще находить свою аудиторию через детективы, а потом предлагать ей книги по саморазвитию?
Третий пример
Это мой любимый пользователь. Он упорен, он неудержим!
Он дошёл до карточки одного и того же автора всеми возможными способами. И каждый раз отлетал.
Скорее всего, пользователь ждёт новой книги этого автора. Но автор не пишет. Или пишет, но у нес нет возможности эту книгу продавать.
Пользователю бы подписаться на автора. Когда новая книга выйдет - он узнаем об этом. У нас есть такой функционал. Но пользователь либо его не заметил, либо по своим причинам не хочет получать от нас лишние сообщения.
Какую ценность представляет для нас такой пользователь? Вроде бы никакую, так как ему нечего в данный момент продать. Но такое упорство, такой опыт в нашей навигации точно делает его чуть более ценным пользователем, чем просто средний человек "с улицы".
Концепция ценности действий
Как же нам дополнить наши воронки, чтобы отвечать на большее количество возникающих вопросов?
Есть такой инструмент. Давайте представим, что мы ловим вот такое состояние пользователя:
У нас есть какой-то хороший (большой, но однородный) сегмент лямбда (а кроме него есть альфа, сигма и другие всякие буквы). У этого сегмент есть какое-то ожидаемое LTV (в данном случае 5000 монгольских тугриков).
И вот есть пользователь из этого сегмента, который готовится воспользоваться внутренним поиском. Такие люди (сегмент + состояние) обычно заканчивают сессию успешной покупкой с вероятностью 15%.
Тогда мы можем просто расчитать математическое ожидание value с данного пользователя в данном сегменте в данном состоянии путём несложной операции умножения.
Если состояние называется успешная покупка, то это value в пересчёте на всех пользователей совпадает с таким понятием как ARPU (average revenue per user). А теперь мы берём, и обобщаемся ARPU на любые события в наших логах.
Это уже хорошо, т.к.
эта метрика измерима
эта метрика связана с деньгами
её можно пересчитать для всех состояний и всех сегментов
это инструмент для ранжирования
Теперь берём следующее состояние пользователя:
Теперь пользователь не просто начинает поиск, он применяет фильтры в поиске (например, выбрал, что хочет искать только аудиокниги).
Теперь конверсия, по нашим данным, стала выше. Это логично: во-первых, действие ниже по воронке, во-вторых, пользователь явно акцентирует, что он хочет. А те, кто знают, что хотят, достаточно часто это находят.
У этого состояния мы тоже может посчитать матеметическое ожидание.
И теперь, самое главное, можем расчитать ценность перехода:
И получается, что мы сейчас расчитали продуктовую ценность вот этой вот стрелочки на схеме.
А это значит, что если у нас есть какая-то идея по тому, как перетащить больше пользователей из состояния 1 в состояние 2 (например, сделать более удобьный фильтры для поиска или добавить больше нужных), то у нас есть не просто достойная проверкой A/B-тестом продуктовая гипотеза, но и сразу числовая мера её важности для будущей выручки.
Эту меру можно добавить в ICE, RICE или иную методологию.
Эта мера имеет прямое связь с выручкой, так что можно напрямую сравнивать с костами на требуемую разработку.
А ещё эта штука лишена большого числа недостатков, которые мы обсуждали выше.
А если вместо выручки мы поставим во все эти действия стоимость привлечения пользователя (например, расходы на рекламу), то кроме ценности получим ещё и стоимость действий и переходов. И unit-экономика заиграет новыми красками!
Осталось всего ничего: взять настоящий, не модельный, пользовательский путь из логов, посчитать вес, ценность и стоимость каждой стрелочки, найти настоящие пути, настоящие воронки и работать дальше только с ними.
Но быстрой победы не будет
Почему же?
Ну потому что, если мы построим CJM на фактических данных, то он будет выглядет вот так:
На это полезно посмотреть глазами, подвигать бегунки. Но вообще, штука сложная. Причём не просто своей шириной, а тем, что реальные пользовательские пути редко полностью "разматываются".
Алгоритмически считать и ранжировать это тоже сложно. Алгоритмы на деревьях не работают: циклы встречаются регулярно. Алгоритм поиска кратчайшего пути с макимальным весом рёбер в общем случае имеет очень высокую сложность по числу узлов. И он тоже не будет работать!
Потому реальный CJM что это не даже не граф! Тут имеет важность гистерезис: в начале сессии зайти на карточку автора - хороший сигнал, в конце зайти туда ещё раз - это уже жест очаяния.
Надо придумывать упрощения.
Гипотеза, упрощая расчёты
Здесь и далее мы будем считать не произвольный граф, а граф реального пользовательского поведения в b2c e-commerce продукте, разбитого по бизнес-значимым сегментами.
И мы будем считать, что наибольшее влияние на будущее состояния пользователя влияют его текущее и прошлое состояние.
Да, мы предположим, что касания пользователем продукта - это марковский процесс.
Насколько экзотично такое предположение?
Вообще ничуть.
С помочщью цепей Маркова и прочность сплавов считают.
И даже RFM-сегментации зачем-то строят.
Но, самое главное, широко известная атрибуция маркетинговых каналов на марковских цепях.
На Хабре тоже хватает и теории, и практики. В том числе стоит отметить работу Александра magisterbes Беспалова Атрибуция с использованием цепи Маркова.
Не то, чтобы по этой атрибуции живёт каждый первый, но практики достаточно много, так что плюсы и минусы модели внимательно изучены.
Проблема в том, что в маркетинге точек касания относительно немного (допустим, десятки) и не всегда логирование по каждой оптимально. Внутри продукта больше касаний, логирование однородно, можно больше собрать статистики, больше гипотез проверять.
Но, по большому счёту, это тот же процесс, описанный в статье, просто мы смотрим за ним ниже по воронке.
Объяснением этого приближения может служить так называемое правило Штирлица "запоминается последняя фраза".
Постановка задачи
Итак, у нас есть обоснованная гипотеза о том, что если задачу упростить, мы всё равно получим хорошую точность.
Спойлер: так и вышло.
Итак, как формулируем задачу?
Цель: предсказывать динамику LTV каждого пользовательского действия
Исходные данные
Основные:
- лог действий (текущее + прошлое)
Для обогащения:
- маркетинговые каналы
- пользовательские сегменты
- данные пользовательской сессии
Маркетинговые каналы важны и потому, что они ведут аудиторию разного качества. А ещё потому, что мы потом всё равно будем считать не только ценность (сколько мы заработаем), но и стоимость (сколько мы потратили) действий. А стоимость - прямая функция именно канала. Радость в том, что её не нужно предсказывать.
Пользовательские сегменты очень важны. Если попытаться расчитать результат по всей выборке - будет печально. Какие важны сегменты? Большие (чтобы была статистическая значимость) и однородные (чтобы изучать сигнал, а не шум).
Сегменты, которые, как правило, хороши:
статус монетизации (платил\не платил, RFM)
платформа (мобильное приложение или браузерная страница)
сегменты активности в продукте (например, любимые жанры)
география (Москва - не Росссия, Болгария - не заграница)
соцдем (пол, возраст)
Сегменты, которые, как правило, не очень:
предпочитаемый канал навигации
участники того или иного аб-теста
выборки по знакам зодиака
Критерий проверки сегмента:
разброс значимых метрик внутри сегмента должен быть низким (критерий однородности)
средние значения сегментов должны отличаться друг от друга (критерий значимости)
Данные пользовательской сессии помогают решить "проблему гистерезиса", чуть-чуть сглаживают высокий вес последних событий и "усредняют" прогноз по пути пользователя.
Best practices
Буквально пару советов, которые могут вам сэкономить время.
Разделите задачу
Так как успешная покупка бывает относительно редко (явно не в 50% случаев), то лучше разделить задачу на две: предсказание сессии с покупкой и предсказание суммы следующих покупок.
Первая задача - это задача классификации. И, так как мы работаем с вероятностями, можно брать не самое значение функции функции predict(), а вероятность попасть в тот или иной класс (обычно, они лежат в переменных типа predict_proba).
Для тех же пользователей, у которых вероятность покупки велика, можно посчитать сумму последующих покупок. Это стандартная задача регрессии.
Не переобучайтесь
Не торопитесь выжимать максимум по выбранной вами метрике, это не типовая задача из Kaggle. Высокая точность модели здесь необязательна. Важно просто быстро и дёшево выхватить важные закономерности. Устойчивость этих интерпретаций в будущем гораздо важнее получения более "точной" модели здесь и сейчас.
Вы можете вообще не использовать машинное обучение
Т.к. нам нужны общие закономерности, то можно начать со старого доброго прогноза вида "завтра будет примерно так же, как и сегодня". Так что можно просто использовать исторические данные для простановки весов.
Но для этого нужно очень хорошо разрезать на сегменты, понимать процессы. Ну и понимать, что работать всё будет до первого серьёзного изменения в продукте.
Тем не менее, собрать такой MVP, показать закономерности, а потом уже пилить "настоящую" прогнозную модель - вполне себе нормальный путь.
Что дальше?
Итак, у нас есть модель, которая показывает какую-то величину, которая напрямую связана с будущим LTV напротив каждого события в пользовательских логах. Как мы будем это использовать?
Скоры у каждого перехода
Логично начать с "настоящей воронки". Точнее воронок. Построить популярные переходы и остортировать их по ожидаемой ценности. Не забудьте взвесить по числу человек, которые попали в тот или иной переход.
Будет очень здорово, если в полученном топе примерно половина связок будет вам знакома. Ну или, хотя бы, будет очень лёгкой для интепретации. Если это не так, значит, либо вы очень плохо знаете свой продукт, либо в модели где-то ошибка. Наличие известного сильно повышает доверие к неизвестной части.
Примеры связкок событий, повышающих LTV:
Событие успешной регистрации => событие просмотра профиля (+1 п.п. к конверсии, +650 ценность).
Это прокси лояльного пользователя. Он после регистрации не побежал смотреть каталог, не побежал покупать одну-единственную книгу, которая ему нужна здесь и сейчас. Он смотрит, как отображается его профиль, что там есть. Человек пришёл обустраиваться на новом месте, человек настроен остаться здесь надолго. Такие люди имеют хорошую возвращаемость и высокий LTV. Осталось только им ничегт не испортить.
События просмотра персональных рекомендаций => событие перехода на внутренний поиск (+3,5 п.п. к конверсии, +500 ценность).
А вот такая штука сложнее для интепретации. Возможно, "рекомендации навеяли" и человек что-то вспомнил, пошёл искать. Возможно, наоборот, "тут всё понятно, попробуем по-другому". Лучше посмотреть на неё внимательнее и не торопиться с выводами.
Примеры связок событий, понижающих LTV:
Событие просмотра карточки книги => закрытие окна авторизации (-3 п.п. конверсии, -50 ценность)
Это известная наша особенность. Тут мы делаем плохо одним пользователям для того, чтобы сделать плохо другим. Мы, конечно, считали, сколько это нам стоит. По новой методологии баланс потерь и приобретений получился примерно таким же. Это радует.
Просмотр страницы каталога жанров => просмотр страницы карточки автора (- 2 п.п. конверсии, -14 ценность)
Тут тоже сложно. Возможно, это "последняя попытка": пользователь не может найти нужную ему книгу, решил ткнуть на автора. Тут важно посмотреть, меняется ли ценность данного перехода в начале и в конце сессии.
Что можно вывести на дашборд?
Ну как же, у нас есть данные и чтобы не было дашборда? Ни в коем случае!
Тем более, тут есть такая крутая штука, как ожидаемый LTV пользователей. Конечно, нам это в каких-то значимых срезах обязательно захочется посмотреть.
Есть один важный параметр, который важно смотреть сразу. Мы с вами проговаривали то, что каждая команда драйвит свои метрики и ситуацию с продуктом в целом смотреть сложно.
Если у вас в пользовательских логах есть принадлежность к веткам A/B-тестов, то вывести LTV по веткам вам будет очень просто.
Это ни в коем случае не иснтурмент для подведения итогов A/B-тестов, но тулза, которая покажет вам, в какую сторону пытаются перетащить одеяло.
Дальнейшие организационные действия
Итак, у вас моделька, есть переходы, есть дашборд. Вы уже готовы показать демо своей команде. Но важно заострить внимание на том, что делать дальше.
Переходы с отрицательной ценностью
Фокусируем внимание команды на том, что это наши настоящие bottlenecks. Нам не нужны бенчмарки для того, чтобы в этом разобраться. Это место, где от нас уходят деньги.
Весь продуктовый креатив должен быть здесь. Тут нужно формулировать гипотезы, пробовать менять объекты местами, смотреть вебвизор. И тасовать A/B-тесты как колоду карт.
Переходы с максимальной ценностью
А вот тут мы вряд ли сможем что-то улучшить. Зато легко можем сломать и даже не заметить.
Поэтому вот эти точки мы обвешиваем алертами, мониторингами, дашбордами, всем, чем только можете себе позволить. Основная задача - понять, что что-то сломалось максимально быстро и чинить в первую очередь ровно в том месте, где сосредоточены основные деньги.
Что мы должны получить достаточно быстро?
Воронки, которые описывают реальность.
Много-много маленьких коротких воронок. Их потом можно собирать в блоки, но это не так важно. Важно, что мы смотрим ровно на то, что важно. И мы определили это на данных, а не исходя из опыта или здравого смысла. Хотя никто не запрещает ими усилить эффект.
Изменение зон ответственности менеджеров.
Новые воронки => новые зоны отвествтенности. Понятно, что это будет касаться лишь каких-то смежных вопросов. Но это шаг в правильную сторону.
KPI с человеческим лицом.
Раз есть праивдьные воронки, правильные команды и правильные точки приложения усилий, то появятся метрики, которые не будут связывать руки продуктовой команды а, наоборот, помогут принимать максимально смелые решения и быстро их проверять.
Промежуточные таргеты для маркетинга.
Шикарный бонус. В большиснтве маркетинговых инструментов, где есть система CPA (cost per action), кроме основного целевого действия (обычно в его качестве выбирают первую покупку) можно добавить промежуточные с какими-то весами. Не все этим пользуются, поэтому что откуда-то их брать, эти веса? А тут мы получаем веса через ценность в явном виде совершенно бесплатно. Не забудьте показать их маркетологам, они скажут вам большое спасибо. И не просто скажут, а приведут либо больше трафика, либо столько же, но дешевле, чем раньше.
Про что обязательно не забыть?
По большому счёту, всё, что написано выше, можно обобщить просто: мы пытались каждому человеку поставить в соотвествие число.
Это хорошо, это круто, это аналитично. Но есть и другая половина этого процесса. Я считаю, что она важна ещё больше. Впервые я это выражение услышал про финансового директора компании Лего в период, когда им было особенно тяжело. Но мне кажется, что лучше всего оно описывает именно аналитиков.
Хороший аналитик - это тот, кто может видеть число за каждым человеком, но не забывает при этом видеть человека за каждым числом.
Желаю вам никогда не забывать о том, что за любой продуктовой моделью всегда есть какой-то человек со своими целями и интересами. Тогда вам всегда будет проще сделать хорошо и для человека, и для продукта.
Другие мои материалы, которые могут быть вам интересны:
Голосовалка про лучший инструмент для рисования схем. В этом ма��ериалы было много всяких графов и схем. Я выбрал один из стандартных инструментов, но пробовал и другие. А после спросил мнение читателей. Результат меня удивил.
Байка про то, что иногда надо ломать то, что "нормально" работает. Наверняка, вы тоже можете поделиться похожими историями.
Статья с примерами задач на аналитику. Подсказки и решения под спойлером. К решениям, которые не совпадают с логикой автора, максимальная толерантность.
Статья про т.н. задачи "про гномиков", которые часто используют на собеседованиях. Разбираю часть, высказываю своё мнение по поводу границ применимости таких испытаний.