Жизненный цикл click ID: от рекламного клика до выплаты

Редакция mevrica

Трекинг5 мин чтения

Обновлено 3 августа 2026 г.

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

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

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

1. Создание на границе входа

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

Внутренний ID должен быть непрозрачным. Кодирование campaign, GEO, ставки или telegram_id внутрь строки создаёт утечки и усложняет изменения. Контекст хранится в записи клика, а не в самом ключе.

2. Уникальность и повтор

Уникальность формулируют как ограничение базы, а не надежду на генератор. Один и тот же ID, пришедший повторно, может означать перезагрузку, повторный HTTP-запрос, ошибку интеграции или злоупотребление. Система не должна молча создавать второй клик.

Полезно разделять raw request ID и логический click ID. Тогда повторная доставка запроса остаётся наблюдаемой, но не удваивает маркетинговое событие.

3. Передача через URL

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

Тест включает значения граничной длины и маршрут с каждым реальным редиректом. Проверка только короткого примера вроде test123 не обнаруживает большинство ошибок сериализации.

4. Redirect ledger

Каждый серверный переход пишет входной ID, исходящий ID, домен назначения, HTTP-статус, время и версию правила. Если посредник вынужден переименовать параметр, преобразование фиксируется как отдельная связь.

Такой ledger отвечает на вопрос, где именно исчезла нить. Без него команда видит клик в первом трекере и событие в партнёрке, но не может доказать, на какой границе они перестали совпадать.

5. Хранение на лендинге

Click ID может жить в серверной сессии, first-party cookie или состоянии приложения, но выбор зависит от маршрута и согласия пользователя. Отсутствие разрешённого хранилища не следует маскировать выдуманной связью. Событие помечается как unattributed или partial, а не присваивается последнему известному клику без правила.

При копировании URL идентификатор может уйти третьей стороне через referrer или логи. Политика referrer, минимизация query string и переход к серверной сессии уменьшают лишнее распространение.

6. От клика к регистрации

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

Если партнёрка возвращает только свой registration ID, соответствие сохраняется сразу после подтверждённого события. Поздняя попытка восстановить его по времени и IP создаёт неоднозначные склейки.

7. Event ID — отдельная ось

FTD, approved и payout — не новые клики, а события. Каждая доставка получает event_id или идемпотентный составной ключ. Повтор postback не должен создавать второе событие, но обязан увеличивать счётчик доставок и обновлять технический журнал.

Статус может измениться, поэтому неизменяемый event ID сочетается с версией или sequence. Перезапись одной строки без истории скрывает reversal и поздние корректировки.

8. Область уникальности

В распределённой системе одинаковая строка может теоретически появиться у разных поставщиков. Хранилище использует составной ключ namespace + click_id, где namespace указывает владельца идентификатора.

Это особенно важно при импорте старых данных и работе нескольких трекеров. Глобальное предположение об уникальности превращает совпадение строк в ложную связь между кампаниями.

9. Срок жизни и архив

TTL выбирают по максимальной полезной задержке событий, сроку сверки и обязательствам хранения, а не по удобству очистки. После удаления детальных данных можно сохранить агрегированную контрольную информацию, если это соответствует политике и задачам аудита.

Нельзя продлевать хранение только потому, что поле когда-нибудь пригодится. В паспорте данных указывают назначение, доступ, срок и процедуру удаления.

10. Диагностика потерь

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

Контрольная выборка проходит цепочку вручную: от строки расхода до ledger редиректов, регистрации, postback и начисления. Результат должен воспроизводиться без поиска по персональным данным.

Click ID не является персоной

Идентификатор клика описывает рекламный контакт. Использовать его как вечный идентификатор человека, объединять устройства без допустимого основания или передавать лишним сторонам — другая и более рискованная задача.

11. Миграция формата

Новый формат вводится с version или namespace. Переходный период умеет читать старые и новые значения, но создаёт только новые. Метрики качества разделяются по версии, чтобы ошибка миграции не растворилась в общем потоке.

Откат не должен повторно выпускать уже использованные ID. Поэтому состояние генератора и область уникальности проектируются независимо от версии приложения.

Вывод

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