Портал недвижимости с геопоиском и ипотечным калькулятором

Разработка портала недвижимости: где ломается поиск объектов

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

Медленный поиск объектов почти всегда упирается в тяжёлые выборки: отбор идёт соединением десятка таблиц без покрывающих индексов, а счётчик «найдено 12 480» считается полным проходом. Отклик растёт с каждой тысячей объявлений, и фильтры не находят объекты просто потому, что значения нормализованы по-разному — «2-комн.» и «2 комнаты» лежат в базе как разные сущности.

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

Третья — отказ под нагрузкой. Геопоиск и карта с кластеризацией бьют по базе отдельным запросом на каждое перемещение карты, и пик обращений в выходные валит сервис целиком. Картографическая подложка на данных OpenStreetMap снимает часть ограничений, но не заменяет нормальный пространственный индекс. Разбираем, как это закрывается.

Что даёт переработанный поиск: скорость, точность, устойчивость

Геопоиск перестал быть полным перебором: пространственный индекс на PostGIS и заранее посчитанные границы районов отдают выборку «в радиусе от точки» по индексу, а не пересчётом расстояний по всей базе. Скорость выдачи держится в пределах долей секунды там, где раньше страница собиралась секундами. Заодно уходит причина пустых результатов: фильтры применяются согласованно, и объекты не теряются из-за расхождения границ районов и координат.

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

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

Актуальность карточек объектов обеспечивает инвалидация кэша по событию: изменилась цена или статус — карточка и её место в выдаче обновляются в пределах минуты, а не после плановой пересборки. Геометрия и индекс обновляются той же транзакцией, что и данные объекта, поэтому поиск не показывает проданную квартиру как доступную.

Варианты реализации портала: готовое ядро, доработка, сборка

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

Сравнение подходов

Практически выбор решают три вопроса: объём каталога и частота его обновления, насколько нестандартна логика подбора, и что уже есть в наличии. Перенос каталога — отдельный риск: ошибки в координатах и адресных полях ломают геопоиск, поэтому переносим с выборочной сверкой данных, а не потоком.

Этапы работ: от разбора каталога до передачи в эксплуатацию

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

1. Аудит каталога. Считаем объём и структуру: сколько объектов, типов недвижимости, городов и источников поступления. Находим дубли, пустые поля и расхождения в адресах — от этого зависит, где чистить данные: при загрузке или уже в поиске.
2. Схема данных. Проектируем модель объектов, связи с агентствами и медиа, правила обновления статусов. Координаты и границы районов храним отдельно от текстовых адресов, чтобы фильтры по карте не зависели от формата написания улицы.
3. Настройка поиска и карточек. Собираем индексацию, ранжирование, подсказки и выдачу по видимой области карты; задаём диапазоны цены, площади и условий ипотеки. Отдельно смотрим поведение на широких запросах, где легко получить тысячи результатов.
4. Проверка сценариев. Проходим путь покупателя и агента от поиска до заявки, включая отказы: пустая выдача, снятый объект, недоступные данные о платеже. По итогам правим логику, а не текст ошибок.
5. Передача в эксплуатацию. Фиксируем схему, регламент обновления и уровни доступов, обучаем команду заказчика, оставляем контур для откатов и мониторинга.

Каждый этап закрывается артефактом — схемой, настройкой или отчётом проверки, поэтому приёмка идёт по факту, а не по ощущениям.

Что передаём на руки: схемы, регламенты, документация

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

• Схема архитектуры — слои приложения, связи с выгрузками застройщиков, геосервисом и ипотечным калькулятором, а также что и на какой срок кэшируется.
• Матрица прав доступа — роли от риелтора до администратора: кто видит черновик объекта, кто публикует, кто меняет параметры ипотечных программ; отдельно сервисные учётные записи.
• Регламент обновления данных — расписание синхронизации объектов, поведение при расхождении с источником, порядок снятия с публикации и что при этом происходит с адресом страницы.
• Инструкции для редакторов — обязательные поля карточки, разметка геометок и полигонов на карте, требования к фото и планировкам, проверка адреса перед публикацией.
• Процедуры эксплуатации — резервное копирование с проверкой восстановления, порядок выкладки релиза и откат на предыдущую сборку, сброс кэша после обновления данных.
• Документация по интеграциям — форматы обмена, ограничения на частоту запросов к внешним сервисам, что показывать пользователю при недоступности источника.
• Журнал решений — почему выбран такой способ поиска по карте, где ограничены фильтры и какие участки кода требуют осторожности при правках.

Приёмка идёт по перечню проверок: поднимаем портал на чистом окружении строго по инструкции и проходим ключевые сценарии — от поиска на карте до расчёта ипотеки. Пробелы вскрываются на этом шаге, а не через полгода.

Кейс: геопоиск по районам и рост числа целевых заявок

Агентство, продающее жильё в новостройках, пришло с порталом, где поиск работал по строке адреса, а районы были перечислены текстовым списком в фильтре. Пользователь доходил до карточки, не понимая, что за район вокруг, и уходил: конверсия из просмотра в заявку держалась на 1,2%, только 18% обращений содержали выбранный район, а фильтр отвечал на запрос две-три секунды.

Что поменяли в геопоиске

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

Карточка объекта

Ипотечный калькулятор перенесли внутрь карточки: платёж, первый взнос и срок пересчитываются без перезагрузки страницы, и тут же видно, проходит ли объект под условия. Добавили сравнение до четырёх объектов и сохранение выборки, чтобы вернуться к ней с телефона.

Через два месяца после запуска конверсия из просмотра карточки в заявку выросла с 1,2% до 3,4%, доля обращений с выбранным районом — с 18% до 61%. Отказы на этапе подбора сократились почти вдвое, а менеджеры стали получать заявки с уже сформированным запросом: район, бюджет и параметры ипотеки известны до звонка.

Чем отличается геопоиск по границам районов от поиска по радиусу?

Радиус — это окружность вокруг точки на карте: пользователь задаёт центр и охват, система отбирает всё, что в неё попало. Считается такой запрос быстро и не требует данных о границах, но окружность почти никогда не совпадает с административной: дом через дорогу уходит в выдачу как «соседний район», а дальний угол нужного района из неё выпадает.

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

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

Инженерно это решается не выбором одного режима, а их комбинацией. Попадание объекта в полигон считается один раз при публикации объявления и хранится как атрибут — фильтр по району превращается в обычное условие отбора и не пересчитывает геометрию на каждый запрос. Радиус остаётся для сценария «рядом с работой или станцией» и для расширения выдачи, когда по точным границам вариантов мало: показываем ближайшие, постепенно увеличивая охват.

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

Технические сомнения: интеграции, нагрузка, качество данных

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

Что делать с ошибками в объявлениях из выгрузок?

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

Как переносится существующая база объектов?

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

Кто сопровождает интеграции после запуска?

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

Обсудим задачу и вернёмся с планом работ и оценкой

Чтобы оценка была предметной, а не «плюс-минус порядок», к разговору стоит приложить то, что уже есть. Опишите задачу: какие сценарии закрывает портал — поиск объектов, карта с кластеризацией, фильтры, ипотечный калькулятор, кабинет агента или застройщика. Прототипы, схемы данных и выгрузки разберём на их основе — так план работ опирается на факты, а не на предположения.

Что помогает вернуться с планом работ, а не с общими словами:

• Роли и аудитория: покупатель, риелтор, застройщик, администратор — у каждой свой набор прав и сценариев.
• Источники объектов: регулярные выгрузки от застройщиков, интеграция с CRM или ручное наполнение — от этого зависят схема хранения и частота обновления.
• Гео: зоны покрытия, требования к точности адресов, нужен ли поиск по радиусу и полигону.
• Ипотечный калькулятор: банки-партнёры и программы, кто обновляет ставки и с какой периодичностью.
• Нагрузка и сроки: сколько объектов в базе, сколько обращений в пике, есть ли привязка к дате запуска.
• Действующий портал, если он есть: доступ к репозиторию, документация, известные узкие места.

Дальше мы изучаем материалы, уточняем неясное и возвращаемся с планом работ: разбивка на этапы, оценка каждого этапа и состав команды под ваш случай. Согласуем порядок старта и точки, где нужно ваше участие: доступы, согласование схемы данных, приёмка. Опишите задачу в удобном виде — обсудим следующий шаг.