Портал нерухомості з геопошуком та іпотечним калькулятором

Розробка порталу нерухомості: де ламається пошук об'єктів

Портал нерухомості — це насамперед пошук. Покупець задає район, ціну, площу, поверх, тип будинку та наявність іпотечної програми й чекає видачу з картою за частки секунди.

Коли розробка порталу нерухомості починається з вітрини, а не з моделі даних, каталог тримається на перших тисячах об'єктів і розсипається на реальному обсязі.

Повільний пошук об'єктів майже завжди впирається у важкі вибірки: відбір іде з'єднанням десятка таблиць без покривних індексів, а лічильник «знайдено 12 480» рахується повним проходом.

Відгук зростає з кожною тисячею оголошень, і фільтри не знаходять об'єкти просто тому, що значення нормалізовані по-різному — «2-кімн.» і «2 кімнати» лежать у базі як різні сутності.

Друга точка відмови — застаріла база об'єктів. Статус «продано» залишається в лістингу, бо вивантаження від забудовника надходить файлом раз на добу й падає на помилці формату, а ціна в картці та в іпотечному калькуляторі рахується з різних джерел.

Користувач бачить розбіжність і йде до конкурента, а агент отримує дзвінки щодо об'єктів, яких немає.

Третя — відмова під навантаженням. Геопошук і карта з кластеризацією б'ють по базі окремим запитом на кожне переміщення карти, і пік звернень у вихідні валить сервіс повністю.

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

Що дає перероблений пошук: швидкість, точність, стійкість

Геопошук перестав бути повним перебором: просторовий індекс на PostGIS і заздалегідь пораховані межі районів віддають вибірку «в радіусі від точки» за індексом, а не перерахунком відстаней по всій базі.

Швидкість видачі тримається в межах часток секунди там, де раніше сторінка збиралася секундами. Заодно зникає причина порожніх результатів: фільтри застосовуються узгоджено, і об'єкти не губляться через розбіжність меж районів і координат.

Точність геопошуку тримається на нормалізації адрес і єдиній геометрії: будинок, вулиця, район і полігон на карті описуються одними даними. Якщо за набором фільтрів збігів немає, пошук показує найближчі відповідні об'єкти й пропонує послабити умову замість порожнього екрана. Частка видач без результатів падає — на тих самих запитах зростає кількість заявок на перегляд.

Іпотечний калькулятор рахує в браузері за попередньо завантаженими умовами банків: перерахунок миттєвий під час руху повзунка й не блокує карту зі списком.

Стійкість до навантаження дають репліки для читання й кеш видачі — вечірній пік, коли відкриті тисячі карток, проходить без зростання часу відгуку.

Актуальність карток об'єктів забезпечує інвалідація кешу за подією: змінилася ціна або статус — картка та її місце у видачі оновлюються в межах хвилини, а не після планового перезбирання.

Геометрія та індекс оновлюються тією самою транзакцією, що й дані об'єкта, тому пошук не показує проданої квартири як доступної.

Варіанти реалізації порталу: готове ядро, доопрацювання, збирання

Портал нерухомості збирають трьома способами, і вибір визначається не смаком, а тим, наскільки ваша логіка підбору відрізняється від типової. Готова платформа закриває стандартний сценарій: каталог об'єктів, фільтри, карта, іпотечний калькулятор за типовими умовами.

Щойно з'являються власні правила ранжування, кілька джерел даних або нестандартні іпотечні сценарії, межа між готовим і власним зміщується — це вже інший обсяг роботи.

Порівняння підходів

Практично вибір вирішують три питання: обсяг каталогу й частота його оновлення, наскільки нестандартна логіка підбору, і що вже є в наявності.

Перенесення каталогу — окремий ризик: помилки в координатах і адресних полях ламають геопошук, тому переносимо з вибірковою звіркою даних, а не потоком.

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

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

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

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

Що передаємо на руки: схеми, регламенти, документація

Портал нерухомості живе довше, ніж команда, яка його збирала. Тому разом з кодом передаємо документи, за якими новий інженер або редактор працює без нас. Тримаємо їх у репозиторії поруч із проєктом — так після кожного релізу вони не розходяться з реальністю.

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

Приймання йде за переліком перевірок: піднімаємо портал на чистому середовищі строго за інструкцією й проходимо ключові сценарії — від пошуку на карті до розрахунку іпотеки. Прогалини виявляються на цьому кроці, а не через пів року.

Кейс: геопошук за районами й зростання кількості цільових заявок

Агенція, що продає житло в новобудовах, прийшла з порталом, де пошук працював за рядком адреси, а райони були перелічені текстовим списком у фільтрі.

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

Що змінили в геопошуку

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

Підкладка карт Яндекс Карты, важкі вибірки рахуються заздалегідь за сіткою й віддаються з підготовленого набору — фільтр відповідає миттєво навіть на десятках тисяч об'єктів.

Картка об'єкта

Іпотечний калькулятор перенесли всередину картки: платіж, перший внесок і строк перераховуються без перезавантаження сторінки, і тут же видно, чи проходить об'єкт під умови. Додали порівняння до чотирьох об'єктів і збереження вибірки, щоб повернутися до неї з телефона.

Через два місяці після запуску конверсія з перегляду картки в заявку зросла з 1,2% до 3,4%, частка звернень із вибраним районом — з 18% до 61%.

Відмови на етапі підбору скоротилися майже вдвічі, а менеджери почали отримувати заявки з уже сформованим запитом: район, бюджет і параметри іпотеки відомі до дзвінка.

Чим відрізняється геопошук за межами районів від пошуку за радіусом?

Радіус — це коло навколо точки на карті: користувач задає центр і охоплення, система відбирає все, що в нього потрапило.

Такий запит рахується швидко й не потребує даних про межі, але коло майже ніколи не збігається з адміністративним: будинок через дорогу потрапляє у видачу як «сусідній район», а дальній кут потрібного району з нього випадає.

Радіус не розрізняє перешкод — річки, залізниці, промзони. Об'єкт по прямій близько, а дорога до нього йде в об'їзд, і покупець отримує картки, які йому свідомо не підходять.

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

Фільтри за районами дають передбачувану видачу, але потребують актуальних контурів — межі переглядаються, нові мікрорайони з'являються, а спірні ділянки на стику доводиться розмічати вручну під час завантаження даних.

Інженерно це вирішується не вибором одного режиму, а їх комбінацією. Потрапляння об'єкта в полігон рахується один раз під час публікації оголошення й зберігається як атрибут — фільтр за районом перетворюється на звичайну умову відбору й не перераховує геометрію на кожен запит.

Радіус залишається для сценарію «поруч із роботою або станцією» і для розширення видачі, коли за точними межами варіантів мало: показуємо найближчі, поступово збільшуючи охоплення.

Що ставити основним — залежить від сценарію покупця. Той, хто вибирає район, чекає фільтр за межами й дратується, бачачи чужі райони у списку. Той, хто прив'язаний до точки, чекає радіус і враховує час у дорозі, а не адміністративні лінії.

Помилки обох режимів видно в замірах: частка відкритих карток поза вибраним районом і частка відмов після перегляду карти показують, де режим промахується.

Технічні сумніви: інтеграції, навантаження, якість даних

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

Дані приводяться до єдиної схеми — геокодування, дедуплікація за адресою й координатами, перевірка обов'язкових полів на вході.

Що робити з помилками в оголошеннях із вивантажень?

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

Як переноситься наявна база об'єктів?

Разовий імпорт: зіставлення полів, тестовий прогін на копії, звірка кількості записів і повноти гео. Стара база залишається доступною для читання, поки розбіжності не зійдуть до нуля, тому перемикання оборотне.

Хто супроводжує інтеграції після запуску?

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

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

Щоб оцінка була предметною, а не «плюс-мінус порядок», до розмови варто додати те, що вже є. Опишіть задачу: які сценарії закриває портал — пошук об'єктів, карта з кластеризацією, фільтри, іпотечний калькулятор, кабінет агента або забудовника.

Прототипи, схеми даних і вивантаження розберемо на їхній основі — так план робіт спирається на факти, а не на припущення.

Що допомагає повернутися з планом робіт, а не із загальними словами:

• Ролі й аудиторія: покупець, рієлтор, забудовник, адміністратор — у кожної свій набір прав і сценаріїв.
• Джерела об'єктів: регулярні вивантаження від забудовників, інтеграція з CRM або ручне наповнення — від цього залежать схема зберігання й частота оновлення.
• Гео: зони покриття, вимоги до точності адрес, чи потрібен пошук за радіусом і полігоном.
• Іпотечний калькулятор: банки-партнери й програми, хто оновлює ставки й з якою періодичністю.
• Навантаження й терміни: скільки об'єктів у базі, скільки звернень у піку, чи є прив'язка до дати запуску.
• Чинний портал, якщо він є: доступ до репозиторію, документація, відомі вузькі місця.

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