Я бы ещё посмотрел интервал между подписками, первая или нет, подписка, а потом сразу отмена и т.п. чисто имхо со стороны

Я хочу сделать классификатор: купил/не купил. Фичи у меня в подневной витрине. К сожалению, в 1 день покупок очень мало для классификатора => нужны покупки за весь период. Вот отсюда и встаёт вопрос, как при этом правильно брать для каждого купившего абонента фичи из подневной витрины.

Если бы все покупки были совершены в 1 день, то и фичи бы я взял за тот же день.

Так-то это дельная тема, но у меня сейчас первоочередная задача — проверить работоспособность витрины с фичами.

да, фичи можно сгенерировать за период, но за какой лучше, чтобы они достаточно полно описывали карину, но при этом не считали слишком старые данные – доп. вопрос

Они генерятся на каждый (Божий) день. В том числе имеют инфу за период (типа, "Сколько денег занёс за предыдущие 30 дней"). Вопрос не в том, какие фичи сгенерировать, а как их взять из таблицы, в которой они генерируются каждый день.

Тупой вариант: взять по всем абонам фичи по состоянию на 1 конкретную дату. Я пытаюсь вспомнить/понять, корректно ли для каждого абонента брать фичи по состоянию на дату, когда он совершил покупку услуги.

Коллеги, подскажите, пожалуйста, какие-нибудь стоящие пакеты для named entity recognition в R?

Видел, что этот вопрос задавался полтора года назад, но тогда ничего конкретного вроде не посоветовали, мб что-то поменялось

Привет, ребята. Сорри за оффтоп, но может кто-то разбирается в линале. Я не очень понимаю условие стационарности для VAR. Что означает, finite and time invariant FIRST and SECOND ORDER MOMENTS?

Это не линал это случайные процессы

https://ru.m.wikipedia.org/wiki/Моменты_случайной_величины

Не уверен наверняка что ты имеешь в виду под var
Но стационарность в узком смысле означает конечность и независимость от времени моментов первого и второго порядка

Стационарность случайного процесса

Для стационарности в широком смысле необходимо ещё чтобы acf зависила не от момента времени а от разности моментов

Что то такое

вроде как в разнообразных клиентских аналитиках и предсказании оттока используют параметр «дней после последней покупки», то есть можно и срез на дату, и посчитать фичи за одинаковый период по всем. бездействие в системе тоже о чем-то может говорить. если пользователь покупал недавно - ок, но если давно - сохранились ли его интересы с последнего раза? мб и да) что если вам попробовать посчитать фичи и так и так, а потом посмотреть какие из них более важные? или может ещё загуглите что в этом случае делают в задачах ранжирования для рекомендаций

Спасибо за комменты. Я поспрашивал бывших коллег из бигдатки: да действительно, можно спокойно брать фичи для каждого абонента на дату покупки.

На всякий случай, ещё раз поясню контекст вопроса. В МТС Big Data главной "рабочей лошадкой" у нас, саентистов, была таблица Customer 360 (c360). В ней тупо на каждый день генерилось ~ 420 фичей на каждого абонента (на момент моего ухода). Собственно я тут у себя замутил аналогичную таблицу с360 и хочу на каком-нибудь более-менее полезном кейсе проверить её работоспособность. Поэтому моя задача заключается не в том, чтобы нагенерить полезных фичей для решение конкретной задачи (построить классификатор и посмотреть, какие фичи различают купивших подписку от не купивших), а в том, чтобы понять, как правильно (с точки зрения дат) взять уже имеющиеся фичи из свежесозданной с360 для проверки её полезности.

Кстати, фича: "Кол-во дней с последней покупке" выглядит перспективно, занесу в бэклог. Ещё раз спасибо.

спасибо, Федор. Вот характеристики случайного процесс и не понял. Почему именно первого и второго моментов?

Не знаю, что тут наехали на последние итерации тайдиверс. across(), tidyselect - это прекрасно и просто

здесь не любят тайдиверс только за одно: непостоянство. Ну еще может быть за то что, у неоправданно большой список зависимостей.