Маркетинговые воронки часто строятся из нескольких отдельных сервисов:
- Основной сайт:
company.com(WordPress или кастомный стек). - Промо-страница акции:
promo.company.tilda.wsили поддомен. - Лид-квиз:
quiz.marquiz.ru/company-quiz. - Витрина или чекаут:
shop.partner-platform.com.
Для маркетолога этот подход удобен, потому что посадочные страницы запускаются за два дня без программистов.
Для систем аналитики (Яндекс Метрики, Google Analytics 4, Meta Pixel) смена хоста приводит к сбросу сессии. Как только посетитель переходит с одного домена на другой, цепочка данных разрывается.
1. Что происходит при переходе между доменами
Браузерная безопасность работает по правилу Same-Origin Policy. Браузер запрещает сайту domain-b.com читать куки и локальные данные сайта domain-a.com.
Пользователь кликает по рекламе ➔ Заходит на company.com (UTM-метки, Client ID зафиксированы)
│
▼ Клик по кнопке «Пройти квиз»
[Внешний домен quiz-platform.com] ◄───────────┘
│
├── ❌ Cookies основного сайта company.com недоступны
├── ❌ Исходный Client ID потерян
└── ❌ Счетчик фиксирует новый визит с источником Direct или Referral
Когда человек переходит с основного сайта на конструктор или сторонний квиз:
- Обнуляются cookies и сессии: сторонний сервис не видит куки основного домена.
- Создается дубль пользователя: система аналитики создает нового пользователя с новым Client ID.
- Ломается источник трафика: вместо рекламы в отчетах появляется источник
Referral(переход с вашего же сайта) или прямой заход (Direct). - Теряется сквозная атрибуция: деньги на рекламу списаны, но заявки с квиза попадают в категорию неизвестного источника.
2. Изоляция хранилищ: Cookie Partitioning (CHIPS)
Раньше маркетологи встраивали квизы и формы через <iframe> или сторонние трекинговые cookies (3rd-party).
Браузеры Chrome, Safari и Firefox закрыли этот механизм через технологию CHIPS (Cookies Having Independent Partitioned State).
Механика работы CHIPS:
Браузер привязывает куки к связке (Основной сайт + Встроенный фрейм).
- Куки, сохраненные внутри фрейма на
company.com, изолируются. - Если пользователь позже откроет страницу
quiz-platform.comнапрямую, браузер отдаст пустой контейнер. - Сквозное отслеживание через сторонние фреймы перестало работать на уровне браузера.
3. Почему стандартные способы не решают задачу
| Способ решения | В чем суть | Причина сбоев |
|---|---|---|
Параметры _gl (GA4 Linker) |
Дописывает Client ID в исходящую ссылку | Ссылки выглядят подозрительно, блокировщики вырезают параметры, а редиректы стирают query strings. |
| JS-скрипты проброса UTM | Подставляет параметры в скрытые поля формы | При переходе по внутренним страницам или обновлении вкладки метки теряются. |
| Referral Exclusion List | Исключение своих доменов из источников перехода | Скрывает факт перехода в отчете, но не восстанавливает связь сессий и cookies. |
4. Решение: ко-локация через Edge Reverse Proxy
Способ сохранить атрибуцию — оставить пользователя в рамках основного домена на всем пути.
Вместо перехода на promo.company.tilda.ws или сторонний квиз страницы открываются по адресам company.com/promo и company.com/quiz.
Пользователь открывает: company.com/promo
│
▼
[Edge Reverse Proxy Sply]
│
├── Маршрут: путь /promo направлен на Tilda
├── Запрашивает HTML с сервера конструктора
├── Перезаписывает заголовки и куки под company.com
└── Отдает страницу пользователю за 30 мс
Преимущества ко-локации:
- Единый домен: конструкторы, квизы и витрины работают под адресами
company.com/*. - Непрерывные 1st-party cookies: все счетчики и пиксели видят единый контекст визита.
- Доверие пользователей: посетители остаются на брендовом домене без сторонних переходов.
- Сохранение SEO-веса: переходы и ссылки усиливают ваш основной домен, а не адрес стороннего конструктора.
Следующий шаг
Внедрите Server-Side Tracking без сложного кода
Sply восстанавливает до 30% потерянных конверсий, защищает от Safari ITP/AdBlock и ускоряет загрузку ваших лендингов.