Классификатор может оценивать вероятность того, что клик относится к выбранному классу (сконвертившийся или нет), а не только булев факт. Линейная регрессия тут вообще не при чем, т.к. это задача классификации, а не регрессии.
Допустим, есть клик, который на самом деле сконвертился.
Первый классификатор оценил вероятность clf1.predict_proba(click) = (0.51, 0.49) — т.е. 49%.
Второй классификатор оценил вероятность clf1.predict_proba(click) = (0.95, 0.05) — т.е. 5%.
Если threshold для классификатора будет на уровне 0.5 (т.е. если вероятность выше 0.5, расценивать как успешный клик), оба классификатора ошибутся, но второй ошибется значительно сильнее.
Рандом в среднем на 30-50% хуже a/b теста.
Оптимизация под мобильный трафик была одинаковой (у одного клиента все хорошо на всех лендингах, у другого — все равномерно плохо).
Я смотрел на связь matthews_corrcoef (он по сути похож на f1) и конверсию и тоже ничего не нашел.
Бустинг пробовал, в двух из шести экспериментов сейчас именно он и применяется. Ансамблевые методы вообще работают в среднем лучше :)
Для каждого эксперимента — свой корпус, от 10 до 150 тыс. При этом learning curve достаточная плавная, уже на 10-20 тысячах точность обычно была близка к максимуму.
Для работы с табличными данными также рекомендую обратить внимание на pandas. На мой взгляд, зачастую удобно прочитать данные из таблицы при помощи pandas, провести необходимые манипуляции с полученным DataFrame и потом опять экспортировать в xls.
Сертификат безопасности сайта не является доверенным!
Вы попытались перейти на сайт manage.appnestic.com, но сервер предоставил сертификат, выданный организацией, которую операционная система компьютера не считает надежной. Это может означать, что сервер создал свой собственный сертификат, которому Google Chrome не может доверять, или что вмешался злоумышленник.
Есть пара нюансов:
— нужно именно предлагать, а не делать по-своему без обсуждений (бывали грустные прецеденты);
— если идеи, предлагаемые разработчиком, постоянно отвергаются (к сожалению, не всегда разработчик хорошо понимает предметную область), это явно демотивируют.
Тем не менее, я всецело за — преимущества чаще перевешивают недостатки.
Например, внутренняя (недоступная для сторонних заказчиков) баннерокрутилка.
Product manager заинтересован в том, чтобы повышать среднюю прибыль с тысячи показов (например, улучшая таргетинг); стейкхолдеров (бизнес-руководство) не особенно интересует, как именно это будет сделано; конечные посетители сайта вообще никак не заинтересованы в продукте.
В основном занимаюсь сервисами, с которыми практически не сталкивается пользователь, что накладывает своеобразный отпечаток
Необязательно у сервиса бывает пользователь, который может что-то подсказать. Например, это может быть какой-то сугубо технический сервис или сервис, которым пользователи вообще предпочли бы не пользоваться, но по какой-то причине вынуждены.
Далеко не всегда пользователь прав в своем мнении.
Продакт менеджером сложно стать с нуля, нужен опыт в других сферах (аналитика, маркетинг, etc.) и понимание не только технологий, но и бизнеса.
У прожект менеджера порог вхождения слегка ниже, имхо.
Допустим, есть клик, который на самом деле сконвертился.
Первый классификатор оценил вероятность clf1.predict_proba(click) = (0.51, 0.49) — т.е. 49%.
Второй классификатор оценил вероятность clf1.predict_proba(click) = (0.95, 0.05) — т.е. 5%.
Если threshold для классификатора будет на уровне 0.5 (т.е. если вероятность выше 0.5, расценивать как успешный клик), оба классификатора ошибутся, но второй ошибется значительно сильнее.
Оптимизация под мобильный трафик была одинаковой (у одного клиента все хорошо на всех лендингах, у другого — все равномерно плохо).
Бустинг пробовал, в двух из шести экспериментов сейчас именно он и применяется. Ансамблевые методы вообще работают в среднем лучше :)
— нужно именно предлагать, а не делать по-своему без обсуждений (бывали грустные прецеденты);
— если идеи, предлагаемые разработчиком, постоянно отвергаются (к сожалению, не всегда разработчик хорошо понимает предметную область), это явно демотивируют.
Тем не менее, я всецело за — преимущества чаще перевешивают недостатки.
Product manager заинтересован в том, чтобы повышать среднюю прибыль с тысячи показов (например, улучшая таргетинг); стейкхолдеров (бизнес-руководство) не особенно интересует, как именно это будет сделано; конечные посетители сайта вообще никак не заинтересованы в продукте.
Необязательно у сервиса бывает пользователь, который может что-то подсказать. Например, это может быть какой-то сугубо технический сервис или сервис, которым пользователи вообще предпочли бы не пользоваться, но по какой-то причине вынуждены.
Далеко не всегда пользователь прав в своем мнении.
У прожект менеджера порог вхождения слегка ниже, имхо.
P.S. Сам сторонник единой метки-идентификатора, но для подавляющего большинства сторонних аналитических решений этого недостаточно.