# Лендинг и форма на разных доменах: как проверить источник обращения

Как проверить переход между доменами, сохранение источника и связь обращения с маршрутом. Учебный протокол для нового и повторного визита

Автор: Редакция KEIVO
Дата публикации: 2026-11-04
Канонический URL: https://keivo.ru/blog/mezhdomennoe-otslezhivanie-yandeks-metrika/

![Маркер источника проходит между двумя доменами и сохраняется у формы](/blog/_media/lg50-20261103/a31-cover-w960-354caa92a463.webp)



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

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

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

В примере используются зарезервированные учебные адреса, условные кампании и записи. Это не реальные клиентские данные и не результат рекламы KEIVO. Мы не обещаем универсальное склеивание посетителей разных сайтов: проверяем конкретный путь и его пределы

## Нарисуйте не дизайн страницы, а границу систем

Запишите полный адрес лендинга A и адрес места, где фактически заполняется форма B. Затем найдите систему, в которой хранится окончательная запись Q. Иногда форма показана внутри лендинга, но её содержимое и обработка принадлежат внешнему домену. Внешний вид одного экрана не делает системы одной

Отдельно укажите, кто может менять код A, настройки B и интеграцию получателя. Если за каждую часть отвечает другая команда, нужен общий способ подтверждения. Исполнитель лендинга не должен обещать сохранение поля, которое внешний сервис вообще не поддерживает

Сначала достаточно простой схемы: «A показывает предложение; B собирает данные; система C получает запись». Между стрелками подпишите фактическую операцию: переход по ссылке, iframe, запрос формы, webhook или ручная выгрузка. Не объединяйте всё словом «интеграция»

Проверьте адреса без лишних чувствительных параметров. В общей схеме не нужны секретные ссылки администратора, ключи API и персональные сведения. Она должна объяснять устройство пути, а не открывать доступ к системам любому читателю

Если система C совпадает с B, так и запишите. Если после формы результат идёт ещё в почту или CRM, у этой связи свой участок. Для задачи источника важно не потерять контекст до того места, где бизнес действительно увидит обращение

## Сформулируйте, какой источник вы хотите знать

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

Для начала напишите вопрос бизнеса: «По какой принятой метке мы связываем конкретное полученное обращение с переходом с A?» Это уже другая задача, чем «сколько раз нажали внешнюю кнопку». Для первой нужна связь с записью Q, для второй достаточно наблюдения действия на A в своей области

Если вы хотите также единый путь посетителя в Метрике, это отдельный проверяемый результат. Техническая связь контекста с записью не доказывает, что разные браузерные идентификаторы стали одним человеком или одним визитом. Не подменяйте один успех другим

Зафиксируйте правило выбора, если человек приходит несколько раз. Нужен первый вход, последний известный переход, источник конкретной попытки или другое принятое основание? Без этого даже правильно сохранённые поля могут дать спорный ответ

В учебном примере проверяется источник конкретной попытки формы по договорённому контексту A. Это не универсальная модель всех рекламных касаний. Она нужна, чтобы объяснить, что действительно можно установить из доступных данных

## Различайте домен, origin и область браузерного хранения

Для браузера важен не только похожий адрес. Origin определяется схемой, хостом и портом. Это объясняет [политика одного источника MDN](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy). Разные поддомены уже могут быть разными origin, даже когда принадлежат одной компании

При этом область cookies и область localStorage устроены не одинаково. У cookies могут быть свои настройки домена и другие ограничения. LocalStorage относится к origin документа. Нельзя обещать, что запись, сделанная скриптом на A, автоматически доступна коду внешнего B

Практический вывод для владельца: фраза «мы сохраним UTM в браузере» описывает только первый участок. Попросите показать, каким разрешённым способом контекст попадёт к получателю B. Если ответ сводится к одинаковому названию ключа localStorage на двух сайтах, связь ещё не объяснена

Не пытайтесь убрать браузерные ограничения, чтобы читать чужой iframe. Не отключайте защиту сайта и не расширяйте доступ к личным данным ради удобства аналитики. Если сервис предоставляет интеграцию, используйте её документированный механизм с понятной областью

В рабочей карте этот пункт можно сформулировать без сложной терминологии: «У A и B разные области кода и хранения; нужен явный поддерживаемый перенос». Этого достаточно, чтобы не принять обещание, основанное только на визуальной близости формы

## Один счётчик на двух сайтах ещё не закрывает весь путь

В [настройках Метрики](https://yandex.ru/support/metrica/ru/general/counter-general) можно указать дополнительные адреса, а переходы между заданными адресами считаются внутренними. Это полезная настройка соответствующей области счётчика. Но она не является универсальным доказательством, что запись формы B получила нужный контекст A

Установка одного номера на нескольких адресах решает не все вопросы сама по себе. Нужно знать, где код разрешён, когда он загружается, какие события видны, какие браузерные условия действуют и что сохранено у получателя. Если на B нельзя установить код, такое обещание тем более требует другой схемы

Не проверяйте успех по одному исчезнувшему внешнему рефереру в отчёте. Вид источника мог измениться из-за настроек, но бизнес-запись всё ещё не иметь признака кампании. Критерий должен относиться к тому результату, который вы заявили в начале

Если задача — единая аналитическая история, попросите показать её на согласованном тесте и сохранить ограничения. Если задача — контекст в карточке обращения, проверяйте карточку и предусмотренную связь. Эти две проверки могут дать разные статусы

Честный итог может выглядеть так: «Оба адреса приняты счётчиком, переход наблюдается, связь с Q не подтверждена». Это полезнее общей надписи «междоменное отслеживание настроено», за которой не видно ни одной конкретной приёмки

## Не рассчитывайте, что Referer перенесёт все метки

При переходе браузер может передать сведения о предыдущей странице, но их состав зависит от политики и условий. Для распространённой политики strict-origin-when-cross-origin междоменный переход передаёт origin без полного пути и строки запроса. Это описано в [документации Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)

Поэтому B не обязан получить UTM из адреса A только потому, что посетитель нажал ссылку. Он может увидеть домен, сокращённый контекст или вовсе не получить реферер в конкретных условиях. Реферер также не является надёжным доказательством сохранённого обращения

Не ослабляйте политику передачи адресов на всём сайте только ради сохранения рекламной строки. В URL могут находиться сведения, которым не стоит уходить во внешний сервис. Лучше определить минимальный нужный набор и предусмотренный способ его передачи

В тесте фиксируйте, что фактически доступно B, если у вас есть разрешённый доступ к этой области. Не придумывайте полную строку A по одному домену. Если известен лишь переход с сайта, результат так и называется: «реферер A», а не «точно кампания C1»

Для выбранной задачи источник должен сохраняться намеренно, а не случайно зависеть от того, какие заголовки пришли в одном браузере. Даже при удачном первом тесте повторите существенные условия, которые действительно будут у ваших посетителей

## Разберите обычный переход и встроенную форму отдельно

У обычного перехода посетитель открывает адрес B в текущей или новой вкладке. Нужно проверить саму ссылку, возможные перенаправления и то, какие поддерживаемые параметры B принял и сохранил. Наличие метки в адресной строке ещё не означает её попадание в запись Q

Встроенная форма может быть iframe внешнего происхождения. Родительская страница A не получает свободный доступ к его полям и состоянию только потому, что он занимает часть экрана. Ограничения браузера остаются, а взаимодействие должно быть предусмотрено владельцем B

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

| Способ | Где искать связь | Чего не обещать по внешнему виду |
|---|---|---|
| Переход A→B | Адрес, поддерживаемый контекст и запись B | Что все метки сохранились автоматически |
| Iframe B внутри A | Документированный обмен/интеграция B | Что A может читать чужие поля |
| Своя форма с внешней доставкой | Ответ обработчика и запись получателя | Что успешное нажатие равно доставке |
| Ручная передача после формы | Принятая выгрузка и поля источника | Что связь восстановится по времени |

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

## Составьте список доступов и возможностей

Для A нужен участник, который понимает адреса, ссылки и код страницы. Для B — человек, который может подтвердить поддерживаемые поля и интеграции. Для конечного получателя — тот, кто увидит запись с допустимыми данными. Иногда это один человек, но роли всё равно полезно различать

Не запрашивайте административный доступ к целому чужому сервису, если достаточно просмотра настроенного поля или обезличенной записи. Опишите действие, которое нужно проверить. Внешняя платформа может иметь свои ограничения по ролям и тарифам; неизвестное не должно превращаться в обещание исполнителя

Проверьте, может ли B сохранять произвольный контекст, экспортировать его, возвращать подтверждение и передавать данные дальше. Для каждой возможности нужно фактическое описание или безопасная проверка. Скриншот похожего сервиса не доказывает функции вашего продукта

Если документация закрыта, попросите владельца B дать нужный ответ в рабочем канале. Вопрос должен быть конкретным: какое поле можно передать, где оно появляется, как узнать об ошибке и как связать результат. Формулировка «поддерживаете ли аналитику» слишком широкая

Отметьте ограничения до покупки или изменения всей схемы. Возможно, для выбранной задачи достаточно своего обработчика, либо внешняя форма подходит только при частичном измерении. Выбор инструмента должен учитывать этот предел, а не скрывать его после запуска рекламы

## Выберите уровень результата, который реально достижим

Есть как минимум три полезных уровня. Первый: известен переход с A на B, но нет связи с записью. Второй: в записи Q сохранён принятый контекст попытки. Третий: дополнительно подтверждена требуемая аналитическая связь в системе измерения. Они не складываются автоматически в один «полный» уровень

Для малого бизнеса второй уровень иногда важнее сложного общего графика: обработчик видит, к какому предложению или принятой метке относится конкретный запрос. Но не выдавайте это за точный путь человека через все устройства и источники

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

Запишите выбранный уровень в брифе и критериях. Тогда проверка не завершится спором, почему заказчик ожидал весь путь в одном отчёте, а исполнитель сделал только событие на внешней кнопке

В учебном примере после исправления принимается контекст конкретной попытки в записи B. Единый идентификатор посетителя и вся атрибуция Метрики остаются за пределами доказанного. Это не недосказанность, а обозначенная область задачи

## Договоритесь о минимальном контексте

Контекст должен отвечать выбранному вопросу и быть поддержан B. Это может быть обозначение предложения, согласованная категория источника или техническая ссылка на запись контекста у вашей системы. Конкретный формат выбирается по возможностям, а не копируется из соседней статьи

Не отправляйте все параметры входного URL без разбора. В нём могут оказаться случайные или чувствительные значения. Заранее перечислите допустимые поля, их назначение и ограничения. Всё остальное не должно попадать во внешний сервис только потому, что его легко скопировать

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

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

Укажите, что происходит без контекста. Форма может принять обращение с источником «не установлен», если это соответствует задаче. Отсутствие метки не должно превращаться в ложную кампанию по умолчанию, которая делает общий отчёт убедительнее

## Опишите контракт передачи до изменения кода

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

Укажите формат и допустимые значения, поведение при отсутствии, ошибке и повторе. Если предполагается преобразование названий, запишите его явно. Иначе «campaign» в одной системе и «источник» в другой будут выглядеть связанными, хотя сохраняют разные вещи

| Поле контракта | Учебная запись |
|---|---|
| Создатель | Принятая точка перехода на A |
| Передаваемый контекст | CX1 для согласованного теста, без контактов |
| Приёмник | Поддерживаемое поле B, подтверждённое владельцем сервиса |
| Сохранение | В записи Q, затем в согласованной выгрузке/карточке |
| Нет значения | Источник не установлен, не автоматическая C1 |
| Неверное значение | Отмечено как непроверенное, не принято за подтверждение |
| Повтор | Не создаёт новую задачу без принятого бизнес-основания |
| Проверка | T01/T02, запись и контекст сопоставлены фактически |

Не выдавайте этот образец за готовое имя поля любого конструктора. CX1 и поддерживаемое поле B существуют в учебной модели. Реальный сервис должен подтвердить собственный способ, а разработчик — реализовать его по документации и условиям проекта

## Проверьте путь контекста по одному участку

Начните с A: какой контекст доступен после входа и каким правилом выбран? Затем проверьте подготовленную ссылку или разрешённое действие перехода. После этого исследуйте, что B действительно принял. Не перескакивайте от красивой метки на A сразу к выводу о карточке Q

Если контекст передаётся через URL, проверьте кодирование и допустимые параметры B. Наличие пробелов, разделителей или дополнительных перенаправлений может изменить получившееся значение. Но не надо перебирать случайные параметры внешней формы: используйте только поддерживаемый способ

Если он передаётся сервером, в браузер не выносят секреты API. Получатель должен знать, какой вызов пришёл и как его подтвердить в согласованной области. Статья не заменяет проектирование авторизации и защиты интеграции

Важный результат каждого участка — ожидаемое значение и фактическое. Если на переходе CX1 уже потерялся, сначала исправляется этот участок. Не надо искать проблему в отчёте Метрики, пока B вообще не получил необходимый контекст

При этом успешный перенос до B ещё не закрывает сохранение. У системы может быть временное отображение параметра, которое не попадает в экспорт. Поэтому следующий шаг всегда связан с фактической записью, которую получит бизнес

## Проверьте сохранение в самой записи, а не только в URL

Выполните одно согласованное тестовое обращение и найдите его у получателя. Сверьте номер, время и допустимую тестовую отметку. Затем посмотрите, где находится контекст: отдельное поле, журнал интеграции или предусмотренная связь с другим объектом

Если в адресной строке B был CX1, а в Q поле пустое, передача ещё не принята. Причина может быть в неподдержанном параметре, неправильном имени, фильтре сервиса или настройке выгрузки. Не заполняйте пропуск вручную и не выдавайте это за исправленную автоматическую связь

Проверьте не только интерфейс оператора, но и тот способ, которым команда будет работать ежедневно. Если обработчик получает email без источника, а поле видно только администратору B, фактическая задача бизнеса может оставаться незакрытой

Сохраните минимальное подтверждение: запись Q01 содержит CX1, а конечная карточка или выгрузка сохраняет ту же связь. Личные данные для общего листа не нужны. Внутренние номера должны использоваться в пределах принятых доступов и хранения

Если просмотр записи недоступен, попросите ответственного подтвердить конкретное поле. Его сообщение — отдельный вид свидетельства, с понятной областью. Нельзя приписать себе самостоятельную проверку базы, если вы видели только пересказ результата

## Для iframe используйте предусмотренное взаимодействие

Если B встроен в iframe, сначала выясните, предоставляет ли сервис сообщения о состоянии или другой поддерживаемый интерфейс. Без этого родительская A может знать только, что виджет загружен или что на внешнюю область был направлен пользователь, но не факт сохранения обращения

[postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) позволяет организовать обмен между окнами, однако наличие такого метода не создаёт готовую интеграцию. Оба участника должны соблюдать согласованный формат, проверять происхождение и ожидаемое окно, а также смысл полученного события

Не принимайте любое сообщение со словом success как доказанную заявку. Проверьте, что оно пришло от предусмотренного origin и источника окна, содержит допустимую структуру и означает именно согласованный результат у поставщика формы. Даже корректное сообщение может сообщать промежуточное действие, если так устроен продукт

Не используйте произвольный широкий targetOrigin для передачи данных, когда известен точный получатель. Не отключайте проверки ради того, чтобы событие «начало приходить». Это меняет границу безопасности и не является подходящим исправлением измерения

Если поставщик не даёт нужного сигнала, в карте остаётся ограничение. Его нельзя закрыть чтением размеров iframe, таймером после клика или красивой анимацией успеха на A. Вы можете измерять взаимодействие с виджетом, но не называть его подтверждённым получением без основания

## Не путайте запись Вебвизора с подтверждением источника

У Метрики есть [условия записи содержимого iframe](https://yandex.com/support/metrica/ru/webvisor/iframe-support). Они описывают свою задачу и зависят от устройства окон. Удачное воспроизведение внешнего блока не означает автоматически сохранённую связь рекламного контекста с конкретной записью B

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

Поэтому в листе отдельно отмечаются «виден путь в записи посещения» и «Q01 содержит принятый контекст». Если первый пункт доступен, а второй нет, источник обращения не становится подтверждённым только из-за наглядного видео

Не расширяйте запись личных полей ради поиска контекста. Вопрос приватности и допустимого состава записи имеет собственные условия. Для нашей задачи предпочтительнее минимальное техническое подтверждение, которое не раскрывает переписку и введённые контакты всему кругу участников

Если на сайте вообще нет Вебвизора, это не делает проверку передачи невозможной. Карта участков, доступ к настройке B и согласованный тест записи могут дать нужное основание без просмотра пользовательской сессии

## Проверьте промежуточные перенаправления

Между A и B может находиться короткая ссылка, трекер, сервис записи или переход на другой URL формы. У каждого участка есть шанс потерять или изменить параметры. Запишите фактическую цепочку, не ограничиваясь тем адресом, который указан в кнопке исходного макета

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

Для теста используйте одно известное значение CX1. Сравните подготовленный переход и конечную запись. Если промежуточный сервис не поддерживает перенос, решение принимается по его возможностям: изменить маршрут, интеграцию или честно ограничить измерение

Обратите внимание на обычные и мобильные ссылки, если они различаются. Кнопка телефона может открывать приложение или встроенный браузер. Результат десктопного перехода не доказывает сохранность контекста во всех таких условиях

Если точную цепочку определить пока нельзя, не рисуйте в итоговой схеме прямую подтверждённую стрелку. Отметьте неизвестный участок и ответственного. Наглядная схема должна показывать реальные ограничения, а не скрывать их красивой линией

## Определите поведение при новом входе и возврате

Посетитель может открыть A из статьи, затем вернуться из рекламного объявления или продолжить старую вкладку B. Прежде чем говорить о первом или последнем источнике, договоритесь, какая попытка и какой контекст относятся к полученной записи

Не перезаписывайте прежнюю связь без правила. Если открытая форма B уже содержит CX1, а человек пришёл по другому маршруту CX2, нужно понять, что именно поддерживает сервис. Он может обновлять поле, создавать новую попытку или сохранять исходное значение. Это проверяется, а не угадывается

Для своего проекта выберите подходящее правило и объясните его в отчёте. Например: контекст конкретной подготовленной попытки формы, без претензии на весь путь человека. Тогда поздний возврат не превращается незаметно в новый рекламный источник

Отдельно проверьте прямое открытие B без A. Источника A в такой попытке может не быть, и это нормальное неизвестное. Не подставляйте последнюю учебную кампанию из памяти оператора, чтобы каждая строка имела красивую метку

В рабочем листе для возврата и нового входа нужны свои строки. Если они не проверены, общий статус «всегда сохраняется» не ставится. Можно принять основной переход и назвать дополнительные условия открытыми

## Ограниченный режим хранения и отказ от аналитики

У посетителя может не работать выбранное браузерное хранилище или не быть разрешения на определённый режим аналитики. Это влияет на доступные наблюдения. Не надо обходить его выбор скрытым переносом расширенного идентификатора во внешний сервис

Сначала определите, какие сведения нужны самой операции обращения, а какие относятся к необязательному измерению. Решение принимается по фактической схеме проекта и её условиям, а не по желанию получить одинаковый отчёт для любого посетителя

Если форма может принять задачу без аналитического контекста, проверьте этот путь отдельно. Обращение не должно теряться только потому, что метка не сохранилась. В карточке допустимо честное значение «источник не установлен», если оно соответствует принятому поведению

Не объявляйте технический параметр автоматически не относящимся к данным человека. Возможность связи с другими записями и доступ к ним имеют значение. Статья не даёт универсального юридического заключения о каждом варианте source_ref

Для приёмки достаточно записать фактический исход в выбранных условиях и не расширять его за пределы проверки. «В обычном тесте контекст сохранён; при отказе форма работает без связи» — понятная граница, если именно так устроен и согласован проект

## Как обращаться с отсутствующим и неподтверждённым источником

Разделите три статуса: подтверждён в принятой области; известен частично; не установлен. Частично может означать, что зафиксирован выход с A, но не удалось связать его с Q. Не установлен — что для конкретной записи нет достаточного основания даже для такого сопоставления

Не заменяйте неизвестное «прямым заходом», если источник просто не был сохранён. Это разные объяснения. Также не назначайте контекст по близости времени, совпадению города или похожему тексту сообщения без принятой связи

| Статус | Что известно | Как подписать |
|---|---|---|
| Подтверждён в области | Q содержит допустимый CX и связь проверена | «Контекст попытки A→B подтверждён» |
| Частично | Выход с A виден, связь с Q не доказана | «Известен переход, источник записи не подтверждён» |
| Не установлен | Нет достаточной связи | «Источник обращения не установлен» |

Даже первый статус не означает доказанный уникальный рекламный клик или отсутствие подмены. Он относится к согласованному сигналу и способу проверки. Если нужен более сильный вывод, нужны дополнительные основания и отдельная техническая задача

В отчёте сохраняйте количество и состав неизвестных рядом с известными группами. Не распределяйте их пропорционально расходам. Получившиеся красивые доли не становятся фактической атрибуцией от того, что арифметика сходится

## Полный учебный пример: что видно в версии V0

Компания показывает предложение на A: `https://offer.example/landing/`. Кнопка ведёт во внешнюю форму B: `https://forms.example.net/request/`. Услуга и кампания C1 условные. Все адреса и записи этого примера учебные, а не реальные внешние кабинеты

Тест T01 входит на A с принятой учебной меткой C1. На A контекст виден, а нажатие внешней кнопки наблюдается как переход. B открывается без поддерживаемого контекста, потому что в V0 команда предполагала автоматическую передачу всех меток через браузер

Получатель находит одну запись Q01. В ней есть тестовая отметка и содержимое задачи, но поле источника пустое. По одному совпадению времени нельзя объявить Q01 обращением C1. Мы знаем, что тест делался последовательно, но реальный отчёт не должен зависеть от памяти проверяющего

| Участок T01 | Ожидалось | Наблюдается | Статус |
|---|---|---|---|
| Вход A | Учебный контекст C1 | Он доступен на A | Принято в области A |
| Нажатие | Переход на B | Выход наблюдается | Принято как действие |
| Приём контекста B | Поддерживаемое значение | Не передано | Не принято |
| Запись Q01 | Связь с контекстом | Источник пустой | Не подтверждено |
| Единый путь Метрики | Отдельный результат | Не исследован | Не заявляется |

Владелец возвращает не всю форму, а участок передачи и сохранения. Приём задачи у получателя работает в пределах T01. Из этого не следует, что источник настроен, и не следует, что заявки вообще не доходят

## Какие вопросы заданы поставщику формы

Команда спрашивает, есть ли у конкретной B поддерживаемое поле для контекста и где оно сохраняется. Можно ли увидеть значение в записи, получить его в рабочей выгрузке и передать в конечную карточку? Как сервис поступает с пустым или неизвестным значением?

В учебной истории поставщик подтверждает собственную возможность. Её условное имя в документе — «поле контекста B», а не выдуманное публичное имя API любого популярного конструктора. Пример объясняет решение, но не заменяет проверку вашего продукта

Следующий вопрос касается способа перехода и ограничений. Нужно ли подготовить ссылку определённым образом, допускаются ли перенаправления, что происходит при повторном открытии? Ответы включаются в контракт до выпуска исправления

Команда также определяет, кто может читать контекст в конечном рабочем процессе. Если его увидит только администратор формы, а обработчик получит сообщение без поля, цель владельца останется частично незакрытой. Это выясняют заранее

Полученный ответ сохраняют вместе с версией интеграции. Не нужно выдавать слова «обычно умеет» за подтверждение конкретной функции. При отсутствии достаточного ответа схема V1 не считается готовой только по замыслу

## Исправление V1: явный контекст и сохранённая связь

В V1 для T02 подготовлен допустимый контекст CX1, который по учебному контракту относится к принятой попытке C1 на A. Он передаётся поддерживаемым способом B и сохраняется в новой записи Q02. Получатель видит тот же контекст в согласованном рабочем представлении

CX1 не является секретом администратора и не открывает данные клиента. Но он также не объявлен универсально анонимным идентификатором и защитой от подделки источника. Реальная схема должна отдельно определить эти свойства по назначению и способу создания

Владелец проверяет цепочку по участкам, а не по итоговой цветной галочке. На A есть принятый контекст; переход подготовлен по правилам B; Q02 содержит CX1; конечная карточка не потеряла его. Для каждого участка записано фактическое подтверждение

Исходная Q01 из V0 остаётся с неподтверждённым источником. Её не дописывают задним числом как будто автоматическая связь работала всегда. История показывает, что изменилось, а новая приёмка относится к V1 и T02

Метрика не объявляется автоматически полностью настроенной. В этой части примера принят контекст записи. Если бизнесу нужна единая история в отчёте, она получает отдельный тест с нужными доступами и условиями, а не следует из сохранённого поля

## Повторная проверка и новый контекст

После основного T02 выполняется T03 с другим допустимым учебным контекстом CX2. Новая запись Q03 должна сохранить именно его. Так проверяется, что интеграция не записывает C1 по умолчанию во все обращения и не держит старое значение только потому, что первый тест прошёл

Затем T04 открывает B напрямую без контекста A. Форма принимает допустимую задачу по своим правилам, а источник остаётся неустановленным. Она не подставляет CX1 из предыдущего просмотра и не заставляет клиента искать рекламную метку ради отправки

В учебном T05 возвращаются к уже открытой попытке CX1 после отдельного нового перехода CX2. Для этой модели заранее выбрано сохранение контекста подготовленной попытки: прежняя Q02 остаётся с CX1, а новое обращение маршрута CX2 имеет собственную Q03. Старую запись не переименовывают последним открытым адресом. У вашего сервиса может быть другой порядок, который нужно описать и проверить отдельно

| Тест V1 | Вход | Полученная запись | Что подтверждено |
|---|---|---|---|
| T02 | A, контекст CX1 | Q02 с CX1 | Связь этой попытки |
| T03 | A, контекст CX2 | Q03 с CX2 | Нет постоянной подстановки CX1 |
| T04 | Прямой B без A | Q04 без контекста | Неизвестное не выдумано |
| T05 | Возврат к попытке CX1 после нового перехода CX2 | Прежняя Q02 сохраняет CX1 | Новый переход не переименовал прежнее обращение |

Если T03 даёт прежнее значение, основной зелёный T02 не закрывает задачу. Возвращается конкретный дефект обновления или области хранения. Повторяют его после исправления вместе с проверкой, что начальный путь не сломан

## Заполненная карта итогового решения

В итоговом документе V1 записано: «Поддерживаемый контекст попытки передаётся с A и сохраняется в записи B и рабочем представлении получателя. Проверены CX1, CX2 и прямой вход без контекста. Единая история посетителя в Метрике и подлинность рекламного клика этой процедурой не установлены»

| Вопрос | Принятое состояние | Оставшаяся граница |
|---|---|---|
| Где находится предложение | A определён | Не весь путь пользователя |
| Где принимается задача | B и конечная запись определены | Доступы других систем отдельно |
| Что передаём | Допустимый контекст попытки | Не все параметры URL и не контакты |
| Где проверяем | Q и рабочее представление | Не только адресная строка |
| Что без метки | Источник не установлен | Не автоматическая C1 |
| Что с историей V0 | Q01 не переписана | Старое неизвестное сохранено |
| Что с Метрикой | Отдельная область проверки | Автоматического склеивания не обещаем |

В [рабочем листе двух доменов](/materials/lg50-a31-worksheet.md) есть заполненные V0/V1 и поля для собственной схемы. Заменяйте не только адреса, но и реальные возможности получателя, правило контекста и способ подтверждения. Если B не поддерживает такой перенос, нельзя принять образец как готовую интеграцию


![Граница A и B: метка на лендинге, поддерживаемая передача, запись с контекстом и три статуса уверенности; единая личность посетителя не обещана](https://media.keivo.ru/blog/_media/lg50-20261103/a31-diagram-31650ca02ddd.png)



Визуал показывает контракт конкретного пути. Он не отменяет браузерные ограничения и не изображает техническое устройство реальной платформы

## Если внешний сервис не позволяет сохранить контекст

Сначала подтвердите ограничение по документации или фактическому ответу поставщика. Не стоит строить сложную интеграцию на предположении, что скрытое поле «наверняка где-то есть». Важен поддерживаемый и воспроизводимый способ, а не разовая манипуляция интерфейсом

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

Если остаётся только выход с A, назовите его действием перехода. Отдельно считайте фактически полученные обращения в своей принятой единице, сохраняя отсутствие индивидуальной связи. Не делайте вид, что два итоговых числа дают точное соответствие строк

Ручной вопрос клиенту «откуда узнали» может дать полезное самоописание. Но это другой источник сведений, с собственной точностью и условиями. Не переписывайте его незаметно в техническую рекламную метку и не объявляйте доказанным последним кликом

При выборе своего приёма учитывайте, что появляется дополнительная ответственность за данные, хранение, безопасность и работу формы. «Сделаем у себя» не является бесплатным устранением всех проблем. Зато область контроля становится понятнее, если она действительно нужна бизнесу и правильно реализована

## Что проверить на телефоне и во встроенном браузере

Тот же URL может открываться иначе из приложения, мессенджера или мобильного браузера. Внешняя форма может перейти в отдельное приложение, потерять прежний контекст или показать другой маршрут. Поэтому один десктопный тест не равен приёмке всех предусмотренных входов

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

В каждом случае повторите ту же карту: контекст A, переход, приём B, запись и итоговый статус. Если телефон даёт лишь частичный результат, сохраните его отдельно. Успех ПК не должен незаметно окрашивать всю матрицу зелёным

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

При обнаружении отличия задайте конкретную задачу: какой маршрут, какое значение ожидалось, где оно потерялось и какая запись получена. Общая фраза «на iPhone источник не тот» без участка редко позволяет принять исправление

## Как принять изменение без потери работающей формы

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

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

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

Повторная приёмка охватывает как найденный дефект V0, так и нормальный путь. Одно поле в новой записи не закрывает потерю контактов на другом маршруте. В итоговом листе должны быть обе стороны: связь контекста и сохранённая работоспособность обращения

После выпуска повторите тест уже на опубликованных адресах, а не только на копии. Укажите версии A/B/интеграции и дату. Авторский учебный пример не является подтверждением, что ваше реальное внедрение уже прошло такую проверку

## Как использовать новые данные в отчёте

Подписывайте уровень связи точно. Если контекст в Q подтверждён по принятому правилу попытки, так и напишите. Не переименовывайте его в безусловно доказанный источник всей продажи или уникального человека через несколько устройств

Сохраняйте неизвестные рядом с известными группами. Отдельно можно показать число переходов A→B, число записей с подтверждённым контекстом и записи без достаточной связи. Не складывайте эти разные единицы в один итог «лидов по рекламе»

Если после исправления доля известных источников выросла, сначала объясните изменение измерения. Оно не доказывает рост реального спроса. Для сравнения периодов нужно видеть, когда работало прежнее правило и какие сведения удаётся сопоставить

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

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

## Запрос разработчику и внешнему поставщику

Передайте карту A/B/получателя, выбранный уровень результата, допустимые поля и полный T01. Напишите, что известно на A, что ожидалось в B и что реально находится в Q. Не заменяйте это общей просьбой «сделать междоменную Метрику»

Для поставщика B отдельно задайте вопросы о поддерживаемом переносе, сохранении в записи, экспорте и отсутствии контекста. Для разработчика A — о подготовке перехода, лишних параметрах, новых входах и сохранении нормальной работы формы. Каждая сторона должна понимать свою область

В критериях приёмки укажите CX1, другой CX2, прямой вход без метки и существенные мобильные условия. Не просите гарантировать то, что не входит в доступные возможности внешнего сервиса. Если нужна единая аналитическая история, выделите её отдельным проверяемым пунктом

Когда требуется связать лендинг, приём обращения и рекламное измерение, состав можно обсудить на [странице лидогенерации KEIVO](/services/lead-generation/). Для начала достаточно схемы систем и обезличенного наблюдения. Секреты внешних кабинетов в первом сообщении не нужны

Сохраните ответы и повторные результаты вместе с версией интеграции. Тогда следующий специалист увидит не только готовую кнопку, но и основания, на которых бизнес считает источник установленным либо ограниченным

## Частые вопросы о двух доменах

### Достаточно добавить B в дополнительные адреса Метрики

Это описывает одну настройку счётчика, а не весь путь получения. Нужно отдельно проверить, где работает код, что сохраняет форма и какой результат требуется. Автоматическое объединение всей истории этим действием не подтверждается

### Метка есть в URL формы, значит источник принят

Пока подтверждён только адрес в этом состоянии. Найдите фактическую запись и рабочее представление получателя. Если поле там пустое или потеряно при выгрузке, требуемая связь ещё не принята

### Форма в iframe выглядит частью лендинга, почему нельзя просто прочитать поля

У внешнего документа своя область происхождения и ограничения браузера. Используйте предусмотренный поставщиком механизм обмена. Размер iframe, клик или показ анимации не заменяют подтверждённое получение

### Можно определить источник по времени обращения

Время помогает искать тест, но само по себе не устанавливает техническую связь. При нескольких посетителях и задержках такое сопоставление легко становится догадкой. Неизвестный источник не надо превращать в уверенную кампанию

### Что делать, если посетитель открыл B напрямую

Применить принятое правило отсутствия контекста. Если сведений нет, источник остаётся неустановленным. Не подставляйте последнюю метку другого теста или кампанию, которой хочется приписать обращение

### Сохранённый CX доказывает рекламный клик

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

## Завершите проверку понятным статусом

В итоговом листе должны быть адреса и владельцы систем, правило контекста, фактическая запись, повторные случаи и границы неизвестного. Если связь принята только в конкретной области, это ограничение остаётся рядом с результатом

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

## Читайте также

- [UTM-метки для лендинга: сохранение источника](https://keivo.ru/blog/utm-metki-dlya-lendinga/)
- [Почему расходятся Директ, Метрика и заявки](https://keivo.ru/blog/pochemu-direkt-i-metrika-pokazyvayut-raznye-konversii/)
- [Цель отправки формы в Метрике: настройка и тест](https://keivo.ru/blog/cel-otpravki-formy-yandeks-metrika/)


## Услуга по теме статьи

Лендинг и реклама: От предложения до заявки

Соберём страницу, подключим аналитику и подготовим рекламный запуск под задачу вашего бизнеса

[Подробнее о лидогенерации](https://keivo.ru/services/lead-generation/)