Обсуждение построения логики прогнозирования оттока для ежемесячных продлений - PullRequest
0 голосов
/ 07 февраля 2019

У меня есть набор бизнес-данных на основе подписки, который выглядит следующим образом:

Company    RenewalMonth    Year   Month  Metrics
 ABC          10           2018    1     ...
 DEF           1           2018    1     ...
 GHI           7           2018    1     ...
 ABC          10           2018    2     ...
 DEF           1           2018    2     ...
 GHI           7           2018    2     ...
 ABC          10           2018    3     ...
 DEF           1           2018    3     ...
 GHI           7           2018    3     ...
 ABC          10           2018    4     ...
 DEF           1           2018    4     ...
 GHI           7           2018    4     ...
 ABC          10           2018    5     ...
 DEF           1           2018    5     ...
 GHI           7           2018    5     ...

и т. Д., Существует около 10 тыс. Учетных записей, и я использую их данные в месяц в течение последних 5 лет.

Здесь RenewalMonth представляет месяц, в котором каждый год происходит продление для этой учетной записи. Год и месяц представляет агрегированные параметры использования в этом году и месяце, метрики использования состоит из таких параметров, как сеансы, контент, регион, продукты и т. Д.

Япостроение модели Churn, но поскольку месяц продления для каждой учетной записи не одинаков, это создает уникальную проблему.Если я агрегирую показатели в 2017 году и использую их в качестве данных поезда для прогнозирования на 2018 год, то предполагается, что обновление каждого аккаунта произойдет 1 января 2018 года, поскольку я прогнозирую принятие к учету данных за последние 12 месяцев..

Но поскольку продление происходит в разные месяцы, другой способ состоит в том, чтобы найти скользящее 12-месячное использование каждой учетной записи, а затем сопоставить его для прогнозирования.Например, существует учетная запись «xyz», обновление которой происходит в ноябре, я сопоставлю ее данные за последние 12 месяцев использования, использую ее в качестве тестовых данных, и мои данные о поездах будут содержать данные за 12 месяцев для всех этих пользователей.учетные записи, для которых продление уже произошло, это означает, что любая учетная запись, продление которой приходится на ноябрь.Но это очень большая задача, поскольку существует около 10000 учетных записей, и найти индивидуальные скользящие средства для этих учетных записей очень сложно.

Может ли кто-нибудь помочь мне отобразить эту логику для создания модели прогнозирования оттока на 12 месяцев?

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