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

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

Круто получить новую задачу. Еще лучше — если задача амбициозная. А когда это что-то новое для тебя лично, включается ВАУ-эффект: срочно бежать и сворачивать горы!

Намного сложнее, если эти горы уже пытались свернуть. Еще хуже, если вместо этого пробили в породе многоуровневую сеть из туннелей. А карту туннелей после третьего уровня обновлять перестали.

Поставили цель:

Заказчик — компания-застройщик.

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

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

Качество модели, которую передали нам, составляло чуть меньше 50%.

С таким же успехом можно подкинуть монетку и задать вопрос — "стоит ли индексировать цену для этой квартиры?". И, чем больше мы изучали набор параметров, тем больше удивлялись: скажем, объяснение тому, для чего учитывалась погода, найти мы не смогли.

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

Выборка по такому числу критериев получилась насыщенной и до крайности "дырявой". Ошибки в ETL процессах, хранении данных и игнорирование бизнес логики добавляли интриги не меньше, чем выбранный подход к прогнозированию цен.

Наша группа аналитики “ворвалась на танцпол”. И первая же мысль, озвученная лидом проекта : “нужно начинать с анализа данных и уменьшения количества параметров, а уже после чинить модель”.

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

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

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

В итоге выкристаллизовались две сюжетных линии развития ситуации:

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

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

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

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

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

Причину мы тоже выявили: четкой формулы индексации не существовало.

Зато в наличии много отраслевых нюансов и терминах, не все из которых понятны людям не из сферы. Так, например, я сам узнал о специальном термине — "вымывание квартир". И с уборкой это оказалось никак не связано.

А если серьезно, то как ни объемен опыт и в каких бы сотнях терабайт ни измерялся тот объем данных, которые ты успел исследовать и проанализировать за годы работы, — новая предметная область всегда в первую очередь новая. И первая реакция, при виде 700 параметров с неочевидной взаимосвязью, — это желание мрачно погрустить пару минут. Ну и начать работу, само собой!

Поделюсь несколькими инсайтами из бизнес-правил застройщиков:

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

Квартир много, характеристик у них еще больше. Равно как и статусов резерва квартир: изначально их немало, но реальное значение имели (в рамках бизнес-процессов заказчика) всего два, остальные — эквивалентны статусу продажи.

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

Осталось меньше 50 переменных из первоначальных 700.Когда число параметров сократили, качество прогнозирования выросло с 70% до 85%.

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

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

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

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

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

Еще одно применение этого инструмента — обоснование предсказаний модели.

Выбрав для анализа один или несколько объектов недвижимости, можно выявить факторы, значимые для формирования индексации.

К слову, это дает не только ценную информацию для аналитиков, но и для клиентов: готовый набор параметров, как обоснование стоимости конкретного объекта. Вот вам и статистически выверенный ответ на вопрос “а почему так дорого?”. ))

Разобрались с переменными, выкатили в тестирование заказчику MVP.

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

С анализом конкурентов задача непростая и отчасти творческая.

Стоимость квартир секретом не является: ее указывают начиная от сайтов других девелоперов, и до агрегаторов типа Циана или Авито.

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

Со спросом все тоже оказалось не так очевидно: он прогнозируется по разным сочетаниям факторов, в зависимости от ЖК.

Для одних ЖК это будут звонки, для других — визиты. Или другой индикатор, уникальный для конкретного объекта.

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

Да и девелопмент — не та сфера, где можно навязать правила игры компаниям со стороны интегратора. )

А “коробка” — это, как правило, fancy BI с графиками темпов спроса.

Наша выверенная и доработанная модель, в части точности предсказаний по оффлайн метрикам, выросла с 50% до 95%.

Во время тестирования системы в течение месяца, получили приятные онлайн метрики: расхождение между прогнозом нашей доработанной модели и отчетами отдела продаж было в пределах 10%!

К слову, расхождение между изначальной моделью, которую нам передали, и фактическими показателями, было около 30%.

Хочется много написать о том, что легаси-проект, который нам достался, не документирован, и все такое… Но сама тема не нова. Поэтому, вместо “нытингов”, с ноткой гордости напишу о том, что мы не только разобрали проект, но и задокументировали. )

В итоге, модель после доработок стала поддерживаемой и “живой”.

Словом, УРА, на одно легаси в мире стало меньше. 🙂

Если говорить, что приобрел лично я за время работы в проекте, то это расширение Soft skills в общении с бизнес-заказчиком. Получилась серьезная прокачка навыка доносить ценность решений и гипотез команды до стейкхолдеров, “продавать” им новые идеи.

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

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