В сообществе разработчиков появилось описание архитектуры мониторинга объявлений о продаже недвижимости, построенной на платформе автоматизации n8n. Автор подчёркивает, что это не отчёт о внедрении и не кейс заказчика, а приглашение к обсуждению границы между сбором данных и принятием решений. Схема включает плановый и ручной запуск через Telegram-бота, нормализацию полученных объявлений и сравнение с предыдущим состоянием. Отдельно рассматривается идея добавить слой решений на основе API Luna Decisions, однако реальных вызовов этого API и проверки интеграции в материале нет. Предыстория такова: около месяца назад автор подробно обсуждал архитектуру проекта в личной переписке с участницей сообщества, которая предложила набор «хардкорных» идей — предохранитель на объём выдачи, счётчик пропусков missed_runs для отсечения ложных удалений и использование сессий Telethon. До реализации этих паттернов дело не дошло, поскольку заказчик активно пользовался проектом. Момент настал после релиза GPT-6 Luna Decisions с её Decisions API, что и подтолкнуло автора к альтернативной мысли, изложенной в публикации.

Минимальный контур workflow состоит из нескольких последовательных шагов. Сначала по расписанию или вручную через Telegram-бота выполняется HTTP-запрос к площадке с объявлениями. Затем нода Hata_Normalizer преобразует данные в плоские поля, после чего читается предыдущее состояние из Google Sheets. Диспетчер сравнивает записи по ad_id, обновляет витрину и записывает события. Далее Build_Prompt формирует статистику и события, текстовая модель готовит сводку, которая отправляется в Telegram. На фрагменте workflow видны три входа: обработка ошибок, запуск по расписанию и команды из Telegram; плановый и ручной запуск сходятся к одной цепочке получения и нормализации данных. Слой Decisions на этом фрагменте отсутствует. В качестве хранилища предыдущего состояния и витрины для человека используется Google Sheets, что удобно для небольших выборок, но не решает вопросы конкурентных запусков и атомарности обновления. Если ручной запуск пересекается с плановым, это нужно учитывать независимо от модели. Способы доступа к площадке и настройки прокси автор оставляет за рамками: это отдельная тема вместе с ограничениями площадки, частотой запросов и полнотой выдачи, а прокси сам по себе не гарантирует ни разрешённый доступ, ни корректный сбор.

Нормализация извлекает ad_id, ссылку, две цены (в у.е. и рублях), комнатность, площадь, этаж, этажность, год постройки, район, адрес и время публикации. Автор отмечает, что две цены из калькулятора не обязательно отражают исходную валюту продавца, поэтому по ним нельзя уверенно установить причину изменения. Кроме того, предусмотрены приземлённые проверки: если площадь пришла как «Н/Д», её нельзя использовать в расчёте цены за метр; отсутствующая цена не должна участвовать в сравнении как ноль; время публикации нужно проверять как дату, а не подставлять вместо него ID; если источник не вернул ссылку, лучше сохранить null, чем собирать непроверенный URL. Эти правила снижают риск ошибок до применения любых моделей и подчёркивают, что качество входных данных важнее выбора алгоритма на следующем шаге.

Диспетчер реализует текущую логику сравнения. В приведённом фрагменте кода видно, как формируются события: для новых объявлений — «НОВИНКА», для снижения цены — «УЦЕНКА» с указанием разницы в долларах и категорией (например, 500–1500, 1501–2900, 2901+). Также рассчитывается временной тег на основе даты публикации: «Сегодня», «до 4 дней», «4–14 дней», «14–42 дней», «42+ дней». Если объявление исчезло из выдачи, оно помечается как «ПРОДАНО/СНЯТО». Автор подчёркивает, что это исходная логика, а не универсальная реализация, и что она уже используется заказчиком. В коде видно, как читаются данные из Hata_Normalizer и листа Read_Active_Sheet, строятся карты по ad_id, после чего выполняется upsert. Такая структура позволяет сравнивать записи, но не претендует на роль эталонного решения.

Контекст обсуждения связан с недавним релизом GPT-6 Luna Decisions и её Decisions API, который возвращает типизированные оценки. В описании на OpenRouter автору понравился подход, при котором модель не просто пишет текст, а выдаёт результат, который можно проверить, сохранить и сравнить с порогом. Однако он не уверен, что такой API необходим в его случае: возможно, достаточно нескольких условий в Code-ноде. В сообществе ранее обсуждались идеи предохранителя на объём выдачи, счётчика пропусков missed_runs и использования сессий Telethon, но до реализации дело не дошло. Теперь автор хочет понять, стоит ли добавлять отдельный слой решений, и готов сравнить подход с API и без него, чтобы оценить оправданность дополнительной сложности. Если окажется, что достаточно нескольких условий, это тоже будет полезным исходом.

Для российского рынка недвижимости и разработчиков автоматизации эта дискуссия важна, поскольку показывает типовой подход к мониторингу объявлений без привязки к конкретным площадкам. Многие команды используют Google Sheets как временное хранилище, но при росте объёмов сталкиваются с ограничениями по конкурентному доступу и дедупликации. Интеграция с API, возвращающим структурированные оценки, могла бы снизить нагрузку на человека, но требует тщательной проверки входных данных. Кроме того, вопросы доступа к площадкам, настройки прокси и частоты запросов остаются за рамками обсуждения, хотя именно они часто определяют полноту выдачи. Альтернативой Luna Decisions могут быть собственные правила на JavaScript или другие модели, но выбор зависит от готовности проверять и поддерживать такой слой.

В перспективе автор планирует сравнить подход с API и без него, чтобы понять, оправдана ли дополнительная сложность. Открытыми остаются вопросы: как избежать ложных срабатываний при пропусках запусков, как обеспечить атомарность обновления витрины и стоит ли доверять типизированным оценкам модели без ручной проверки. Если окажется, что достаточно нескольких условий в Code-ноде, это тоже будет полезным исходом. Пока же сообщество приглашается к обсуждению границы между парсингом и принятием решений, а также к оценке рисков интеграции внешних API в чувствительные к данным проекты. Проверка JavaScript на синтетических данных, как отмечает автор, не заменяет реальной проверки интеграции, поэтому окончательные выводы делать рано.