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

Вводные по методологии:
https://drive.google.com/drive/u/0/folders/1GlAZKs...

Правки:

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

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

Пользователь может оплатить один раз в 2017 году, а второй раз в 2020 году. В таком случае его Lifetime будет равен 3 годам. А теперь сдвинем сроки на 2 года вперед: представим, что этот же пользователь сделал первую оплату в 2019 году. Вторую он должен сделать в 2022 , но этот год еще не наступил… Поэтому его Lifetime будет равен 1 месяцу, так как у него всего одна оплата. Выбранная модель работает в нашем случае именно так. И чем больше нерегулярных оплат и пропусков, тем больше у нее погрешность.

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

Даже в самой статье, от которой отталкивался математик написано:
"Why retention? The issue with customer lifetime value is the customer lifetime. If we’re talking subscription-based service, an estimate for customer brought-in value is recurring revenue (RR), or the amount a customer pays for a subscription. If your customer has a possibility to skip a period, however, do not forget to adjust for that (estimate the average % of skips)"

Здесь написано, что необходимо сделать поправку на процент пропусков. Эта поправка не была сделана. Да и я думаю, что она в принципе не могла быть сделана, так как у нас далеко не регулярные оплаты, а отсюда выходит очень-очень большой процент пропусков.

Я могу быть не прав с процентом пропусков, и люди могут платить более менее регулярно, однако в таком случае оплаты идут не в Paid, а в другое поле (Other, Spent и так далее). Так сказать неправильно атрибутируется тип оплаты. Тем не менее, я уверен, и проверил это на нескольких клиентах: каждый месяц пользователи не платят, и скорее всего, неправильная атрибуция лишь добавляет масла в огонь, а не является единственной причиной проблемы.

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

P.S. Я бы еще убрал фильтр по отрицательным оплатам и фильтр по крупным оплатам, так как это не выбросы а особенность бизнеса, где существуют крупные клиенты. Это больше вопрос на подумать (или посчитать обеими способами), так как любой пользователь с большИми оплатами может внести большИе помехи в общий LTV по кампаниям. Однако неучет таких пользователей может привести к ошибочному занижению общего LTV.

В этом хочу лишь добавить два скрина (есть по ссылке выше), как доказательство моих слов. На них можно увидеть, что будет, если один и тот же месяц взять первым и последним для прогнозной модели. Спойлер: lifetime далеко не похожи…

Также я пробовал убрать фильтр по типу Paid. То есть я учитывал вообще все оплаты/списания. Это ничего не дало, методология все равно дает плохую точность.

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