Нужно ли DS понимать бизнес-логику продукта
Насколько важно дата-сайентисту понимать бизнес-логику того, как пользователи попали в приложение? Достаточно ли просто событий из базы?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Да, нужно. Без бизнес-логики легко неверно интерпретировать события, пропустить важные признаки, получить leakage или оптимизировать не ту метрику.
Подробный разбор
События в базе — это только наблюдения. Чтобы строить хорошую модель, DS должен понимать, откуда пришел пользователь, что ему обещали, какой был канал, какое промо, какие ограничения продукта и какая бизнес-метрика оптимизируется.
Бизнес-логика помогает правильно собрать признаки, выбрать target, понять bias выборки, найти leakage и объяснить результат стейкхолдерам. Например, одинаковые действия пользователей из разных каналов могут иметь разный intent и разную конверсию.
При этом не нужно знать все детали бизнеса как product owner. Нужно понимать те части, которые влияют на данные, target, интерпретацию и production decision.
Типичные ошибки
- Сказать, что достаточно сырых events.
- Не связать бизнес-логику с target leakage и метриками.
- Не привести пример влияния acquisition/channel на поведение.
Как сказать на собеседовании
- Отвечай через "данные не существуют вне бизнес-процесса".
- Назови 2-3 конкретных примера: канал, промо, регион, device, funnel.
Какие внешние сигналы брать для более качественного прогноза
Если не смотреть только на продуктовые события внутри приложения, какие сигналы стоит получить у стейкхолдеров, чтобы улучшить прогноз или рекомендационную систему?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Нужно искать контекст до и вне продукта: канал привлечения, кампанию, регион, устройство, сезонность, календарь, цены, промо, наличие товара, ограничения supply и бизнес-сегменты пользователей.
Подробный разбор
Ответ лучше строить от цели прогноза. Если нужно прогнозировать конверсию, заказ, retention или релевантность рекомендации, продуктовых событий часто мало: они описывают поведение уже внутри продукта, но не объясняют источник и контекст пользователя.
Полезные группы сигналов: маркетинговый канал и кампания, landing page, поисковый запрос, регион и геозона, устройство, время, день недели, праздники, погода, сезонность, цены, промо, наличие товара или ресторана, SLA доставки, сегмент пользователя, история коммуникаций, внешние события и ограничения supply.
Отдельно стоит проговорить data quality: доступность этих сигналов online, задержки, пропуски, стабильность схемы, права доступа и риск leakage. Не все внешние признаки можно использовать в момент предсказания.
Типичные ошибки
- Перечислить только клики, просмотры и покупки.
- Не проверить, доступны ли признаки в момент инференса.
- Не отделить полезный контекст от leakage из будущего.
Как сказать на собеседовании
- Группируй признаки: acquisition, user context, item/context, supply, calendar, business actions.
- После списка признаков сразу скажи про leakage и online availability.
Как учитывать сезонность в рекомендациях и прогнозах
Ты упомянул сезонность. Как с ней работать в фичах для рекомендационных систем, прогнозов или продуктовой аналитики?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Сезонность кодируют через календарные признаки, rolling statistics, события/праздники, time-aware embeddings и отдельную temporal validation схему. Главное — не считать агрегаты с заглядыванием в будущее.
Подробный разбор
Можно начать с простых календарных признаков: час, день недели, месяц, праздник, рабочий/выходной, сезон, локальные события. Для ресторанов и e-commerce полезны промо, payday, погода, school holidays, спортивные события и локальные ограничения.
Дальше идут агрегаты: спрос по ресторану/категории/товару за прошлые окна, тренды, rolling mean, rolling conversion, freshness товара. Такие признаки нужно считать только из прошлого относительно момента предсказания.
Валидация должна быть temporal: train на прошлом, validation на будущем, иногда с gap между train и validation, если признаки используют скользящие окна. Иначе модель увидит будущие периоды через агрегаты.
Типичные ошибки
- Считать rolling features по всему датасету до split.
- Использовать random split для временного процесса.
- Не отделять глобальную сезонность от локальной сезонности ресторана/категории.
Как сказать на собеседовании
- Обязательно произнеси temporal split и leakage.
- Приводи примеры из домена: ресторан, категория, гео, промо, доставка.