Как стать автором
Обновить

Как мы дорабатывали легаси-ценообразование: от стадии отрицания до MVP за 4 месяца

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров1.4K
Привет, меня зовут Валерий Лобанов и я — аналитик данных в компании Spacecode.

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

Исходные данные: 
  • Заказчик — компания-застройщик. 
  • Задача — создать инструмент для наших аналитиков, который позволит индексировать и изменять цены на квартиры в зависимости от спроса и ситуации на рынке. 

Что мы исследовали?


Изначально в качестве наработок нам досталась математическая модель, в которой  обрабатывалась исходная информация. Качество модели, которую передали нам, составляло чуть меньше 50%. Выглядело так, будто за основу взяли некую универсальную модель, и не слишком внимательно адаптировали под задачу заказчика.
Выборка по такому числу критериев получилась насыщенной и до крайности «дырявой». Ошибки в ETL процессах, хранении данных и игнорирование бизнес логики добавляли интриги не меньше, чем выбранный подход к прогнозированию цен. 
Наша группа аналитики “ворвалась на танцпол”. И первая же мысль, озвученная лидом проекта: “нужно начинать с анализа данных и уменьшения количества параметров, а уже после чинить модель”.

С этого момента начались основные работы по проекту. Хотя у команды и был опыт в задачах ценообразования, полного понимания специфики процессов в сфере недвижимости не хватало.
Сначала мы выполнили все работы в знакомом нам домене: привели существующие данные в порядок, исправили некорректные связи данных. Это уже улучшило качество модели с 50% до 70%.

Бюджет не позволял начать разработку системы со сложной бизнес-логикой “с нуля”, при этом нынешняя реализация требовала основательного совершенствования. 

В итоге вырисовывались две сюжетных линии развития ситуации:
  1. Идти по существующему пути и продолжить доработку и корректировку прошлой модели, стараясь применить максимум существующих наработок.
  2. Упростить решение, собрать интуитивно понятный дашборд, который будет агрегировать нужную аналитику.

Эти варианты предложили заказчику, который выбрал первый путь, чтобы как можно больше задействовать наработки предыдущей команды. 
Мы изменили многое — но, по желанию заказчика, оставили ранее проработанную бизнес-логику. Особенно больно от этого было команде backend-разработки, на плечи которой лег непростой труд по сборке обучающей выборки и битве с 1С за данные.

Погружаемся в предметную область


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

Не удержусь и поделюсь несколькими инсайтами из бизнес-правил застройщиков: 
  • Некоторые квартиры не принадлежат застройщику напрямую. Часть квартир в собственности у инвесторов, и их продажей компания-застройщик не занимается. Для таких квартир существует отдельная логика формирования цен. 
  • Оказывается, застройщику не выгодно идти по пути “продать все квартиры как можно скорее”. План продаж выстраивается относительно бизнес-правил, принятых у конкретного девелопера. Выручка ожидается равномерной, в течение запланированного периода времени. Звучит просто, но на деле эффективно составить такой план на 4 года вперед с NP-трудная задача.
  • У каждого застройщика — уникальный набор скидок, акций и всего, что с этим связано. Временами запутанный. Еще и часто изменяемый, без уведомлений… Разобраться в этом — отдельный квест. ) 

Но главное, что стал понятен реальный запрос на задачу со стороны бизнеса: компании-девелоперу важно, какие квартиры продаются быстрее, какие — наоборот, не вызывают интереса у покупателей. Словом, отслеживать жизненный цикл квартиры.

Берем не количеством, а качеством данных


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

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

В дополнение к модели, вывели «шахматку» квартир (расположение внутри ЖК, с разделением по домам и этажам). Получился специальный и нативный интерфейс, понятный конечному пользователю: выбирая квартиру (из выставленных на продажу), оперативно видишь, насколько вероятно через месяц конкретную квартиру продать.

Еще одно применение этого инструмента — обоснование предсказаний модели. Выбрав для анализа один или несколько объектов недвижимости, можно выявить факторы, значимые для формирования индексации. 

А как же спрос и конкуренты?


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

С анализом конкурентов задача непростая и отчасти творческая.
Стоимость квартир секретом не является: ее указывают начиная от сайтов других девелоперов, и до агрегаторов типа Циана или Авито.
Загвоздка в том, что цена, по которой объект выставлен на площадке, часто отличается от цены при продаже. Причины в основном — системы скидок и акций у застройщиков. Как раз про их запутанность упоминал выше.

Со спросом все тоже оказалось не так очевидно: спрос прогнозируется по разным сочетаниям факторов, в зависимости от ЖК.
Для одних ЖК это будут звонки, для других — визиты. Или другой индикатор, уникальный для конкретного объекта.
Наверное, справедливо будет сказать, что в таких нюансах и отличается кастомная разработка систем ценообразования с индивидуально разработанной аналитикой в сравнении с покупкой готового “коробочного” решения от интеграторов. Особенностей настолько много, даже внутри одной сферы, что для рынка в совокупности учесть каждый не получится.
Да и девелопмент — не та сфера, где можно навязать правила игры компаниям со стороны интегратора. )
А “коробка” — это, как правило, fancy BI с графиками темпов спроса.

Итоги и выводы


Наша выверенная и доработанная модель, в части точности предсказаний по оффлайн метрикам, выросла с 50% до 95%.
Во время тестирования системы в течение месяца, получили приятные онлайн  метрики: расхождение между прогнозом нашей доработанной модели и отчетами отдела продаж   было в пределах 10%!
К слову, расхождение между изначальной моделью, которую нам передали, и фактическими показателями, было около 30%.

В результате, модель после доработок нашей команды преобразилась в поддерживаемую и “живую”. Словом, УРА, на одно легаси в мире стало меньше. ?

Если говорить, что приобрел лично я за время работы в проекте, то это расширение Soft skills в общении с бизнес-заказчиком. 

Сам опыт оказался крутым: погрузиться в новую предметную область, действовать, опираясь не только на информацию заказчика, но и учитывать внешние факторы.
Ну и в который раз убедился в истинности одной из заповедей математического моделирования: “Прежде чем решать задачу, подумай, что делать с ее решением”.

Теги:
Хабы:
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Публикации

Работа

Data Scientist
56 вакансий

Ближайшие события