Трекинговая ссылка: что внутри и как работает

Трекинговая ссылка — это адрес, по которому посетитель попадает на сайт рекламодателя не напрямую, а через платформу, которая ведёт учёт. Переход приходит на домен сети, записывается в лог вместе с метками и только после этого перенаправляется на целевую страницу. Для сети такая ссылка — базовый инструмент: без неё нельзя отличить клик партнёра от органики, засчитать конверсию и начислить выплату. Для партнёра это способ доказать, что клиент пришёл именно от него. Ниже — из чего состоит трекинговая ссылка, какие параметры она несёт, как устроен редирект, что ломает учёт чаще всего и как проверить ссылку до запуска трафика.

Состав

Любой адрес страницы устроен одинаково: схема, домен, путь и строка запроса после знака вопроса. Так описывает универсальный идентификатор ресурса стандарт RFC 3986, и трекинговая ссылка использует ту же конструкцию — но каждая часть здесь работает на учёт.

Домен в такой ссылке принадлежит не рекламодателю, а сети или трекеру: обычно это отдельный поддомен вида redirect.имя-сети, чтобы переходы шли мимо основного сайта и не смешивались с его собственной статистикой. Путь внутри домена указывает на оффер или рекламную кампанию — у каждого оффера свой адрес перехода. Строка запроса несёт метки: идентификатор партнёра, номер клика, источник трафика.

Выглядит это так: партнёр получает от сети ссылку вида https://redirect.example.com/ofer123?aff_id=77&click_id={logid}. При переходе платформа подставляет вместо шаблона {logid} реальный номер клика и запоминает всю строку запроса в логе. Дальше работают два события. Клик платформа записывает сразу. Конверсия приходит позже постбэком от рекламодателя — заказ мог случиться через час или на следующий день, — и привязывается к клику по идентификатору из параметров: связка «клик — конверсия» восстанавливается по одному значению.

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

Строка запроса при этом не скрыта от глаз: она видна в адресной строке браузера и передаётся дальше вместе с адресом. Поэтому в метки не кладут персональные данные — только идентификаторы, по которым связку событий восстанавливает платформа. На этом же принципе построено хранение в Recca: персональные данные клиентов сети можно не передавать вовсе — только непрозрачные идентификаторы.

Параметры

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

Минимальный набор, без которого учёт не работает, — идентификатор клика. Его подставляет рекламная система в момент перехода, поэтому в ссылке он выглядит как шаблон в фигурных скобках: в примере из справки Яндекс Директа это click_id={logid}, рядом подставляется source={source}. Те же справки разрешают передавать в адресе перехода UTM-метки — источник, кампанию, объявление: платформа принимает их как обычные параметры строки запроса и складывает в статистику.

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

Кроме обязательных почти у каждой платформы есть свободные параметры — их обычно называют sub1–sub4. Партнёр вписывает в них что угодно: номер площадки, идентификатор поста, вариант креатива — и потом режет статистику по этим разрезам. Сеть просто прокидывает sub-метки дальше и показывает их в отчётах.

Обратная сторона обмена — постбэк. Рекламодатель принимает метки из строки запроса, а при конверсии возвращает их сети серверным вызовом. На платформе Recca формат постбэка совместим с конвенцией Affise, поэтому связка «клик — конверсия» собирается из привычных элементов: макросы подставляются так же, а каждый вызов остаётся в логе, где его видно целиком. Подробно про обмен событиями — в разделе про S2S-постбэки (/features/postbacks-s2s).

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

Редиректы

Трекинговая ссылка почти всегда отвечает редиректом: платформа принимает переход, пишет лог и отдаёт браузеру команду идти дальше. В HTTP для этого есть два вида кодов: постоянные 301 и 308 и временные 302 и 307 — семантика описана в RFC 9110.

Для трекинговых ссылок выбор кода не мелочь. Постоянный редирект браузер запоминает: при следующем переходе по тому же адресу он может разыграть сохранённый ответ из кэша и уйти по старому адресу сразу, минуя домен сети; правила кеширования описаны в RFC 9111. Кэш живёт долго, и клики выпадают из учёта — притом что сама ссылка исправна. Поэтому трекинговые ссылки отвечают временными кодами: 302 или 307 гарантируют, что каждый переход снова придёт на платформу и попадёт в лог.

Разница есть и внутри пар: 308 и 307 предписывают повторить запрос тем же методом, что важен для отправки форм, а при 302 клиент может сменить метод на GET. Переход по клику всегда начинается с GET, поэтому рабочими остаются оба временных кода — выбор между ними диктует то, как партнёр отправляет трафик.

Рекламные системы дополнительно проверяют, куда ведёт ссылка. В справке VK Рекламы описаны белый список редиректов и параметр redirect, в котором целевой адрес передаётся в закодированном виде: система распаковывает цепочку и смотрит конечную точку до запуска кампании. Для сети это означает простой порядок действий: зарегистрировать домен перехода у рекламной системы заранее и держать цепочку короткой — каждое лишнее звено удлиняет ответ и добавляет ещё одно место, где метки могут потеряться.

Что ломает учёт

Первый источник потерь — срезанные параметры. Если промежуточное звено в цепочке — сокращатель ссылок, прокси, страница-прокладка — передаёт адрес дальше без строки запроса, конверсия приходит без идентификатора клика, и привязать её к партнёру платформа не может. Ссылка внешне работает, но учёт уже испорчен, и задним числом это не восстановить.

Второй — закэшированный постоянный редирект. Стоит один раз ответить на переход кодом 301 — и браузеры части посетителей будут уходить по старому адресу даже после того, как сеть исправила ссылку. Лечится только временем: у каждого браузера свой срок жизни кэша.

Третий — длинные цепочки. Каждое лишнее перенаправление добавляет задержку и ещё одно место, где параметры могут потеряться; два-три перехода до целевой страницы — уже много.

Четвёртый — несработавшие макросы. Если рекламная система не подставила значение в шаблон, в лог попадает строка в фигурных скобках вместо номера клика, и связать такую запись с конверсией нельзя. Это видно сразу в логе кликов — поэтому его и смотрят до запуска, а не после.

Пятый разрыв — мобильный. Человек переходит с одного устройства на другое между кликом и конверсией, и у ссылки нет способа узнать об этом: часть установок остаётся неатрибутированной. Отложенный диплинк уменьшает проблему, но не снимает её.

Проверка

Трекинговую ссылку проверяют до запуска трафика, и для этого достаточно терминала и двух минут.

Команда curl -sIL «адрес» показывает всю цепочку: каждый ответ со своим кодом и адресом, куда ведёт следующий шаг. Проверяющему нужно убедиться, что в цепочке один-два перехода, коды временные — 302 или 307, а строка запроса доезжает до конца. Для проверки меток подставьте в шаблоны вместо фигурных скобок любое тестовое значение и убедитесь, что оно появилось в конечном адресе.

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

Последний шаг делает сеть. После тестового клика партнёр и менеджер оффера смотрят, записался ли клик в статистике платформы и пришло ли событие конверсии в лог постбэков. Если клик в логе есть, а конверсия на тестовое действие не пришла, проблема на стороне рекламодателя — проверяют постбэк и метки, которые он возвращает. В кабинете CPA-сети на Recca для этого есть статистика по кликам и логи постбэков, а настройки ссылок и событий собраны на тарифе «CPA-сеть» (/cpa-set). Оставьте заявку на подключение — и проверьте свою первую трекинговую ссылку на живом оффере.