Чтобы оценить рекламу отеля по бронированиям, нужны две связанные записи: действие посетителя на сайте и результат в системе бронирования или журнале менеджера. Минимальный набор — источник перехода, принятое обращение, идентификатор брони и её текущий статус. Если связать записи нельзя, показывайте их раздельно: количество целей в Метрике не заменяет количество подтверждённых броней.
Эта схема подходит владельцу небольшого отеля и управляющему, которому нужно понять, где теряются обращения. У городского отеля с онлайн-оплатой и загородного объекта, где пакет согласуют по телефону, цепочка будет разной. Не настраивайте одинаковую воронку только потому, что оба объекта продают проживание.
Сначала определите, что считается результатом
Договоритесь с отделом бронирования о трёх понятиях.
Обращение — принятая заявка, состоявшийся звонок или полученное сообщение. Нажатие ссылки на телефон показывает намерение позвонить, но не подтверждает разговор. Переход в мессенджер тоже не доказывает отправку сообщения.
Подтверждённая бронь — запись с идентификатором и согласованным статусом в системе бронирования. Уточните, считается ли подтверждением резерв номера, поступление предоплаты или другой этап. Не называйте резерв оплаченным проживанием.
Результат после отмен — брони или заезды с учётом актуальных статусов. В отчёте нужны дата среза и правило обработки возвратов. Сумма подтверждённых броней, полученная оплата и выручка за состоявшееся проживание — разные показатели.
Для санатория обращение может потребовать дополнительного согласования, а для группового заезда — расчёта предложения. Эти этапы лучше записать отдельно, иначе длительная сделка будет выглядеть как потерянная заявка.
Разведите открытие модуля и начало бронирования
Названия событий ниже — пример для технического задания, а не стандарт Метрики. Каждому событию нужно задать условие срабатывания и проверить его на вашем сайте.
| Событие | Что подтверждает | Чего не подтверждает |
|---|---|---|
| phone_click | Нажатие ссылки на номер | Звонок, разговор и заявку |
| messenger_click | Нажатие ссылки на канал связи | Полученное сообщение |
| lead_form_submit | Сервер принял заявку и создал запись | Доставку уведомления менеджеру и бронь |
| booking_module_open | Модуль открылся | Выбор дат или номера |
| booking_start | Гость сделал первый согласованный шаг: например, запустил поиск по датам | Подтверждение брони |
| booking_confirm | Система создала бронь с уникальным ID и нужным статусом | Оплату и состоявшийся заезд, если они ещё не наступили |
Если модуль не передаёт начало выбора, оставьте только измеряемое открытие. Не переименовывайте его в «начатое бронирование» ради полной на вид воронки.
Для собственных онлайн-событий Метрика поддерживает метод reachGoal; условие цели и вызов на сайте должны соответствовать друг другу. Это описано в инструкции по целевым событиям. Для формы выбирайте момент успешной обработки, а не просто нажатие кнопки: иначе ошибки валидации попадут в заявки. Отдельно проверяйте, дошло ли уведомление до отдела бронирования.
Сохраните источник вместе с обращением
Для рекламных, партнёрских и социальных ссылок используйте согласованную UTM-разметку. Зафиксируйте допустимые значения utm_source, utm_medium и порядок названий кампаний, чтобы один канал не распался на несколько строк.
В записи обращения полезно сохранить посадочную страницу, доступные UTM-метки, реферер, время и технический идентификатор для сопоставления. Если требуется связать результат из CRM с визитом Метрики, проверьте возможность сохранения ClientID: Яндекс описывает его использование в импорте офлайн-данных.
Идентификатор может отсутствовать: например, счётчик не загрузился или обращение пришло по телефону без связи с визитом. При этом UTM-метки в записи заявки могут сохраниться. Разделяйте два признака: «источник установлен» и «есть привязка к визиту Метрики». В группу «источник не установлен» относите только обращения, для которых нет подтверждённых сведений об источнике. Не распределяйте их по каналам пропорционально известным заявкам — это расчётное допущение, а не восстановленные данные.
Не передавайте имена, телефоны, email, паспортные данные или содержание медицинских обращений в URL и произвольные параметры событий. Для конкретной интеграции используйте предусмотренные поля и отдельно проверьте правила обработки данных. Журнал аналитики не должен становиться копией анкеты гостя.
Если бронирование происходит в отдельном виджете или домене
Уточните у поставщика модуля, какие события и идентификаторы он отдаёт. Сам по себе переход с сайта в модуль не гарантирует сквозного отслеживания.
Для технического задания достаточно пяти вопросов:
- Сохраняются ли источник и технический идентификатор при переходе в модуль?
- Можно ли отличить открытие от первого шага выбора?
- Как получить подтверждение с ID брони — через готовую интеграцию, API или выгрузку?
- Как поступают изменения статуса, отмены и возвраты?
- Кто сверяет данные модуля с системой управления отелем — PMS?
Страница «Спасибо» может помочь в измерении, но не заменяет проверку брони в операционной системе. Её могут открыть повторно; данные могут не отправиться из-за блокировки счётчика. Поэтому защиту от повторного учёта результата стройте вокруг ID брони и правил выбранной интеграции, а не вокруг количества просмотров страницы.
Если используется электронная коммерция Метрики, событие покупки имеет собственный формат и идентификатор заказа; он показан в документации передачи ecommerce. Не подменяйте проверку этого механизма произвольной целью booking_confirm и не складывайте оба события как две продажи.
Проверьте события до сравнения каналов
Тест должен включать успешный и неуспешный сценарии. Используйте согласованную тестовую среду или заранее отмеченные тестовые записи, не создавая случайные брони в рабочем номерном фонде.
| Проверка | Ожидаемое поведение |
|---|---|
| Отправить форму с неверно заполненным обязательным полем | Событие принятой заявки не появляется |
| Отправить корректную форму | Создана одна запись обращения; проверены событие и уведомление менеджеру |
| Открыть модуль и уйти без выбора | Зафиксировано открытие, но не подтверждение брони |
| Выполнить согласованный первый шаг выбора | Сработал booking_start, если модуль его поддерживает |
| Создать тестовую бронь и повторно открыть подтверждение | В операционном отчёте остаётся одна бронь по её ID |
| Изменить статус тестовой брони на отменённую | Сводка броней показывает актуальный статус; отдельные цели сайта не выдаются за итог после отмен |
После теста сравните несколько реальных записей: время обращения, источник, ID и статус брони. Письмо из формы, событие в Метрике и запись в CRM относятся к разным системам; наличие одного не доказывает наличие остальных.
Что показывать управляющему каждую неделю
Не складывайте звонки, формы и сообщения в «уникальных гостей», пока не настроено объединение обращений. Один человек может написать, позвонить и оставить форму по одной поездке. Сохраняйте отдельные числа обращений и броней, а правило объединения описывайте рядом с отчётом.
| Участок | Показатель | Решение, которое помогает принять |
|---|---|---|
| Реклама и поиск | Визиты, источник, кампания, посадочная страница | Какой спрос и предложение проверить |
| Сайт | Принятые формы, открытия модуля, доступные шаги выбора | Где проверить форму или путь бронирования |
| Отдел бронирования | Принятые обращения, время ответа, причины отказа | Какие обращения зависли и что мешает ответу |
| Брони | Уникальные ID, статус, сумма, отмены | Какие каналы связаны с подтверждённым результатом |
Укажите период, дату среза и модель атрибуции. Один посетитель мог сначала прийти из поиска, затем вернуться по рекламе. Сравнение первого источника с последним даст разные результаты; это не повод менять модель от недели к неделе под удобный вывод.
Отдельно показывайте долю броней с известным источником. Если значительная часть не сопоставлена, рейтинг каналов по подтверждённым броням отражает только связанный сегмент, а не все продажи отеля.
Как не ошибиться со стоимостью бронирования
Учебный пример: на одну кампанию потратили 30 000 ₽. С ней сопоставлены 20 уникальных подтверждённых броней, из которых к дате отчёта четыре отменены. Расход на одну первоначально подтверждённую бронь — 1 500 ₽; на одну из 16 броней без отмены на эту дату — 1 875 ₽. Это ещё не стоимость состоявшегося заезда: часть гостей может отменить поездку позже.
Рядом с расчётом подпишите, что в расход входят только рекламные затраты, а работа подрядчика и другие расходы не включены. Не называйте результат прибылью или окупаемостью. Для такого вывода нужны сопоставимые данные о доходе и составе затрат.
Брони должны относиться к выбранной группе обращений: расходы одной недели и все заезды этой недели могут описывать разных гостей. У загородного отеля или санатория решение иногда принимают заранее, поэтому группе обращений нужно дать время дойти до результата.
Если данных достаточно для анализа рекламного спроса, сопоставьте эту схему со структурой кампаний Директа для отеля. А проверку посадочной страницы начните с страниц сайта, помогающих выбрать номер и забронировать.
Для первого рабочего отчёта выберите один путь: например, реклама → принятая форма → ответ менеджера → бронь. Проверьте его на отдельных записях и только затем расширяйте измерение. Так ошибка в одном событии не превратится в ложный вывод о работе всего маркетинга.