Можно ли посчитать LTV прямо в интерфейсе Mindbox без выгрузки?

Базовую среднюю выручку на клиента — да, через отчеты и сегменты. Но полноценный когортный или прогнозный LTV в интерфейсе не построить: для матрицы когорт и моделей нужна выгрузка транзакционных данных во внешний инструмент — BI, таблицу или Python. Mindbox здесь источник чистых данных, а не калькулятор LTV.

Какой горизонт расчета LTV выбрать?

Отталкивайтесь от цикла повторных покупок в вашей категории. Если клиенты возвращаются раз в месяц — горизонта в 12 месяцев достаточно и он покажет почти весь потенциал. Если цикл длинный, как в крупной бытовой технике, считайте на 24–36 месяцев, иначе сильно недооцените ценность клиента и примете неверные решения по бюджету.

LTV считать по выручке или по прибыли?

Зависит от задачи. Для сравнения каналов привлечения и общей картины достаточно выручки. Но если хотите принимать решения по марже и реальной окупаемости, берите маржинальный LTV — умножайте выручку на валовую маржу категории. Маржу Mindbox не хранит, ее нужно подмешать из учетной системы, и это стоит сделать один раз, чтобы цифры были честными.

Как считать LTV в Mindbox: от данных платформы до…

Открываешь дашборд Mindbox, а там сотни метрик: отклики на рассылки, конверсии в заказ, RFM-сегменты, выручка по механикам. Красиво. Только вот на вопрос «сколько нам в среднем приносит клиент за все время жизни» ни один отчет прямого ответа не дает. И когда финдиректор спрашивает, можно ли поднять бюджет на удержание, маркетолог разводит руками — цифры вроде есть, а опереться не на что.

LTV — та самая метрика, которая связывает CRM-маркетинг с деньгами компании. Без нее любой разговор про ретеншн превращается в «давайте слать больше писем, вдруг поможет». С ней — в нормальную управленческую логику: вот сегмент, вот его ценность, вот сколько разумно в него вложить. Как вытащить LTV из данных Mindbox и не запутаться в методологии, объясняет Егор Череватенко, CRM-маркетолог ClientCore.

Почему в Mindbox нет кнопки «показать LTV»

Платформа хранит всю транзакционную историю: кто, когда, что и на какую сумму купил. Этого достаточно для расчета. Но готовой метрики «LTV» в интерфейсе нет — и это нормально. LTV нельзя посчитать «вообще», его всегда считают под конкретную задачу и в конкретной методологии.

Простейший вариант — исторический LTV. Берешь всех клиентов, суммируешь их выручку за все время, делишь на количество. Получаешь среднюю ценность клиента. В Mindbox эти данные есть в выгрузке по клиентской базе: суммарная выручка на профиль, число заказов, дата первого и последнего заказа. Уже на этом уровне многие компании впервые видят реальную картину — и она обычно неприятно отличается от ощущений.

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

Что нужно из данных платформы

Прежде чем строить формулы, договоритесь, что считаете LTV выручкой, а не прибылью. Это разные метрики, и путать их — частая беда. Если хотите управлять маржой, берите маржинальный LTV: умножайте выручку на среднюю валовую маржу по категории. Mindbox валовую маржу сам не знает, ее придется подмешивать из учетной системы.

Минимальный набор данных из платформы для расчета:

Норма

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

Red flag

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

Качество склейки профилей — фундамент. Если в базе бардак с идентификацией, любой расчет LTV будет врать в меньшую сторону, причем непредсказуемо. Сначала чистка дублей и сшивка офлайна с онлайном, потом формулы.

Считаем LTV по когортам

Когортный подход — рабочая лошадка для CRM-маркетинга. Логика простая: группируете клиентов по месяцу первого заказа и смотрите, как накапливается их выручка со временем. Когорта «январь 2024» через 12 месяцев принесла столько-то на одного клиента — это и есть их LTV на горизонте года.

Из Mindbox выгружаете клиентов с датой первого заказа и всей последующей историей покупок. Дальше — в таблицу или BI. Строите матрицу: по строкам когорты (месяцы старта), по столбцам — номер месяца жизни (0, 1, 2, 3...). В каждой ячейке кумулятивная выручка на клиента. Получаете кривую накопления LTV, и сразу видно, на каком месяце клиенты «выдыхаются».

Эта кривая ценнее одной цифры. Она показывает не только сколько клиент приносит, но и когда. Если 80% LTV набирается в первые два месяца, а дальше плато — у вас проблема с повторными продажами, и весь потенциал ретеншна не используется. Если кривая растет плавно и долго — клиенты лояльны, и здесь есть смысл вкладываться в программу удержания.

Прогнозный LTV: когда исторического мало

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

Тут начинается прогнозирование. Самый доступный способ — экстраполировать когортную кривую. Если когорты возрастом 12 месяцев у вас есть, а свежей всего три месяца, накладываете форму старой кривой на новую и достраиваете прогноз. Грубо, но для приоритизации сегментов часто достаточно.

Более точные модели — вероятностные, вроде BG/NBD с гамма-гамма для среднего чека. Они оценивают, сколько покупок клиент еще совершит и на какую сумму, исходя из его поведения. Mindbox сырые данные для этого отдаст, а сам расчет делается во внешнем инструменте — Python, R или BI с нужными библиотеками. Для mid-market это уже не оверкилл, а нормальная практика, если повторные продажи — основа выручки.

От цифры к решению: приоритизация сегментов

Посчитать LTV — половина дела. Дальше он должен влиять на то, куда идут деньги и силы команды. Самое прямое применение — сравнить LTV с CAC по каналам и сегментам. Канал, где LTV/CAC меньше 3, обычно требует пересмотра. Где больше — туда стоит докладывать бюджет.

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

Норма

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

Red flag

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

Частые ошибки в расчете

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

Смешивают B2C и B2B, розницу и опт в одной базе. У этих групп принципиально разная экономика, и общий LTV по ним бессмысленен. Считайте раздельно.

Берут слишком короткий горизонт. Если у вас длинный цикл повторных покупок — скажем, в товарах для дома люди возвращаются раз в полгода-год — то LTV на горизонте трех месяцев недооценен в разы. Горизонт расчета должен соответствовать реальному циклу покупок вашей категории.

И главное — считают LTV в вакууме, без привязки к стоимости привлечения и удержания. Сама по себе цифра ничего не значит. Значение появляется, когда рядом лежит, сколько стоило этого клиента привести и удержать.

Как считать LTV в Mindbox: от данных платформы до управленческого решения