Click ID, Sub ID, fbclid, fbc и ttclid: чем они отличаются

click_id, sub1, fbclid, fbc, ttclid и transaction_id часто оказываются в одном URL, но решают разные задачи. Ошибка начинается, когда один идентификатор пытаются использовать вместо другого: campaign ID отправляют как уникальный клик, fbclid считают внутренним ключом трекера, а один click ID используют для дедупликации всех депозитов.

Эта статья — карта ролей: кто создаёт идентификатор, где он живёт и на каком этапе его нужно вернуть.

Карта идентификаторов

Значение	Кто создаёт	Что идентифицирует	Где хранить	Для чего вернуть
Internal click ID	Трекер	Один отслеженный клик	Отдельное поле click ID или sub-поле сети	S2S postback в трекер
Sub ID	Трекер/баер	Произвольный контекст или контейнер	`sub1…subN`, `aff_sub`	Аналитический срез или перенос click ID
`fbclid`	Meta	Клик по рекламе Meta	В click record и first-party storage	Построение `fbc`, CAPI attribution
`fbc`	Сайт/интеграция	Cookie-формат Meta click context	First-party cookie/сервер	Meta Conversions API
`fbp`	Meta Pixel/сайт	Идентификатор браузера Meta	First-party cookie	Meta CAPI matching
`ttclid`	TikTok	Клик по рекламе TikTok	В click record и first-party storage	TikTok Events API/атрибуция
`gclid`	Google Ads	Клик по рекламе Google	В click record/CRM	Offline conversion import
Transaction ID	Сеть/CRM	Одно бизнес-событие	Conversion record	Dedup и correction
Campaign/ad IDs	Рекламная платформа	Группу кликов	Отдельные dimensions	Отчётность и разбивка

Internal click ID: позвоночник трекера

Внутренний click ID создаётся, когда пользователь проходит через tracking link. Он должен быть уникальным, неизменяемым и не содержать персональные данные.

Трекер использует его как ключ, чтобы поздняя регистрация или покупка вернулась к исходному source, campaign, creative, stream и offer. В URL партнёрской сети ID часто едет в универсальном поле:

https://network.example/offer?aff_sub={click_id}

А в postback возвращается обратно:

https://tracker.example/postback?click_id={aff_sub}&status={status}

Названия слева и справа могут отличаться. Инвариант — реальное значение должно пройти цикл без изменений. Подробный разбор направления макросов есть в гайде по параметрам Postback URL.

Sub ID: поле, а не тип данных

sub1, sub2, aff_sub или s2 — это контейнеры. В них можно записать:

внутренний click ID;
buyer/team code;
placement;
creative angle;
имя landing-варианта.

Поэтому фраза «наш click ID лежит в sub2» корректна. Фраза «любой sub ID — это click ID» — нет. Если в sub1=facebook_feed, это полезная метка, но она повторяется у множества кликов и не может найти одну конверсию.

`fbclid` и `fbc`: связаны, но не равны

Meta добавляет fbclid к URL после рекламного клика. Это платформенный идентификатор, а не замена внутреннего ключа трекера. Для server-side отправки Meta использует параметр fbc, который обычно строится из click context и имеет ожидаемый формат.

Практически нужно сохранить оба слоя:

внутренний click ID — чтобы ваш трекер нашёл клик;
Meta click context — чтобы Meta сопоставила CAPI-событие со своим рекламным кликом.

fbp решает ещё одну задачу: помогает Meta сопоставить браузер. Он не идентифицирует business transaction и не заменяет event_id для дедупликации Browser Pixel + CAPI.

Параметры кампаний Meta — campaign_id, adset_id, ad_id и их name-макросы — вынесите в отдельные поля. Рабочий шаблон разобран в макросах URL для Facebook Ads.

`ttclid`: click context TikTok

TikTok описывает TTCLID как click ID, который добавляется к landing URL после клика и используется для атрибуции, измерения, создания аудиторий и оптимизации доставки (официальная справка TikTok).

Его тоже нужно хранить отдельно от internal click ID:

internal_click_id = dc_01K2A7M9X4
ttclid           = EAIaIQob...
campaign_id      = 183746...

Если редирект или PWA теряет query string, TikTok context исчезнет, даже когда ваш внутренний трекер продолжит считать клики. Именно поэтому URL надо проверять после каждого перехода. Для структуры campaign-параметров используйте гайд по макросам TikTok Ads.

`gclid` и другие platform click IDs

Google Ads использует gclid для click attribution и offline conversion workflows. Другие платформы имеют свои идентификаторы. Общая модель не меняется:

platform click ID принадлежит рекламной системе;
internal click ID принадлежит вашему трекеру;
mapping между ними хранится в click record;
transaction ID принадлежит конверсии.

Не пытайтесь создать собственный gclid, fbclid или ttclid. Если платформа не передала значение, произвольная строка не восстановит её атрибуцию.

Transaction ID и event ID: ключи события

Один click ID может породить несколько событий:

click dc_01K2A7M9X4
├── registration tx_reg_7719
├── first_deposit tx_dep_8821
└── repeat_deposit tx_dep_9904

Transaction ID различает эти бизнес-события и помогает не учитывать retry дважды. Для Browser Pixel + Meta CAPI обычно нужен согласованный event_id: браузерная и серверная копии одного события используют одно значение, чтобы платформа могла дедуплицировать пару.

Не используйте один постоянный event_id на всю жизнь пользователя: разные реальные события начнут склеиваться. И не генерируйте разные IDs для Pixel и CAPI одной покупки: платформа увидит две конверсии.

UTM-параметры — не идентификатор клика

utm_source, utm_campaign, utm_content описывают канал и группировку. Тысячи переходов закономерно имеют одинаковый UTM-набор. UTM полезны для отчётности, но не могут надёжно вернуть позднюю конверсию к одному клику.

Удобная иерархия:

UTM и campaign/ad IDs — где и в какой группе;
click ID — какой конкретно переход;
transaction/event ID — какое конкретно событие.

Пример записи одного клика

{
  "click_id": "dc_01K2A7M9X4",
  "source": "facebook",
  "campaign_id": "120210001",
  "adset_id": "120210101",
  "ad_id": "120210111",
  "fbclid": "IwY2xjaw...",
  "fbc": "fb.1.1786011100.IwY2xjaw...",
  "sub1": "buyer_07",
  "sub2": "feed_video_a"
}

Ни email, ни телефон, ни имя не должны ехать в открытом query string. URL попадают в access logs, analytics, историю браузера и интерфейсы партнёров.

Pass/fail-проверка параметров

Тест	Pass
Каждый тестовый переход создаёт новый internal click ID	☐
`fbclid` или `ttclid` сохраняется после всех редиректов	☐
Campaign/ad IDs лежат в отдельных полях и не подменяют click ID	☐
Сеть получает внутренний click ID в согласованном sub-поле	☐
Postback возвращает то же значение без изменений	☐
Каждая транзакция получает стабильный уникальный ID	☐
Pixel и CAPI одной конверсии используют общий `event_id`	☐
В URL нет персональных данных и секретов	☐

Частые ошибки

записать campaign ID в click_id и схлопнуть все переходы;
сохранить fbclid, но потерять его при PWA/open/offer redirect;
передать внутренний click ID в сеть, но вернуть другой sub-слот;
считать fbc буквальной копией fbclid без корректного формата;
использовать UTM как ключ postback;
дедуплицировать все события только по click ID;
менять регистр или длину непрозрачного идентификатора;
передавать PII в sub-параметрах.

FAQ

Click ID и Sub ID — одно и то же?

Нет. Click ID — роль уникального ключа клика. Sub ID — универсальное поле, которое может переносить click ID или любую другую метку.

Нужно ли хранить internal click ID, если есть fbclid?

Да. fbclid помогает Meta, а внутренний ID обеспечивает вашу собственную атрибуцию, postback и reconciliation между источниками.

Чем `fbclid` отличается от `fbc`?

fbclid приходит в landing URL после рекламного клика. fbc — параметр click context в ожидаемом Meta формате для server-side события. Они связаны, но не взаимозаменяемы как имена полей.

Зачем transaction ID, если click ID уже уникален?

Потому что один клик может дать несколько настоящих конверсий и несколько повторных доставок одного callback. Transaction ID отличает событие от retry.

Рабочая модель

Храните отдельные колонки для отдельной ответственности. В DarkCore PWA Tracker click record связывает source context, внутренний click ID и platform identifiers; Conversion Statuses нормализуют callback, а аналитика показывает итог по одной согласованной модели.