Wildberries - данные как основа быстрого запуска и масштабирования BNPL-продукта, Михаил Кузин
Михаил Кузин, Руководитель управления аналитики b2c-продуктов RWB. Форум Data Day 2026 «ИИ + Данные». Организатор — Издательский дом «Регламент».
Как правильно организованная работа с данными помогает быстро запускать и масштабировать новый финансовый продукт на маркетплейсе. Основная мысль состоит в том, что в таких продуктах нельзя смотреть только на быстрый рост одобрений и выдач: важно заранее выстроить аналитику так, чтобы можно было видеть не только эффект от изменений, но и их долгосрочные последствия для риска и экономики бизнеса.
Отдельный акцент сделан на том, что на старте проекта обычно нет готовой дата-инфраструктуры, а команда маленькая, при этом продукт сразу должен расти. Поэтому правильный подход — не ждать идеальной системы, а параллельно развивать продукт и основу для аналитики. Такой фундамент включает логирование, хранилища данных, управляемость операционных процессов и понятную систему управленческих метрик. Здесь важен баланс между скоростью запуска и возможностью дальнейшего масштабирования: решение должно быть достаточно простым, чтобы быстро заработать, но не настолько временным, чтобы через несколько месяцев его пришлось выбросить.
Логирование в выступлении описано как одна из ключевых отправных точек. Сначала нужно ответить не на вопрос «что можно залогировать вообще всё», а на вопрос «какие бизнес-вопросы должны быть закрыты данными». Для рассрочки это означает необходимость понимать действия клиента, решение системы, причины этого решения и поведение заявки на каждом этапе.
Большое внимание уделено хранилищам и внутренней структуре данных. На старте можно обходиться техническими выгрузками и мониторингами, но этого недостаточно для роста. Нужны MVP хранилища, который можно быстро запустить, однако в него сразу должна быть заложена расширяемость.
Сильный блок выступления связан с операционной управляемостью. Когда поток заявок растёт, растёт и количество проблем, которые нужно быстро разбирать: что сломалось, почему это произошло и что делать дальше. Для этого нужны реалтайм-мониторинг, алерты по ключевым метрикам и возможность разбирать любую проблему на данных, а не на уровне догадок.
Дашборды в докладе представлены не как просто визуализация, а как часть системы принятия решений. Автор подчёркивает, что не нужно создавать десятки отчётов, которыми никто не пользуется. Гораздо полезнее сделать один-два действительно управленческих дашборда с ключевыми метриками, по которым команда реально каждый день принимает решения.
Ещё один важный тезис — данные часто приходится не просто хранить, а добывать. Это может быть парсинг сырых логов, получение данных через API или даже создание отдельного сервиса, который собирает и поставляет данные в хранилище. Помимо внутренних источников, возможна и покупка данных, а также получение данных через управляемые эксперименты.
Во второй части выступления речь идёт о росте продукта. Перед запуском любой гипотезы необходимо провести предварительный анализ: оценить потенциал, риски и ограничения, а также сформировать ожидания по эффекту. Это важно потому, что в ранней стадии развития не всегда достаточно зрелые метрики, и даже неожиданный рост может оказаться не успехом, а источником потерь.
Эксперименты и A/B-тестирование показаны как обязательный, но не догматичный инструмент. Важно соблюдать базовую гигиену тестирования, но не перегружать дизайн академической сложностью, если это мешает скорости принятия решений. Отдельно подчёркнуто, что ещё до запуска нужно договориться, какой результат ведёт к какому управленческому действию. Иначе после эксперимента можно столкнуться с ситуацией, когда метрики изменились разнонаправленно, а команда не понимает, что делать дальше.
Для кредитных и рискованных продуктов выделена проблема длинного цикла созревания метрик риска. Бизнес не может ждать месяцами, пока проявится финальный эффект, поэтому нужны прокси-метрики — ранние показатели, которые помогают прогнозировать итоговый риск. Но такие метрики нельзя считать статичными: за их качеством нужно постоянно следить, проверять их связь с целевой метрикой и обновлять при изменении продукта.
Блок про машинное обучение и искусственный интеллект построен вокруг прагматичного подхода. ML рассматривается не как самоцель и не как показатель зрелости, а как дорогой и сложный инструмент, который имеет смысл только там, где он даёт реальный экономический эффект. На раннем этапе многие задачи можно решить классической аналитикой, моделированием и эвристиками. Запускать ML-модели без чёткой бизнес-задачи, особенно в продакшене, не стоит.
Данные действительно помогают быстрее принимать качественные решения, но в каждой системе нужен баланс. Где-то можно пожертвовать частью сложности ради скорости, если это не навредит масштабированию в будущем.
