Привет, меня зовут Валерий Лобанов и я — аналитик данных в компании Spacecode.
Первый проект на новом месте работы всегда запоминается ярче последующих.
Для меня в Spacecode первой глобальной задачей стала работа с моделями динамического ценообразования. Сейчас, когда работа нашей команды над MVP продукта завершена, хочу рассказать о проекте и подвести свои личные итоги.
Исходные данные:
Изначально в качестве наработок нам досталась математическая модель, в которой обрабатывалась исходная информация. Качество модели, которую передали нам, составляло чуть меньше 50%. Выглядело так, будто за основу взяли некую универсальную модель, и не слишком внимательно адаптировали под задачу заказчика.
Выборка по такому числу критериев получилась насыщенной и до крайности «дырявой». Ошибки в ETL процессах, хранении данных и игнорирование бизнес логики добавляли интриги не меньше, чем выбранный подход к прогнозированию цен.
Наша группа аналитики “ворвалась на танцпол”. И первая же мысль, озвученная лидом проекта: “нужно начинать с анализа данных и уменьшения количества параметров, а уже после чинить модель”.
С этого момента начались основные работы по проекту. Хотя у команды и был опыт в задачах ценообразования, полного понимания специфики процессов в сфере недвижимости не хватало.
Сначала мы выполнили все работы в знакомом нам домене: привели существующие данные в порядок, исправили некорректные связи данных. Это уже улучшило качество модели с 50% до 70%.
Бюджет не позволял начать разработку системы со сложной бизнес-логикой “с нуля”, при этом нынешняя реализация требовала основательного совершенствования.
В итоге вырисовывались две сюжетных линии развития ситуации:
Эти варианты предложили заказчику, который выбрал первый путь, чтобы как можно больше задействовать наработки предыдущей команды.
Мы изменили многое — но, по желанию заказчика, оставили ранее проработанную бизнес-логику. Особенно больно от этого было команде backend-разработки, на плечи которой лег непростой труд по сборке обучающей выборки и битве с 1С за данные.
Чтобы осознанно менять алгоритмическую модель, важно погружение в контекст. Наша команда за время работы над проектом узнала много интересных подробностей ценообразования на рынке недвижимости.
Не удержусь и поделюсь несколькими инсайтами из бизнес-правил застройщиков:
Но главное, что стал понятен реальный запрос на задачу со стороны бизнеса: компании-девелоперу важно, какие квартиры продаются быстрее, какие — наоборот, не вызывают интереса у покупателей. Словом, отслеживать жизненный цикл квартиры.
Работа с данными принесла ожидаемый эффект: многие параметры, заявленные отделом продаж как критически важные, концептуальные для бизнес-процессов, связанных с жизненным циклом квартир… но никак не влияют на цену.
В результате исследований, создали модель, которая не только прогнозирует вероятность продать квартиры в следующем месяце и индексирует предложения по конкретным объектам.
Если вероятно, что конкретно эта квартира будет скоро продана, процент индексации будет выше. На те квартиры, которые согласно предсказанию модели, будут продаваться дольше, — соответственно, индексация будет минимальной.
В дополнение к модели, вывели «шахматку» квартир (расположение внутри ЖК, с разделением по домам и этажам). Получился специальный и нативный интерфейс, понятный конечному пользователю: выбирая квартиру (из выставленных на продажу), оперативно видишь, насколько вероятно через месяц конкретную квартиру продать.
Еще одно применение этого инструмента — обоснование предсказаний модели. Выбрав для анализа один или несколько объектов недвижимости, можно выявить факторы, значимые для формирования индексации.
А сами продолжили исследовать, как повысить качество модели и расширить набор учитываемых параметров. Довольно быстро выяснили, что очевидной недоработкой стало отсутствие конкурентного анализа. Практика показала, что это — значимый фактор при индексации спроса.
С анализом конкурентов задача непростая и отчасти творческая.
Стоимость квартир секретом не является: ее указывают начиная от сайтов других девелоперов, и до агрегаторов типа Циана или Авито.
Загвоздка в том, что цена, по которой объект выставлен на площадке, часто отличается от цены при продаже. Причины в основном — системы скидок и акций у застройщиков. Как раз про их запутанность упоминал выше.
Со спросом все тоже оказалось не так очевидно: спрос прогнозируется по разным сочетаниям факторов, в зависимости от ЖК.
Для одних ЖК это будут звонки, для других — визиты. Или другой индикатор, уникальный для конкретного объекта.
Наверное, справедливо будет сказать, что в таких нюансах и отличается кастомная разработка систем ценообразования с индивидуально разработанной аналитикой в сравнении с покупкой готового “коробочного” решения от интеграторов. Особенностей настолько много, даже внутри одной сферы, что для рынка в совокупности учесть каждый не получится.
Да и девелопмент — не та сфера, где можно навязать правила игры компаниям со стороны интегратора. )
А “коробка” — это, как правило, fancy BI с графиками темпов спроса.
Наша выверенная и доработанная модель, в части точности предсказаний по оффлайн метрикам, выросла с 50% до 95%.
Во время тестирования системы в течение месяца, получили приятные онлайн метрики: расхождение между прогнозом нашей доработанной модели и отчетами отдела продаж было в пределах 10%!
К слову, расхождение между изначальной моделью, которую нам передали, и фактическими показателями, было около 30%.
В результате, модель после доработок нашей команды преобразилась в поддерживаемую и “живую”. Словом, УРА, на одно легаси в мире стало меньше. ?
Если говорить, что приобрел лично я за время работы в проекте, то это расширение Soft skills в общении с бизнес-заказчиком.
Сам опыт оказался крутым: погрузиться в новую предметную область, действовать, опираясь не только на информацию заказчика, но и учитывать внешние факторы.
Ну и в который раз убедился в истинности одной из заповедей математического моделирования: “Прежде чем решать задачу, подумай, что делать с ее решением”.
Первый проект на новом месте работы всегда запоминается ярче последующих.
Для меня в Spacecode первой глобальной задачей стала работа с моделями динамического ценообразования. Сейчас, когда работа нашей команды над MVP продукта завершена, хочу рассказать о проекте и подвести свои личные итоги.
Исходные данные:
- Заказчик — компания-застройщик.
- Задача — создать инструмент для наших аналитиков, который позволит индексировать и изменять цены на квартиры в зависимости от спроса и ситуации на рынке.
Что мы исследовали?
Изначально в качестве наработок нам досталась математическая модель, в которой обрабатывалась исходная информация. Качество модели, которую передали нам, составляло чуть меньше 50%. Выглядело так, будто за основу взяли некую универсальную модель, и не слишком внимательно адаптировали под задачу заказчика.
Выборка по такому числу критериев получилась насыщенной и до крайности «дырявой». Ошибки в ETL процессах, хранении данных и игнорирование бизнес логики добавляли интриги не меньше, чем выбранный подход к прогнозированию цен.
Наша группа аналитики “ворвалась на танцпол”. И первая же мысль, озвученная лидом проекта: “нужно начинать с анализа данных и уменьшения количества параметров, а уже после чинить модель”.
С этого момента начались основные работы по проекту. Хотя у команды и был опыт в задачах ценообразования, полного понимания специфики процессов в сфере недвижимости не хватало.
Сначала мы выполнили все работы в знакомом нам домене: привели существующие данные в порядок, исправили некорректные связи данных. Это уже улучшило качество модели с 50% до 70%.
Бюджет не позволял начать разработку системы со сложной бизнес-логикой “с нуля”, при этом нынешняя реализация требовала основательного совершенствования.
В итоге вырисовывались две сюжетных линии развития ситуации:
- Идти по существующему пути и продолжить доработку и корректировку прошлой модели, стараясь применить максимум существующих наработок.
- Упростить решение, собрать интуитивно понятный дашборд, который будет агрегировать нужную аналитику.
Эти варианты предложили заказчику, который выбрал первый путь, чтобы как можно больше задействовать наработки предыдущей команды.
Мы изменили многое — но, по желанию заказчика, оставили ранее проработанную бизнес-логику. Особенно больно от этого было команде backend-разработки, на плечи которой лег непростой труд по сборке обучающей выборки и битве с 1С за данные.
Погружаемся в предметную область
Чтобы осознанно менять алгоритмическую модель, важно погружение в контекст. Наша команда за время работы над проектом узнала много интересных подробностей ценообразования на рынке недвижимости.
Не удержусь и поделюсь несколькими инсайтами из бизнес-правил застройщиков:
- Некоторые квартиры не принадлежат застройщику напрямую. Часть квартир в собственности у инвесторов, и их продажей компания-застройщик не занимается. Для таких квартир существует отдельная логика формирования цен.
- Оказывается, застройщику не выгодно идти по пути “продать все квартиры как можно скорее”. План продаж выстраивается относительно бизнес-правил, принятых у конкретного девелопера. Выручка ожидается равномерной, в течение запланированного периода времени. Звучит просто, но на деле эффективно составить такой план на 4 года вперед с NP-трудная задача.
- У каждого застройщика — уникальный набор скидок, акций и всего, что с этим связано. Временами запутанный. Еще и часто изменяемый, без уведомлений… Разобраться в этом — отдельный квест. )
Но главное, что стал понятен реальный запрос на задачу со стороны бизнеса: компании-девелоперу важно, какие квартиры продаются быстрее, какие — наоборот, не вызывают интереса у покупателей. Словом, отслеживать жизненный цикл квартиры.
Берем не количеством, а качеством данных
Работа с данными принесла ожидаемый эффект: многие параметры, заявленные отделом продаж как критически важные, концептуальные для бизнес-процессов, связанных с жизненным циклом квартир… но никак не влияют на цену.
В результате исследований, создали модель, которая не только прогнозирует вероятность продать квартиры в следующем месяце и индексирует предложения по конкретным объектам.
Если вероятно, что конкретно эта квартира будет скоро продана, процент индексации будет выше. На те квартиры, которые согласно предсказанию модели, будут продаваться дольше, — соответственно, индексация будет минимальной.
В дополнение к модели, вывели «шахматку» квартир (расположение внутри ЖК, с разделением по домам и этажам). Получился специальный и нативный интерфейс, понятный конечному пользователю: выбирая квартиру (из выставленных на продажу), оперативно видишь, насколько вероятно через месяц конкретную квартиру продать.
Еще одно применение этого инструмента — обоснование предсказаний модели. Выбрав для анализа один или несколько объектов недвижимости, можно выявить факторы, значимые для формирования индексации.
А как же спрос и конкуренты?
А сами продолжили исследовать, как повысить качество модели и расширить набор учитываемых параметров. Довольно быстро выяснили, что очевидной недоработкой стало отсутствие конкурентного анализа. Практика показала, что это — значимый фактор при индексации спроса.
С анализом конкурентов задача непростая и отчасти творческая.
Стоимость квартир секретом не является: ее указывают начиная от сайтов других девелоперов, и до агрегаторов типа Циана или Авито.
Загвоздка в том, что цена, по которой объект выставлен на площадке, часто отличается от цены при продаже. Причины в основном — системы скидок и акций у застройщиков. Как раз про их запутанность упоминал выше.
Со спросом все тоже оказалось не так очевидно: спрос прогнозируется по разным сочетаниям факторов, в зависимости от ЖК.
Для одних ЖК это будут звонки, для других — визиты. Или другой индикатор, уникальный для конкретного объекта.
Наверное, справедливо будет сказать, что в таких нюансах и отличается кастомная разработка систем ценообразования с индивидуально разработанной аналитикой в сравнении с покупкой готового “коробочного” решения от интеграторов. Особенностей настолько много, даже внутри одной сферы, что для рынка в совокупности учесть каждый не получится.
Да и девелопмент — не та сфера, где можно навязать правила игры компаниям со стороны интегратора. )
А “коробка” — это, как правило, fancy BI с графиками темпов спроса.
Итоги и выводы
Наша выверенная и доработанная модель, в части точности предсказаний по оффлайн метрикам, выросла с 50% до 95%.
Во время тестирования системы в течение месяца, получили приятные онлайн метрики: расхождение между прогнозом нашей доработанной модели и отчетами отдела продаж было в пределах 10%!
К слову, расхождение между изначальной моделью, которую нам передали, и фактическими показателями, было около 30%.
В результате, модель после доработок нашей команды преобразилась в поддерживаемую и “живую”. Словом, УРА, на одно легаси в мире стало меньше. ?
Если говорить, что приобрел лично я за время работы в проекте, то это расширение Soft skills в общении с бизнес-заказчиком.
Сам опыт оказался крутым: погрузиться в новую предметную область, действовать, опираясь не только на информацию заказчика, но и учитывать внешние факторы.
Ну и в который раз убедился в истинности одной из заповедей математического моделирования: “Прежде чем решать задачу, подумай, что делать с ее решением”.
