Потеря click ID прелендинг: где умирают клик-идентификаторы

Самый тихий способ арбитражной воронки утечь деньгами - потеря click ID прелендинг: площадка дописывает идентификатор к URL объявления, посетитель проходит прелендинг, редирект-другой и страницу оффера - и где-то в этой цепочке идентификатор перестаёт ехать. Конверсия случается; постбек приходит с пустым subid; и площадка никогда не узнает, какой из её кликов произвёл деньги. Этот гайд проходит прелендинг хоп за хопом, отмечая, где click ID выживают, а где умирают, и показывает две техники, удерживающие атрибуцию живой, когда вёрстка ведёт себя плохо.

Точки потери на уровне самой ссылки - срезанные UTM, лимиты длины URL, ошибки настроек объявлений - живут в гайде где теряются fbclid и ttclid; эта страница - про саму прелендинг-цепочку. Имена по площадкам собраны в глоссарной статье про click ID.

Цепочка: каждый хоп - это передача

Типичная прелендинг-воронка проводит идентификатор через четыре хопа:

1. Объявление в трекер. Площадка дописывает fbclid (Meta), ttclid (TikTok) или свой параметр к URL назначения. Если назначение - ссылка трекера, трекер сохраняет клик с идентификатором немедленно - до того, как что-то ещё успеет сломаться.
2. Трекер в прелендинг. Трекер редиректит на прелендинг, передавая нужные ему параметры. Click ID уже благополучно сохранён на стороне трекера; копия, едущая в URL, - лишь удобство.
3. Прелендинг на оффер. CTA прелендинга ведёт посетителя на URL оффера с параметром subid сети. Здесь техники на странице - обычные ссылки, meta refresh, JavaScript, iframe - несут параметры по-разному.
4. Оффер в постбек. Рекламодатель сообщает о конверсии; сеть возвращает ваш subid эхом. Вернёт ли она что-то - зависит целиком от того, что пережило хоп три.

Правило безопасности следует из структуры: занесите идентификатор в трекер на хопе один, и хопы два-четыре возят только сетевой subid - один короткий параметр, задокументированный сетью, одинаковый на всех ваших лендингах. Гайданс Meta для серверных связок говорит то же с другой стороны: значение куки _fbc собирается из URL-параметра fbclid, когда браузер его не поставил (fbp and fbc parameters) - канонический дом идентификатора - URL в момент клика, а не любая следующая страница.

Хоп три: где живут тихие потери

У хопа «прелендер-оффер» три типовых реализации с очень разными профилями отказа:

Случай iframe заслуживает предупреждения, которого редко получает: оффер, вложенный в iframe, грузит URL, который вы вписали в src фрейма. Если URL сохранён без плейсхолдера subid - или с макросом, который шаблон не разрешает, - каждый посетитель конвертится без идентичности, а прелендинг в браузере выглядит идеально. Meta и TikTok документируют свои идентификаторы как URL-параметры - fbclid на URL объявлений, ttclid по документации click ID TikTok, - а URL-параметры не телепортируются через фреймы и refresh: что-то в разметке обязано их нести.

TikTok в документации указывает, что каждый Click ID уникален и привязан к тому же CTA-окну, которое настроено в Attribution Manager, - и параметр живёт в URL перехода, так что приёмник должен снять его при первом же заходе; ещё один аргумент за захват на хопе один вместо надежды на середину воронки.

Хоп один сделан правильно: захват на стороне трекера

Решение с наивысшим рычагом в прелендинг-воронке - URL назначения объявления. Ведите объявление прямо на оффер или на голый прелендинг, передающий параметры дальше, - и каждый хоп становится шансом потери. Ведите объявление на ссылку трекера, и хоп один заканчивается тем, что клик - с идентификаторами площадки, IP и user agent посетителя - записан в базу трекера:

1. Ссылка трекера принимает клик с fbclid/ttclid и сохраняет их в строке клика.
2. Все последующие хопы должны прокатить в обратную сторону только собственный subid трекера - один короткий параметр, задокументированный сетью, стабильный на всех лендингах.
3. В момент конверсии постбек сети возвращает subid; Keitaro матчит его с кликом, и сохранённые идентификаторы едут серверным событием на площадку (постбек-контракт Keitaro).

Именно поэтому предупреждение из доков Keitaro так важно в прелендинг-воронках: «партнёрские сети не шлют настоящий subid в тестовых постбеках» - единственный валидный тест хопов два-четыре - реальная конверсия через реальную цепочку.

Серверная реконструкция: страховочная сетка

За одним симптомом («конверсии не атрибутируются») прячутся две разные потери с противоположной восстанавливаемостью:

• Потеряны браузерные идентификаторы. Куки _fbp/_fbc домена оффера в арбитражных потоках не существовали никогда - пикселя на оффере нет. Их заменяет сборка: Meta документирует, что _fbc собирается из параметра fbclid, который трекер снял в момент клика (fbp and fbc parameters). Пока хоп один сохранил клик, реконструкция работает независимо от того, что натворила вёрстка прелендинга.
• Потерян subid. Если сеть не получила ваш subid - meta refresh, уронивший его, или голый src iframe, - конверсия доезжает до трекера не сматченной, и никакая техника ниже по течению не восстановит связь, которая не была образована. Лог постбеков Keitaro называет это прямо: «Click for subid REPLACE not found», а починка - маппинг параметров оффера или разговор с сетью (postback troubleshooting).

Лестница восстановления поэтому такая: предотвращайте захватом на хопе один, детектируйте логом постбеков и реконструируйте на сервере то, что потерял браузер. Чего трекер не сохранял - в лестнице нет ступени; более широкие потери разобраны в плейбуке без доступа.

Тест цепочки до масштабирования

Пятиминутный ритуал до деплоя ловит все режимы потери выше:

1. Кликните объявление (или скопируйте его URL назначения) и убедитесь, что параметр click ID присутствует на входе в трекер.
2. Откройте каждый хоп прелендинга и инспектируйте производимый URL оффера: параметр subid обязан присутствовать и быть непустым - проверяйте реальным кликом, потому что шаблонные макросы иногда разрешаются только для реальных сессий.
3. Стрельните реальной конверсией и проверьте логи Keitaro: лог входящих постбеков подтверждает матч по subid (без ошибки «Click for subid not found»), а лог S2S-постбеков показывает заполненный {external_id}, доказывая замкнутый цикл до источника.
4. Убедитесь, что площадочное событие несёт реконструированные идентификаторы - Test Events показывает прибытие, Events Manager - примерно за 20 минут (get started).

Чеклист поиска неисправностей постбеков превращает ритуал в печатную рутину, а обвязка хопа четыре - в гайде от постбека до CAPI.

Потеря click ID прелендинг: частые вопросы

Источники