Lead Prioritization with Time-Aware Validation

Проект в рамках тестового вступительного задания в Avito DS Bootcamp лето 2026 решает задачу приоритизации обращений: для каждого обращения модель оценивает вероятность успешного целевого действия в течение пяти дней после назначения. Полученный score используется для ранжирования обращений внутри каждого дня. Изначально был дан индивидуальный датасет с данными, quickstart с простым бэйзлайном на логреге и пример ответа с правильной последовательностью лидов (sample_submission.csv)

Ключевые особенности

• временная walk-forward валидация вместо случайного разбиения;
• защита от утечки: при построении признаков используются только события с event_ts < assignment_ts;
• feature engineering - поведенческие признаки из истории просмотров, поиска, добавлений в избранное, открытия чата и кликов по номеру;
• сравнение Logistic Regression и нескольких вариантов CatBoost;
• ограниченный подбор гиперпараметров с отдельной контрольной проверкой;
• полностью воспроизводимое создание submission.csv.

Результат

Лучшей стала модель CatBoost с готовыми табличными и событийными признаками. После ограниченного подбора параметров средний Daily Average Precision на трёх временных фолдах составил около 0.7048.

Выбранная конфигурация:

• depth=6;
• l2_leaf_reg=12;
• random_strength=1.5;
• итоговое число деревьев — 934.

Подробный EDA, feature engineering, схема валидации, сравнение моделей и обоснование решений находятся в solution.ipynb.

Структура проекта

.
├── data/
│   ├── train.csv
│   ├── test.csv
│   └── events.csv
├── quickstart.ipynb       # базовое решение для точки отсчёта
├── solution.ipynb         # полный исследовательский и ML-пайплайн
├── sample_submission.csv  # шаблон и требуемый порядок lead_id
├── submission.csv         # воспроизведённые прогнозы финальной модели
└── requirements.txt       # зафиксированные версии зависимостей

Запуск

Проект проверен на Python 3.11.

git clone https://github.com/Nkitocik/lead_prioritization_challenge.git
cd lead_prioritization_challenge
python -m venv .venv

Активация окружения в Windows:

.venv\Scripts\Activate.ps1

Установка зависимостей и запуск Jupyter:

pip install -r requirements.txt
jupyter notebook solution.ipynb

После выполнения всех ячеек solution.ipynb файл submission.csv создаётся заново. Важно: Файл sample_submission.csv должен находиться в корне проекта: он используется для проверки состава и порядка lead_id.

Технологии

Python, pandas, NumPy, scikit-learn, CatBoost, Matplotlib и Jupyter.

---

ЧАСТЬ 1. Официальный текст задания

О задаче

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

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

Скачай архив с данными и baseline-кодом. В архиве есть описание задачи, обучающая выборка, тестовая выборка, события и пример файла для отправки решения.

Данные

Тебе доступны файлы:

• data/train.csv — обучающая выборка с target;
• data/test.csv — тестовая выборка без target;
• data/events.csv — дополнительные события для feature engineering;
• sample_submission.csv — пример файла для отправки решения.

Одна строка в train.csv и test.csv соответствует одному назначенному обращению в конкретный момент времени. Это не пользователь, не объявление, не дилер и не звонок сами по себе. В строке собран контекст вокруг факта назначения обращения в обработку.

lead_id — идентификатор обращения, который нужно сохранить в файле с ответом.

Файлы train.csv и test.csv

В этих файлах уже собраны готовые табличные признаки, доступные на момент назначения обращения:

• lead_id — идентификатор обращения;
• user_id — идентификатор пользователя;
• assignment_ts, assignment_date — время и дата назначения обращения;
• Контекст назначения: источник, колл-центр, регион, канал, сегмент авто, bucket цены и стажа пользователя;
• Признаки времени назначения: час, день недели, признак выходного дня;
• Признаки пользователя, продавца и объявления: активность пользователя, возраст аккаунта, число прошлых назначений, размер инвентаря продавца, цена, возраст авто, пробег;
• Агрегаты активности за окна 1d, 3d, 7d, 14d, 30d, 90d: просмотры, избранное, раскрытия деталей, свайпы фото, просмотры продавца, поисковые действия, контакты, открытия чата и клики по звонку;
• История предыдущих назначений: сколько обращений было назначено, отвечено и привело к положительному исходу в прошлых временных окнах;
• target есть только в train.csv.

Суффикс в названии признака показывает временное окно агрегации. Например, item_views_7d — число просмотров объявления за 7 дней до назначения.

Файл events.csv

Содержит дополнительные события, из которых можно собрать свои признаки. В нем есть идентификаторы обращения и пользователя, время события, тип события и несколько дополнительных полей события.

Целевая переменная (Target)

• target = 1, если в течение 5 дней после назначения произошло успешное целевое действие.
• target = 0, если за это окно успешного действия не было.

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

Если ты строишь признаки из events.csv, используй только события с условием: $$\text{event_ts} < \text{assignment_ts}$$

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

Ограничения и условия

• Использование больших языковых моделей (>1B параметров) или внешних API запрещено.
• Запрещена ручная разметка тестовых данных.
• Запрещены хардкод ответов под конкретные lead_id и попытки вручную восстановить тестовую разметку.
• Запрещены плагиат и копирование решений других кандидатов.
• Если вы используете open-source модели, библиотеки или готовые подходы, укажите это в описании решения.
• Решение должно воспроизводиться у проверяющего.

Допускается использование:

1. Классических ML-моделей;
2. Правил и эвристик;
3. Гибридных подходов;
4. Open-source моделей и библиотек, если они разворачиваются локально и не обращаются к внешнему API.

Формат решения и используемая метрика

Файл с предсказаниями должен содержать ровно две колонки:

• lead_id — идентификатор обращения из test.csv;
• score — число от 0 до 1, чем выше, тем перспективнее обращение.

Пример формата есть в sample_submission.csv.

Основная метрика — Daily Average Precision на скрытой тестовой выборке

Для каждого дня назначения отдельно считается Average Precision, после этого значения усредняются по дням. Чем выше score у успешных обращений относительно неуспешных внутри дня, тем лучше результат.

В сообщении после отправки также может показываться обычный Average Precision по всей скрытой тестовой выборке. Он нужен как дополнительная диагностика, но итоговый score на платформе считается по Daily Average Precision.

Математическое описание метрик

Average Precision (AP): Пусть $y_i$ — целевая метка обращения, $s_i$ — score модели. Отсортируем обращения по убыванию $s_i$. Тогда:

$$AP = \frac{1}{N_+} \sum_{k=1}^N Precision@k \cdot y_{(k)}$$

$$Precision@k = \frac{\sum_{j=1}^k y_{(j)}}{k}$$

$$N_+ = \sum_{i=1}^N y_i$$

Здесь $y_{(k)}$ — target объекта на позиции $k$ после сортировки по score, $N_+$ — число успешных обращений.

Daily AP: Пусть $D$ — множество дат назначения обращений в скрытой тестовой выборке. Для каждой даты считаем Average Precision только по обращениям, назначенным в этот день:

$$AP_d = AP({ (y_i, s_i) : assignment_date_i = d })$$

Итоговая метрика — среднее значение по дням:

$$DailyAP = \frac{1}{|D|} \sum_{d \in D} AP_d$$

Quickstart & Отправка решения

• Quickstart: Открой quickstart.ipynb из архива с данными и выполни ячейки ноутбука. Ноутбук показывает минимальный пример обучения модели на готовых табличных признаках и создает файл submission.csv.
• Формат сдачи:
  • submission.csv с предсказаниями для data/test.csv;
  • код или notebook, которым получен submission.csv;
  • короткое описание подхода: какие признаки использовали, как валидировались, что пробовали.

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

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

ВАЖНО: на отправку дается максимум 7 попыток.