Как построить сервис уведомлений о новых объектах недвижимости

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

Ниже — практическая схема, как построить такой сервис: от источников и фильтров до очередей, дедупликации, доставки уведомлений и контроля качества данных. Я описываю подход, который выкристаллизовался из нескольких лет работы с парсерами досок объявлений, API застройщиков и риелторских CRM.

Зачем вообще нужен такой сервис

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

• сокращает время на мониторинг;
• ускоряет реакцию на свежие объекты;
• снижает риск пропустить хороший вариант;
• помогает вести историю цен и изменений;
• позволяет строить аналитику по рынку и конкретным фильтрам.

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

Каким должен быть MVP сервиса

На старте не нужен «комбайн» из 20 модулей. Достаточно минимального, но устойчивого набора функций:

• сбор объявлений из 2–5 источников;
• фильтрация по параметрам пользователя;
• дедупликация;
• сравнение с уже виденными объектами;
• отправка уведомлений в Telegram, email или push;
• базовая история изменений.

Такой MVP уже приносит ценность. Дальше можно добавлять аналитику, скоринг ликвидности, CRM-интеграции и гибкие сценарии подписок. Я не раз убеждался: лучше запустить простой конвейер с двумя источниками и честной дедупликацией, чем полгода пилить «универсальную платформу», которая так и не увидит пользователей.

Архитектура сервиса: из чего она состоит

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

1. Слой источников данных

Это площадки объявлений, агрегаторы, сайты застройщиков, личные кабинеты и открытые API. В российском контексте чаще всего приходится работать с разными типами источников одновременно:

• публичные страницы с объявлениями;
• JSON-эндпоинты, которые отдают данные сайту;
• внутренние поисковые API;
• RSS или выгрузки;
• вебхуки и партнерские интеграции, если они доступны.

Практический вывод простой: не стоит завязываться только на HTML-парсинг. Если источник отдает структурированные данные через API, это обычно стабильнее и дешевле в поддержке. HTML меняется без предупреждения, а API, даже неофициальный, живёт дольше. К тому же парсинг HTML всегда дополнительная нагрузка на CPU и сеть, тогда как JSON приходит готовым.

2. Сборщик или парсер

Сборщик отвечает за получение новых карточек, обновление цены, статуса и других полей. Здесь важны:

• расписание обхода;
• повторные попытки;
• контроль лимитов;
• защита от дублей запросов;
• логирование ошибок.

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

3. Нормализатор данных

У каждого источника свои форматы. Один пишет площадь в 42.5, другой — 42,5, третий хранит это в нескольких полях. Нормализатор приводит всё к единой схеме:

• адрес;
• координаты;
• тип объекта;
• цена;
• площадь;
• этаж;
• количество комнат;
• источник;
• дата публикации;
• ссылка;
• ID объявления.

Без нормализации невозможны корректная фильтрация, сравнение и аналитика. Это самая рутинная, но критичная часть: если вы не приведёте цену к числу, а площадь к квадратным метрам, никакой скоринг потом не заработает. Часто приходится чистить юникод-символы, отрезать валюту, разбирать диапазоны («от 4,2 до 4,8 млн»).

4. Хранилище

Обычно нужны два типа хранения:

• оперативная база для текущих объявлений и статусов;
• историческое хранилище для изменений цены, текста, фото и времени публикации.

Если хранить только «последнее состояние», вы потеряете важный контекст: как быстро дорожает объект, как часто его перезаливают и когда он исчезает. Историческая база — это основа для аналитики ликвидности и ценовых трендов. Я обычно использую реляционную БД для оперативных данных и append-only таблицы для логов изменений, чтобы можно было откатиться к любому моменту.

5. Движок правил и подписок

Именно здесь рождается ценность сервиса. Пользователь задает правила:

• район;
• цена;
• тип недвижимости;
• площадь;
• этаж;
• срок сдачи;
• класс дома;
• новостройка или вторичка;
• наличие ремонта;
• расстояние до метро или центра.

Движок правил сравнивает новые объявления с подписками и решает, кому отправлять уведомление. Важно не превращать его в монолит: я предпочитаю декларативные фильтры, которые можно комбинировать. Пользователь со временем начинает хотеть больше гибкости, поэтому лучше сразу заложить DSL для условий или хотя бы JSON-структуру правил.

6. Модуль доставки уведомлений

Это конечная точка цепочки:

• Telegram-бот;
• email;
• push в браузере;
• мобильные push-уведомления;
• SMS в отдельных сценариях.

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

Как спроектировать поток данных

Проверенная схема выглядит так:

1. Источник отдает новые данные.
2. Сборщик кладет сырые записи в очередь.
3. Нормализатор приводит данные к общему формату.
4. Дедупликатор проверяет, не видели ли объект раньше.
5. Фильтры находят подходящие подписки.
6. Уведомление уходит пользователю.
7. Результат логируется и сохраняется в историю.

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

Очереди и асинхронная обработка: почему без них тяжело

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

Что дает очередь

• не теряются задачи при сбоях;
• можно увеличивать число воркеров;
• проще переживать пики нагрузки;
• легче повторять неудачные операции;
• можно отдельно ускорять критичные этапы.

Что выносить в очередь

• обход источников;
• скачивание карточек;
• парсинг изображений;
• нормализацию;
• дедупликацию;
• отправку уведомлений;
• пересчет индекса релевантности.

Для старта подойдет простая очередь, но при росте лучше сразу думать о ретраях, приоритетах и дедлайнах задач. Я обычно беру Redis + BullMQ или RabbitMQ: для первых нескольких сотен подписок этого хватает с запасом. Если вы планируете собирать миллионы объявлений, смотрите в сторону Kafka, но это уже отдельная история.

Дедупликация: самая недооцененная часть

В недвижимости дубли — это не исключение, а норма. Один и тот же объект может появиться:

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

Как дедуплицировать

Используйте сразу несколько признаков:

• ID в источнике;
• URL;
• адрес;
• координаты;
• цена;
• площадь;
• количество комнат;
• фото;
• описание;
• телефон или контакт продавца, если доступен.

Лучше применять не один жесткий ключ, а набор правил и fuzzy matching. Иначе вы будете либо терять новые объекты, либо засорять ленту повторениями. В идеале — комбинированный подход: если совпали адрес и площадь, это почти наверняка дубль, даже если цена изменилась.

Типичная ошибка

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

Как фильтровать новые объекты правильно

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

Базовые фильтры

• город;
• район;
• метро;
• цена от и до;
• площадь;
• число комнат;
• тип недвижимости;
• этаж;
• срок сдачи;
• ремонт;
• наличие мебели;
• новостройка / вторичка.

Продвинутые фильтры

• цена за квадратный метр;
• отклонение от средней цены района;
• удаленность от точки на карте;
• история цены;
• снижение цены за последние N дней;
• срок размещения;
• признаки срочной продажи;
• совпадение с шаблоном спроса пользователя.

Хорошая практика

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

Каналы уведомлений: что выбрать

Для рынка недвижимости в России чаще всего выигрывает связка Telegram + email. Telegram — для мгновенных сигналов, email — для сводок и истории. Я бы не советовал SMS на старте: дорого, а польза сомнительна, если только речь не о very hot leads.

Что должно быть в самом уведомлении

Слабое уведомление бесполезно. Сильное уведомление экономит время. Когда пользователь получает сообщение, он должен за 10–15 секунд понять, стоит ли открывать карточку.

Минимальный состав карточки

• заголовок;
• цена;
• район или адрес;
• площадь;
• количество комнат;
• ссылка;
• источник;
• время публикации;
• 1–3 фото;
• отметка, почему объект попал в подборку.

Лучше сразу показать

• насколько объект соответствует фильтру;
• есть ли снижение цены;
• это новый объект или обновление старого;
• насколько давно он опубликован;
• есть ли риск дубля.

Если уведомление слишком короткое, пользователь вынужден идти в источник и тратить время. Если слишком длинное — его перестают читать. Я обычно делаю компактную карточку с фото, ценой, адресом и кнопкой «Открыть», а детали подгружаются уже в боте или на сайте.

Как избежать спама и «шума»

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

Что помогает

• ограничение частоты уведомлений;
• группировка похожих объектов;
• режим дайджеста;
• приоритизация по релевантности;
• исключение повторов;
• «тихий режим» ночью;
• отдельные пороги для срочных и обычных событий.

Пример

Если пользователь ищет аренду в одном районе, лучше прислать одно сильное уведомление с 5 подходящими вариантами, чем 15 отдельных сообщений подряд. Я реализую это через агрегацию за короткий интервал (например, 10–15 минут): события копятся в буфере, а затем отправляются одним сообщением с лучшими объектами.

Метрики, которые нужно считать с первого дня

Без метрик сервис быстро превращается в черный ящик. Важно понимать, что происходит на каждом этапе конвейера, иначе вы не заметите, как у вас всё сломалось.

Что измерять

• количество новых объектов в час/день;
• долю дублей;
• процент ложных срабатываний;
• время от публикации до уведомления;
• доставляемость по каналам;
• open rate;
• click-through rate;
• отказ от подписки;
• среднее число объектов на одну подписку.

Зачем это нужно

Эти цифры показывают, где сервис теряет ценность:

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

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

Технические ограничения, о которых часто забывают

1. Частота обхода

Нельзя бесконечно опрашивать источник. Нужно балансировать между скоростью и нагрузкой. Слишком частый опрос может привести к бану по IP или к блокировке аккаунта. Обычно я начинаю с обхода раз в 5–10 минут для горячих источников и раз в час для второстепенных, затем подстраиваю под реальную частоту появления новых объектов.

2. Изменчивость верстки

Площадки часто меняют HTML, классы и структуру карточек. Поэтому парсер должен быть устойчивым к изменениям. Я использую CSS-селекторы, которые не зависят от порядка элементов, и обязательно покрываю парсер тестами с реальными примерами страниц. Идеально — иметь мониторинг, который сигналит, если структура изменилась и парсер перестал находить ключевые поля.

3. Ограничения доступа

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

4. Юридические риски

Нужно учитывать правила источников, условия использования данных и допустимые сценарии автоматизации. Для коммерческого продукта это особенно важно. Я не юрист, но всегда советую проконсультироваться, если вы собираетесь перепродавать данные или делать публичный сервис. Иногда проще договориться о партнерском API, чем тянуть данные парсингом.

5. Неполные данные

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

Пошаговый план запуска

Этап 1. Определите MVP

• Выберите 2–3 источника.
• Зафиксируйте список полей.
• Опишите один сценарий пользователя.
• Решите, куда уходят уведомления.

Этап 2. Соберите конвейер

• Парсинг.
• Очередь.
• Нормализация.
• Дедупликация.
• Фильтрация.
• Уведомление.

Этап 3. Добавьте контроль качества

• Логи.
• Метрики.
• Ретрай ошибок.
• Тесты на структуру источников.
• Историю изменений.

Этап 4. Настройте пользовательский опыт

• понятные фильтры;
• шаблоны подписок;
• приоритеты уведомлений;
• архив найденных объектов;
• быстрый просмотр деталей.

Этап 5. Расширяйте функциональность

• история цен;
• скоринг ликвидности;
• сравнение районов;
• интеграции с CRM;
• API для партнеров;
• аналитика по застройщикам и объектам.

Чек-лист перед запуском

• [ ] Есть минимум один стабильный источник данных.
• [ ] Схема данных унифицирована.
• [ ] Настроена дедупликация.
• [ ] Уведомления не дублируются.
• [ ] Есть ретраи и логирование.
• [ ] Измеряется время от публикации до уведомления.
• [ ] Пользователь может управлять фильтрами.
• [ ] Канал доставки подходит под реальный сценарий.
• [ ] Есть защита от спама.
• [ ] Система переживает сбой одного источника без остановки всего сервиса.

Типичные ошибки при разработке

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

Вывод

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

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

FAQ

Какой канал уведомлений лучше всего подходит для недвижимости?

Чаще всего — Telegram. Он быстрый, привычный и удобен для карточек с фото, ценой и ссылкой. Email оставьте для дайджестов.

С чего начать, если нужен MVP?

С 2–3 источников, простой схемы данных, дедупликации и одного канала уведомлений. Этого уже достаточно, чтобы проверить ценность продукта.

Что важнее: скорость или точность?

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

Нужно ли хранить историю объектов?

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

Как бороться с дублями?

Использовать несколько признаков одновременно: ID, URL, адрес, площадь, цену, фото и описание. Один ключ почти никогда не работает идеально.

Можно ли строить такой сервис только на HTML-парсинге?

Можно начать, но для долгосрочного проекта лучше комбинировать HTML, API и другие структурированные источники, если они доступны. HTML слишком хрупкий, а API стабильнее и дешевле в поддержке.