Все верно. Толи за регистрируется, толи нет. 50/50

Тут наверняка есть более опытные машинисты, но кажется auc = 50% это в принципе минимум. Значит модель раскидывает предикты поровну между истинно истинными и ложно истинными. Другими словами, модели вообще не удалось выявить какие-либо каузальности

Я знаю, как интерпретируется AUC. Мой вопрос в интерпретации такого результата в подобном контексте. Например, можно ли на основе этого результата утверждать, что UI/UX никак не влияют на решение пользователя о регистрации?

при сохранении в .csv из SQL Studio не записываются названия колонок

Я DBeaver использую и раньше такого поведения не замечал. Может потому, что раньше никогда не использовал возможность компрессии в *.zip

ну зависит от того что в модели. AUC в 50% может вознинкуть в следующих случаях

1. В напиленных фичах нет полезного сигнала
2. Напиленные фичи имеют разнонаправленные эффекты которые компенсируют друг друга
3. Есть не UX driven факторы (например демография пользователей ) которые так же взаимно друг друга компенсируют.

С этим надо разбираться. Вывод о невлиянии UI/UX преждевременный.

Спасибо. Поясню интерес к вопросу. Для того, чтобы "напилить фичей" под эту задачу, мне придётся отвлечь разработчиков от решения других задач, польза от которых более очевидна. Вот я и хочу с помощью данного "мысленного эксперимента" понять, что случится в крайнем случае, т.е. если модель не найдёт значимых различий.

Потратить ресурсы для того, чтобы отчитаться фразой: "Мы не смогли отличить пользователей, которые зарегистрируются и выделить факторы, которые на это влияют" — такой себе результат.

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

Я думаю это в любом случае надо делать

Почему же странный? Есть поток пользователей на сайт/приложение. Кто-то из них регистрируется, кто-то нет. У нас есть данные о том, как они взаимодействовали с сайтом/приложением. Мне кажется логичным попытка понять по этим данным, чем отличаются те, кто зарегистрировался, от тех, кто нет.

Я бы искал ошибку в своих расчетах. Чтобы логи прям совсем не влияли на факт регистрации... Ну это их для невлияния надо как-то особенным образом готовить. Или что у вас с балансировкой классов?

За задачу ещё не брался. Решил сначала представить, что делать в случае "провала": AUC ~ 0.5

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

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

Ну так а при чем тут UX /UI ? есть те кто в этом UX /UI зарегестрировался, есть то кто не зарегистрировался. Одинаковый UX с разными резлультатами.

Грузить лог действий пользователя в лог регрессию (или аналогичную модель) - это не очень корректно.
Отвалившиеся проходят не полный путь. Возниакет куча корреляций вида "Если был на последнем шаге перед таргетом вероятность что зарегитрируется - высокая"

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

Очень мало шансов для такого. Скорее всего у вас будет неплохой auc, но банальная модель. Из разряда "100 процентов зарегистрировпвшихся зашли на страницу регистрации"

Кстати, да. Над отмазкой для подобного исхода тоже надо подумать.

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

Имхо, думать заранее особого смысла нет. Лучше пробовать что-то самое простое, что вы можете сделать

Либо думать на тему, какой вообще в этой модели смысл, даже если она будет содержательной. Какие бизнес-результаты вы хотите получить из предсказания?