Интеграция
Bayut и одна и та же квартира, размещённая дважды
Интеграция с Bayut заводит ваши собственные объявления в Telegram-бота для подбора покупателям. Поскольку большинство агентств в ОАЭ размещается и на Bayut, и на Property Finder, конкретная задача здесь — дедупликация: один и тот же объект, пришедший из двух фидов с разными идентификаторами, должен дать покупателю ровно одно уведомление.
Bayut — интеграция: доступ, лимиты и доступность
- Модель авторизации
- Ключ API
- Идентификаторы объявлений
- Выдаются каждым порталом отдельно; идентификаторы Bayut и Property Finder между собой не совпадают
- Доступность в Заливе
- ОАЭ — основной рынок; двойное размещение вместе с Property Finder здесь норма
- Поток данных
- 5 узлов, через воркер
As of 2025-10-01, Telegram Bot API 13.4
Зачем нужна эта интеграция
Bayut и Property Finder в ОАЭ оба считаются стандартом, и агентства сколько-нибудь заметного размера размещаются сразу на обоих. Коммерчески это разумное решение, и оно создаёт проблему данных для любой системы, которая читает оба фида: один и тот же физический объект приходит дважды, с разными идентификаторами портала, иногда с разными фотографиями, а порой и с немного разной ценой — потому что один фид обновили раньше.
Для уведомлений покупателям это важно сразу. Покупатель, подписанный на квартиры с двумя спальнями в конкретной башне, должен услышать о новом объекте один раз. Получить ту же квартиру дважды в течение минуты, под двумя разными номерами объявления, — значит увидеть сломанный бот и неорганизованное агентство; замечают это в первую очередь.
Дедупликация не может опираться на идентификаторы портала, потому что каждый портал выдаёт свои. Работает составная идентичность из тех признаков, которые между фидами не меняются: здание или район, номер квартиры, где он есть, количество спален, площадь и ценовой диапазон. Там, где совпадение получается неоднозначным, лучше удержать объект на проверку, чем гадать: склеить два действительно разных лота хуже, чем показать агенту две записи для сверки.
Как на самом деле движутся данные
Как и на другом портале, интеграция авторизуется не в Bayut напрямую, а в той системе, которая держит ваш пул объектов, — в системе размещения, CRM агентства или в фиде по расписанию. Учётные данные лежат как секреты воркера, а источник фида записывается у каждого объекта, чтобы расхождение можно было отследить до портала, из которого оно пришло.
Модель доступа: API-ключ
Их лимиты и что они означают для вас
Идентификаторы объявлений выдаются каждым порталом отдельно и между собой не соответствуют.
Дедупликация опирается на составную идентичность из устойчивых признаков, а не на идентификаторы. Сопоставление по идентификатору гарантирует, что каждый объект с двойным размещением будет считаться двумя.
У одного и того же объекта в двух фидах может стоять разная цена, если один из них обновили раньше.
Побеждает запись, обновлённая последней, а расхождение пишется в журнал. Разница в цене между порталами — обычно отставание синхронизации и изредка настоящая ошибка, которую агенту стоит увидеть.
Правила рекламы в Дубае требуют номер разрешения RERA, и он присутствует в данных обоих порталов.
Разрешение — не только требование регулятора, но и полезный вторичный признак для дедупликации: у одного и того же объекта на обоих порталах оно одинаковое.
Частота обновления фида различается и между порталами, и между системами размещения.
Один фид опережает другой на минуты или часы. Уведомлять по первому появлению, не дожидаясь второго, правильно; а запись о том, из какого фида объект пришёл, — то, что потом делает расхождение объяснимым.
Как это ломается и что происходит потом
Покупателю приходит один и тот же объект дважды в течение минуты.
Дедупликация не сработала или отработала после подбора. Это самый заметный сбой в схеме с двумя порталами и первое, о чём говорит покупатель.
Два действительно разных лота в одном здании склеились в один.
Составное сопоставление оказалось слишком свободным. Неоднозначные совпадения удерживаются на проверку агентом, а не склеиваются: ошибочная склейка прячет объект от всех покупателей, которые его ищут.
Уведомление о цене сработало из-за расхождения двух фидов, а не из-за реального изменения.
Изменение цены подтверждается по тому же источнику до отправки уведомления. Иначе покупателям сообщают о снижениях, которых не было.
Один фид встал, и пул объектов как будто уменьшился вдвое.
Нужны отдельные оповещения о залежавшихся данных по каждому фиду. Без них вставший фид выглядит как тихий рынок, а пропавшая половина обнаруживается, когда покупатель спрашивает об объекте, увиденном где-то ещё.
Доступность в ОАЭ и остальных странах Залива
Объединённые Арабские Эмираты
Основной рынок Bayut наряду с Property Finder. Двойное размещение здесь норма, поэтому дедупликация — центральная задача, а не краевой случай.
Саудовская Аравия и регион в целом
Присутствие портала и рекламное регулирование различаются. Подтверждайте по каждому рынку отдельно, а не переносите эмиратскую схему как есть.
Поиск по чужим объявлениям
Недоступен, как и на другом портале. Интеграция читает ваш собственный пул объектов.
Агентства с одним порталом
Дедупликация не нужна, и интеграция получается проще. Это стоит подтвердить: строить под случай, которого у вас нет, — лишняя механика без пользы.
Когда эту интеграцию делать не нужно
- Вы размещаетесь только на одном портале. Дедупликация и есть причина, по которой эта интеграция дороже, и без двойного размещения она превращается в механику ради механики.
- В ваших фидах нет устойчивых признаков для сопоставления. Составной идентичности нужны как минимум здание, площадь и количество спален.
- Неоднозначные совпадения никто не будет разбирать. Удержание на проверку работает только тогда, когда в очередь кто-то смотрит.
- Вам нужен поиск по всему порталу. Здесь его тоже нет, и строить вокруг него — значит строить на нарушении условий.
На чём это работает
| Компонент | Версия | Зачем |
|---|---|---|
| Cloudflare Workers | current | Скачивание каждого фида по расписанию, дедупликация и подбор. |
| Cloudflare D1 | current | Объединённые объекты, записи об источниках и очередь на проверку. |
| Cloudflare R2 | current | Снимки по каждому фиду хранятся для сравнения и разбора расхождений. |
| Zod | 4.4 | Валидация записей фида, форма которых у порталов различается. |
Вопросы, которые возникают при оценке
Почему нельзя дедуплицировать по идентификатору объявления?
Потому что каждый портал выдаёт свой идентификатор и между собой они не соответствуют. Сопоставление по идентификатору гарантирует, что каждый объект с двойным размещением будет считаться двумя, — а это ровно тот сбой, который покупатели замечают первым.
Из чего складывается составная идентичность?
Из признаков, одинаковых в обоих фидах: здание или район, номер квартиры, где он есть, количество спален, площадь и ценовой диапазон. Сильным вторичным признаком служит разрешение RERA — у одного и того же объекта на обоих порталах оно совпадает.
Что делать, когда два фида расходятся в цене?
Побеждает запись, обновлённая последней, а расхождение пишется в журнал. Изменение цены подтверждается по тому же источнику до отправки уведомления, чтобы покупателям не сообщали о снижении, которое на деле является отставанием синхронизации.
Стоит ли дожидаться обоих фидов перед отправкой уведомления?
Нет. Один фид обычно опережает другой на минуты или часы, а весь смысл — в скорости до покупателя. Уведомляйте по первому появлению и записывайте, из какого фида объект пришёл, чтобы позднейшее расхождение поддавалось объяснению.
Что будет, если две разные квартиры склеятся в одну?
Это хуже, чем показать две записи: ошибочно склеенный объект становится невидимым для всех покупателей, которые его ищут. Поэтому неоднозначные совпадения уходят на проверку агентом, а не разрешаются угадыванием.
Как мы узнаем, что один из фидов встал?
По отдельным оповещениям о залежавшихся данных для каждого фида. Без них вставший фид выглядит как тихий рынок, а пропавшие объекты обнаруживаются в тот момент, когда покупатель спрашивает об объявлении, увиденном на другом портале.
Что почитать дальше
Вторая половина типичной дубайской схемы с двумя порталами — интеграция с Property Finder.
Бот, который работает на этих фидах, — сборка бота по недвижимости.
Превращение уведомления в просмотр разобрано через сборку бота записи.
Остальные системы, которых обычно касается бот агентства, собраны в полном списке интеграций.