Цена пересчитывается по спросу и конкуренту

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

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

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

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

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

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