Если GCLID приходит на посадочную страницу, но отсутствует в заказе, рекламная система теряет связь клика с продажей. Причина обычно в редиректе, очистке query-параметров, cookie, переходе между доменами или отсутствии серверного хранения.

Пройдите путь от рекламного URL до создания заказа и на каждом шаге проверьте, где хранится click ID. Для надежности записывайте его на backend при первом визите и связывайте с заказом серверно.

Коротко: что сделать

  • Проверить наличие gclid на первой странице
  • Проверить редиректы и canonical URL
  • Проверить запись идентификатора после согласия пользователя
  • Проверить перенос через корзину и авторизацию
  • Проверить поле click ID в заказе и CRM

Почему возникает проблема

GCLID — параметр входа, но заказ может быть создан через несколько страниц, поддоменов и сервисов. Без явного сохранения он естественно исчезает.

  • Редирект удаляет query string
  • SPA-роутер заменяет URL до чтения параметра
  • Cookie имеет неправильный domain или SameSite
  • Корзина находится на другом домене
  • Идентификатор хранится только в localStorage одного браузера
  • Backend заказа не принимает поле атрибуции

Пошаговая диагностика

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

  • Проверить цепочку редиректов в Network
  • Зафиксировать gclid на каждом шаге тестового заказа
  • Проверить cookie и storage после согласия
  • Проверить вход и оформление на другом поддомене
  • Проверить payload создания заказа
  • Проверить экспорт заказа в CRM

Как исправить

Надежная схема сохраняет click ID при первом допустимом контакте и переносит его через серверную сессию или запись лида.

  • Сохранять query string при технических редиректах
  • Читать gclid до очистки URL
  • Записывать click ID в серверную сессию с нужным TTL
  • Передавать идентификатор между доверенными доменами по безопасной схеме
  • Добавить отдельное поле в заказ и CRM
  • Отправлять офлайн-конверсию только с валидными данными и временем события

Как проверить результат

  • Создать тестовый заказ с уникальным GCLID-маркером
  • Проверить его в базе и CRM
  • Проверить гостевой и авторизованный заказ
  • Проверить мобильный сценарий и переход между доменами
  • Проверить, что повторный визит не затирает атрибуцию без правила

Как не допустить повторения

Атрибуция должна быть частью модели заказа и регулярно проверяться сквозным тестом.

  • Документировать first-click и last-click правило
  • Добавить мониторинг доли заказов с click ID
  • Тестировать редиректы после релиза
  • Соблюдать настройки согласия и политику обработки данных

Чего не стоит делать

  • Не подставлять вымышленные GCLID
  • Не хранить идентификаторы бессрочно
  • Не передавать их в открытых логах без необходимости
  • Не считать наличие параметра на лендинге достаточным

Что подготовить для диагностики

  • Тестовый рекламный URL
  • Схема доменов и редиректов
  • Код сохранения атрибуции
  • Структура заказа и CRM
  • Правило согласия и TTL

Частые вопросы

Можно ли хранить GCLID только в cookie?

Можно для простого сценария, но серверная сессия или запись лида надежнее при сложном оформлении и нескольких доменах.

Почему GCLID пропадает после входа?

Авторизация может создать новую сессию или перейти на другой домен, не перенеся атрибуцию.

Что проверять после изменения редиректов?

Сохранение query string, запись идентификатора и полный тестовый заказ до CRM или импорта конверсии.

Когда стоит обратиться за помощью

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

Итог

GCLID не должен случайно путешествовать только по URL: его нужно законно сохранить и привязать к заказу на backend. Настроить сквозную передачу можно через @rabotator_support.