Потеря 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 прелендинг: частые вопросы

Источники