fbclid ttclid: как не потерять клик-идентификаторы в воронке
Что делают клик-идентификаторы
Когда пользователь кликает рекламу Meta, Meta добавляет свой ClickID в URL рекламодателя: https://example.com/?fbclid=IwAR2F4.... выгоды Meta документирует прямо - больше зачтённых конверсий, лучше атрибуция и оптимизация кампаний - потому что клик-идентификатор позволяет связать будущую конверсию с тем самым кликом, который её привёл. TikTok делает то же самое через ttclid: параметр добавляется в URL лендинга и используется для атрибуции внутри клик-окна.
Пара fbclid и ttclid имеет правила, важные операционно. Meta предупреждает: значение ClickID чувствительно к регистру - не нужно приводить его к верхнему или нижнему регистру и вообще как-то менять до использования. Обе платформы рекомендуют хранить значение у себя: пиксель Meta автоматически пишет ClickID в first-party куку _fbc; ttclid TikTok добавляет в URL сам, а хранить его на своей стороне - уже ваша задача.
Параметры заслуживают отдельного гайда потому, что они хрупкие в пути. Всё, что дальше - цепочки редиректов, трекеры, шортлинки, мессенджеры, - обрабатывает ваш URL лендинга, и одна перезапись, потерявшая query string, тихо рубит цепочку атрибуции. Ошибки не будет; конверсии просто перестанут матчиться.
Где клик-ID теряются
Клик-ID умирают в пути, а не в источнике. Типовые точки потери в арбитражной воронке:
- Цепочки редиректов. Каждый хоп обязан пробрасывать весь query string. Редирект 301 с жёстко прописанным чистым URL назначения срезает
fbclidиttclidодной строкой конфига. - Шортлинки и смарт-линки. Шортлинк, который перекодирует параметры - или выбрасывает неизвестные, - ломает все платформенные идентификаторы, которые вёз.
- Мессенджеры и in-app открытия. Трафик из мессенджеров проходит дополнительные слои, которыми вы не управляете, - именно поэтому платформы дали куки-страховку для навигации внутри сайта.
- Хоп прелендинг → оффер. В арбитражных воронках чаще всего рвётся именно тут: ссылка на оффер собрана без макросов трекера, и клик-ID, пойманный на преленде, не доезжает до страницы, где происходит конверсия. Пробрасывайте макросы трекера - и платформенные параметры - в каждую исходящую ссылку.
- Рерайты трекера. Трекер, пересобирающий URL лендинга, обязан пробрасывать платформенные параметры дословно - и предупреждение Meta про чувствительность к регистру здесь работает: изменили значение - сломали его.
Операционное правило: считайте fbclid и ttclid неизменяемыми строками. Поймали на первом запросе - тащите через все хопы без изменений и логируйте рядом с кликом в трекере. Если вы не можете ответить «где fbclid для этой конверсии?», цепочка атрибуции уже порвана где-то между рекламой и постбеком.
Куки-страховка first-party
Платформы спроектированы с расчётом на потерю URL. Пиксель Meta, установленный на сайте, автоматически пишет ClickID в first-party куку _fbc; кука _fbp несёт рядом идентификатор браузера. Гайд Meta по серверным событиям: слать обе куки в параметрах fbc и fbp, когда они доступны, и обновлять их между сессиями, потому что значения меняются. Если ваш сервер читает куку _fbc из запроса, вы можете восстановить клик-контекст для посетителей, дошедших до сайта с целым ClickID: кука страхует переходы между страницами вашей воронки, но не хоп до первой загрузки страницы. Если редирект выше по цепочке уже срезал fbclid, пиксель его не увидит и куку не создаст - поэтому сохранность параметра по дороге к лендингу остаётся обязательной.
ttclid TikTok аналогично живёт через пиксель для веб-событий. У куки-страховки есть пределы - куки привязаны к браузеру и чистятся вместе с согласиями и уборкой, - поэтому авторитетная схема ловит клик-ID серверно на первом касании и хранит его в собственном трекере, не доверяя браузеру.
Тащим клик-ID через трекер в CAPI-события
Для трекерного трафика цепочка сохранности из трёх звеньев. Первое - захват: лендинг или трекер записывает fbclid/ttclid из URL вместе с собственным клик-ID трекера. Второе - хранение: пара живёт в трекере до конверсии - дни или недели. Третье - реплей: когда приходит постбек, серверное событие в Conversions API платформы несёт сохранённый клик-идентификатор, и сеть связывает конверсию с исходным кликом. Это тот же механизм, что в доставке TikTok Events API из трекеров и интеграции Keitaro с Facebook CAPI. Дальше дедупликация по event ID не даёт переигранному событию задвоиться с браузерной копией.
Пропущенное первое звено отравляет остальные: постбек без клик-идентификатора отправить можно - фолбэк-матчинг даст хэшированный user data, - но сильнейший сигнал атрибуции потерян, и это проявится как проблемы match rate и расхождения, а не как ошибки. Диагностика - в гайде по расхождениям Facebook Ads и общем чеклисте по постбекам.
Ручная обвязка клик-ID по лендингам и сетям - ровно тот хрупкий слой, который автоматизирует MOST: захват на лендинге, хранение в трекере, реплей в Conversions API каждой сети с ретраями и дедупликацией. Для одиночного лендинга и ручного воркфлоу те же механики без кода применяет Pixel Activator, а серверный контекст целиком - в серверном трекинге против браузерных пикселей.