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

- Страница: https://attribution-lab.nexusnode.ru/ru/cases/cross-domain-journey/
- Статус: есть в демо
- Сервисы: GA4, GTM, sGTM, Google Ads
- Обновлено: 2026-09-21
- На английском: https://attribution-lab.nexusnode.ru/cases/cross-domain-journey.md

## В чём проблема

Реклама ведёт на один сайт, а бронь или покупка происходит на другом: на сайте партнёра, на сайте другого города, на платформе бронирования. В отчётах такая бронь приходит как «direct» (посетитель пришёл сам) или как «переход с сайта», и реклама, которая её привела, не получает ничего.

Пример. За месяц реклама привела 100 броней, но 40 из них оформлены на другом сайте. В Google Ads видно 60. Реклама учится на 60, отчёт показывает результат почти вдвое хуже настоящего, и бюджет режут в кампании, которая приносит брони. Пропадают именно брони тех, кто прошёл через несколько сайтов, то есть самых заинтересованных.

**Легенда демо:** сеть турагентств во Вьетнаме. У сети есть сайт бренда, каждый город – отдельная франшиза со своим сайтом, своим рекламным бюджетом, своим GTM и своей отчётностью, а бронирование завершается на внешней платформе, где наших тегов нет. Все три бизнеса вымышленные.

## Что теряет бизнес

- **Идентификатор рекламы теряется на переходах.** Google Ads и Meta оптимизируются под конверсии, которые видят. Бронь, не вернувшаяся в рекламную платформу, для назначения ставок не существует.
- **В аналитике источник продаж – direct.** Бронь приходит как «direct» или как переход с сайта сети. В отчётах реклама франшизы выглядит бесполезной, и её бюджет режут первым.
- **Две точки зрения, обе верные.** Для владельца сети клиент, который кликнул рекламу Дананга и забронировал в Нячанге, – всё равно продажа. Для франшизы в Дананге – потерянный бюджет. А клиент, который ушёл из Дананга, погулял по сайтам сети и вернулся в Дананг, – дырка для обоих: реклама, которая его нашла, не получает ничего, а алгоритм ничему не учится.

## Чем это закрывается

| Вариант | Плюсы | Минусы | В демо |
| --- | --- | --- | --- |
| **Один тег Google на всех доменах** (кросс-доменная связка GA4) | Официальный путь: Google сам переносит идентификатор посетителя между вашими доменами внутри ссылки. | Нужны одна property (аккаунт аналитики) и один владелец на все домены. Но такое доступно не всегда. В вымышленном примере две франшизы – это два разных собственника со своими property, связка не применима. С платформой бронирования, куда тег не поставить, данный подход не помогает вовсе. | только описание |
| **Подписанная передача пути между сайтами** | Каждый сайт держит свой контейнер и свою property. Первый сайт просит у нашего сервера одноразовый код и добавляет его в ссылку; второй сайт обменивает код на путь и ставит свою cookie. Две cookie, две property, один путь. | Свой сервер и запись пути на нём. Код выдаётся только тогда, когда это разрешает согласие. | есть в демо |
| **Ссылка на источник трафика внутри брони**, которую платформа возвращает вебхуком (автоматическим уведомлением на ваш сервер) | Надёжно: подтверждённая бронь приходит назад с кодом пути. | У платформы должно быть поле под неё. У Checkfront, Regiondo и Bokun такое поле есть; FareHarbor прямо пишет, что через параметры и cookie ничего передать нельзя. Проверяется по каждой платформе, такая возможность есть не всегда. | есть в демо |
| **Редирект назад на страницу «спасибо»** | Просто. Страница «спасибо», у которой есть наша cookie, прикрепляет бронь. | Только если платформа умеет вернуть посетителя на ваш домен с id брони. До этой страницы посетитель может и не дойти. | есть в демо |
| **Виджет платформы на своём домене** (окно платформы внутри вашей страницы, которое отдаёт событие) | Посетитель не меняет домен, но форму бронирования по-прежнему рисует платформа: вы вставляете её виджет и получаете от него сообщение «бронь создана». | Ломается, когда виджет сидит в окне внутри другого окна или когда до него не доходит состояние согласия. Событие приходит, только если платформа его отдаёт. | есть в демо |
| **Бронь через API платформы** со своего сайта | Форма ваша, платформа только принимает данные: ваш сайт сам создаёт бронь через программный интерфейс платформы, и посетитель не видит платформу вовсе. В отличие от виджета, вы управляете и формой, и тем, какие данные уходят в платформу. | Разработка на вашей стороне. Не у каждой платформы есть такой интерфейс. | есть в демо |
| **Сопоставление по времени, туру и цене**, когда платформа не возвращает ничего | Работает, когда платформа не даёт ничего. | Это предположение, и демо помечает его как предположение: статус INFERRED, уверенность ниже 1.00, один клик привязывается максимум к одной брони. | есть в демо |

## Что сделано в демо

Демо хранит одну запись пути на своём сервере. Сайт A (сеть) передаёт путь сайту B (франшиза) одноразовым подписанным кодом. Сайт B несёт код пути в платформу бронирования как ссылку. Платформа отправляет вебхук с этой ссылкой, и бронь привязывается к пути: метод `booking_reference`, уверенность 1.00, статус LINKED (связано). Остальные четыре поведения платформы включаются одним переключателем, так что их можно сравнить на одном и том же пути.

Согласие решает, случится ли всё это вообще. В режиме opt-out (США и большая часть мира) путь создаётся сразу. В режиме opt-in (ЕС, Великобритания, Швейцария) до согласия ничего не сохраняется и код не выдаётся. Отказ – и ссылка перехода объясняет причину: «Токен передачи не выдан: согласия не было, поэтому межсайтовый идентификатор не передаётся».

## Открыть демо

Демо открывается уже настроенным под этот кейс, с серверным транспортом. Шаги ниже описаны для перехода из Google Ads – он выбран по умолчанию. Для чистого прогона откройте демо в приватном окне: режим и транспорт запоминаются браузером.

- [Авто – режим по вашему местоположению](https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_cross_domain&demo_click_id=GADS-11111&al_case=cross-domain-journey&al_lang=ru&al_transport=server&al_regime=auto)
- [Принудительно США – opt-out](https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_cross_domain&demo_click_id=GADS-11111&al_case=cross-domain-journey&al_lang=ru&al_transport=server&al_regime=us)
- [Принудительно ЕС – opt-in](https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_cross_domain&demo_click_id=GADS-11111&al_case=cross-domain-journey&al_lang=ru&al_transport=server&al_regime=eu)

Что вы увидите:

1) **Сайт A, сеть.** Откройте панель кнопкой «Показать, что записано» внизу экрана. Панель показывает KNOWN (источник известен): первое касание `google / cpc`, исходные значения `GAds / CPC` сохранены рядом с нормализованными, click id `GADS-11111 (демо)`.
2) **Перейти на сайт города.** Открывается сайт B со статусом LINKED (путь связан), «Путь продолжен с alpha», визит #2 и список того, что пережило смену домена: источник, кампания, исходная метка времени, отдельная property GA4, отдельный контейнер GTM.
3) **Забронировать тур.** Над турами выберите, что платформа делает со ссылкой: API, «Ссылка в брони», «Виджет», «Возврат на сайт», «Без сигнала». Подтвердите бронь на хосте платформы, где нет ни одного нашего тега. Вернувшись на сайт, откройте панель, если она закрыта: на вкладке «Путь» видно, как бронь привязана: `booking_reference 1.00 LINKED`, или `probabilistic 0.80 INFERRED` (предположение) с расписанным правилом, или UNKNOWN (связь потеряна).
4) **Вкладка «Данные».** Каждый ключ, который демо пишет в ваш браузер, и кто его поставил. Два из них, `FPID` и `FPLC`, ставит серверный контейнер на родительский домен, поэтому браузер несёт их и на хост бронирования, который их не читает и не ставит. Демо показывает это в таблице как есть.

## Кадры

![Сайт B: путь продолжен с сайта A](https://attribution-lab.nexusnode.ru/assets/case/a02-beta-linked.png)
*Сайт B после передачи: свой контейнер и своя property, тот же путь, первое касание сохранено.*

![Бронь привязана по ссылке](https://attribution-lab.nexusnode.ru/assets/case/a05-conversions.png)
*Бронь, привязанная по ссылке, которую платформа вернула вебхуком: надёжно, 1.00.*

## Чего демо не доказывает

- Что ваша платформа бронирования примет и вернёт ссылку. Это проверяется по документации и настройкам платформы, для каждого вендора отдельно.
- Что источник доезжает до Google Ads. Демонстрационный click id – свидетельство клика, в Google Ads он не отправляется; проверка настоящего `gclid` требует живой кампании.
- Что идентификатор переживает недели в любом браузере. Демо ставит cookie с сервера, и это делает идентификатор долговечнее скриптового; длительные тесты в браузерах – отдельный шаг.

## Кто это сделал

Антон Кожанов – инженер маркетинговых данных и атрибуции. Свой серверный Tag Manager на своей инфраструктуре, first-party загрузчик и cookie, хранилище пути с выгрузкой и удалением. Четыре года на измерении театра (выручка ×2,3 за время ведения, доля рекламы около 7% выручки) и конвейер коллтрекинг → CRM → реклама для производственной компании (стоимость лида −25%, минимум за 2,5 года).

## Договориться о созвоне

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

Форма: слот в календаре · ваш сайт или платформа бронирования · где вы замечаете разрыв · как с вами связаться.