Что такое ID клика: gclid, fbclid, ttclid и msclkid

ID клика - это непрозрачный токен, который рекламная платформа создаёт в момент клика по её объявлению, добавляет к целевому URL и считывает обратно позже, при конверсии, - чтобы сопоставить продажу или регистрацию с тем самым кликом, который её вызвал. У Google это gclid. У Meta - fbclid. У TikTok - ttclid. У Microsoft Advertising - msclkid. Запустите платные кампании больше чем на одной платформе - и вы встретите все четыре, обычно недоумевая, почему ваш URL стал таким длинным.

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

Что такое ID клика на самом деле

Думайте об ID клика как о номерке из гардероба, а не как о бейджике с именем. Когда кто-то кликает по рекламе Google, сервер Google генерирует уникальную строку, привязывает её к кампании, группе объявлений и ключевому слову, стоящим за этим кликом, и добавляет её к URL в виде ?gclid=.... Эта строка нечитаема ни для вас, ни для кого-либо ещё - это номер записи в собственном журнале кликов Google. Fbclid, ttclid и msclkid работают по той же схеме: разный «монетный двор», одна и та же идея.

Смысл в том, чтобы замкнуть цепочку между «мы показали рекламу» и «вот что произошло на вашем сайте». Без ID клика платформа может сообщать только оценки на уровне кампании. С ним она может сказать: именно этот клик, три дня назад, привёл к именно этой покупке - такую точность одни лишь UTM не дают. Именно на этом строится импорт офлайн-конверсий, Smart Bidding и серверные события в духе CAPI. Что такое UTM-параметры - статья-компаньон про разметку на уровне кампании, которую большинство команд использует вместе с ID кликов.

Четыре ID клика, с которыми вы столкнётесь

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

Четыре платформы, четыре имени параметра, один и тот же механизм. Рекламируйтесь на всех сразу - и одна и та же посадочная страница может нести сразу несколько ID кликов: устаревший gclid от клика на прошлой неделе соседствует со свежим fbclid от сегодняшней ретаргетинговой рекламы.

Чем ID клика отличается от UTM-параметра

Именно эта путаница стоит за каждым запросом «что такое fbclid»: он сидит прямо рядом с utm_source в строке запроса и выглядит как параметр отслеживания, но делает совершенно другое.

UTM-параметр - это метка: вы сами выбираете значение - utm_campaign=spring-sale - и ваш инструмент аналитики группирует сессии по той строке, которую вы ввели. ID клика - это ключ поиска. Значение gclid выбирали не вы, а Google, и только собственные системы Google могут что-то с ним сделать. Поместите gclid в обычный отчёт аналитики - и он просто будет там лежать: полезный для Google Ads, бесполезный для всех остальных.

Эта асимметрия важна для диагностики проблем. Когда UTM перестают отображаться в отчётах, виноват обычно браузер или сломанная ссылка - об этом сбое рассказывает статья Firefox и Brave ломают вашу UTM-атрибуцию. Когда перестаёт совпадать ID клика, причина почти всегда в том, что он вовремя не добрался до собственного пикселя или API платформы, либо окно его действия закрылось до того, как произошла конверсия.

Как на самом деле работает путь ID клика туда и обратно

Уберите специфичные для платформы названия - и каждый ID клика проходит один и тот же путь из трёх этапов.

Этап первый, создание. В момент, когда пользователь кликает по рекламе, ещё до того как браузер вообще запросит вашу посадочную страницу, платформа генерирует идентификатор и кодирует его в URL редиректа.

Этап второй, путешествие. Идентификатор едет как параметр запроса через все промежуточные переходы между рекламой и вашей посадочной страницей - сначала редирект платформы, затем ваш домен. Перехватите его здесь и запишите в cookie, скрытое поле формы или запись в CRM для дальнейшего использования.

Этап третий, сопоставление. Когда происходит конверсия - покупка, регистрация, отправка формы - ваш пиксель или сервер отправляет сохранённый ID клика обратно в API платформы вместе с событием. Платформа ищет его в собственном журнале кликов и, если окно действия ещё не закрылось, засчитывает исходную рекламу. Именно на этой механике строится передача конверсий в Conversions API от Meta: захватить рано, сохранить, отправить обратно позже.

Почему параметр появился незваным и можно ли его убрать

Большинство людей сталкиваются с ID клика случайно. Автоматическая разметка включена по умолчанию в Google Ads и Microsoft Advertising, а TikTok сделал ttclid автоматическим в 2024 году без какого-либо согласия. Никто не просил добавлять этот параметр - платформа просто начала это делать, потому что именно так теперь устроено отслеживание конверсий.

Так что да, его можно убрать - но именно момент решает, будет ли это безобидной уборкой или самостоятельно созданной дырой в атрибуции. Удаление fbclid из ссылки перед тем, как вы ей поделитесь, или очистка его из столбца URL в отчёте, никак не меняет данные о конверсии, которые уже зафиксировал ваш пиксель. Удаление же до того, как его успел прочитать ваш собственный скрипт или редирект, - совсем другая история: вы удалили единственное, что было нужно платформе для зачёта клика, и никакие объёмы UTM-данных это не восстановят. Самая безопасная привычка - перехватывать ID клика на стороне сервера на первом же переходе, подход, описанный в статье серверное отслеживание конверсий, - и очищать параметр только из того, что вы показываете или храните уже после этого перехвата.

Посмотрите, как отслеживание конверсий в Elido автоматически перехватывает каждый ID клика → Если вы вручную возитесь с gclid, fbclid, ttclid и msclkid в четырёх рекламных аккаунтах сразу, именно эту боль решает этот подход - один слой редиректа, который логирует идентификатор прежде, чем к URL прикоснётся что-либо ещё.

Где теряются ID кликов

ID клика уязвим точно так же, как уязвим UTM, плюс ещё один-два собственных сценария сбоя.

Четыре ситуации объясняют большую часть потерь, и для каждой нужно своё решение.

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

Клик открывается во встроенном браузере приложения. Instagram и TikTok передают нажатие в ограниченный webview, который часто не может сохранить собственный (first-party) cookie дольше этой сессии, поэтому идентификатору, едущему в URL, негде «жить». Считывайте параметр на сервере при первом же запросе, вместо того чтобы полагаться на память браузера.

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

Браузер вырезает параметр ещё до загрузки страницы. Вырезание параметров запроса в Firefox прямо называет fbclid в режиме «Строгая». Перехватывайте идентификатор на этапе редиректа, до того как целевая страница и её скрипты вообще запустятся.

Случай с копированием ссылки - это на самом деле проблема тёмного социального трафика (dark social), просто в костюме ID клика: ссылка проходит через приватный канал, невидимый для вашей аналитики, и статья атрибуция тёмного социального трафика разбирает этот разрыв полностью. Про специфичные для Safari ограничения cookie, влияющие на живучесть fbclid и ttclid, есть отдельный материал - атрибуция кликов после Safari ITP, - пересказывать его здесь не буду.

Как сохранить атрибуцию конверсий: практический чек-лист

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

• Перехватывайте gclid, fbclid, ttclid и msclkid на стороне сервера на первом же переходе редиректа, а не на посадочной странице после загрузки скриптов.
• Храните ID клика вместе с записью о заказе или лиде в собственной базе данных, а не только в cookie, которая может истечь до закрытия сделки.
• Передавайте сохранённый ID клика в API каждой платформы - Conversions API, Enhanced Conversions, Events API, офлайн-импорт UET - в пределах окна действия этой платформы.
• Проверьте, что ваш сокращатель или цепочка редиректов передаёт строку запроса без изменений; протестируйте с тестовым ?gclid=test123 и убедитесь, что он переживает переход.
• Используйте ID кликов вместе с UTM, а не вместо них; статья сквозное отслеживание UTM-параметров разбирает параллельную настройку для представления на уровне кампании, которое один только ID клика дать не может.

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

Другие статьи в блоге

• UTM-параметры: полное руководство
• Firefox и Brave ломают вашу UTM-атрибуцию
• Атрибуция кликов после Safari ITP
• Серверное отслеживание конверсий
• Передача конверсий в Conversions API от Meta