Bounce tracking пропускает клики через домен трекера, чтобы установить first-party идентификатор — и полностью обходит блокировку third-party cookie.
Third-party cookie постепенно отключают во всех крупных браузерах, и немало советов по приватности до сих пор преподносят это как конец кросс-сайтового отслеживания. Это не так. Bounce tracking — также известный как редирект-трекинг — никогда и не зависел от third-party cookie. Он пропускает ваш клик через домен трекера на долю секунды — ровно настолько, чтобы этот домен успел прочитать и записать собственное first-party хранилище, — а затем отправляет вас туда, куда вы и хотели попасть. Ни один third-party cookie при этом не устанавливается, поэтому блокировка third-party cookie его никак не затрагивает.
Ключевые выводы
- Bounce tracking незаметно пропускает клик через собственный домен трекера перед тем, как продолжить путь к нужному адресу, — благодаря этому трекер на мгновение становится first-party и может записать или прочитать идентификатор в своём собственном хранилище.
- Link decoration переносит идентификатор через этот переход: к URL добавляется click ID или похожий параметр, чтобы трекер мог связать визит с профилем даже без cookie.
- Это в самой основе обходит блокировку third-party cookie — во время bounce идентификатор хранится в first-party хранилище на собственном домене трекера, а такую категорию ограничения на third-party вообще не затрагивают.
- Браузеры борются с этим на структурном уровне, а не только блокировкой cookie: Privacy Sandbox в Chrome включает Bounce Tracking Mitigations, которые очищают состояние для доменов, замеченных только в роли bounce-посредников; Intelligent Tracking Prevention в Safari изначально проектировался именно под этот класс злоупотребления редиректами.
- Это отдельное семейство трекинга, отличное от фингерпринтинга браузера (сигналы устройства без хранения состояния), суперкук на основе кеша (состояние спрятано в HTTP-кешировании) и постоянных ID на основе отпечатка — сравнение всех подходов ниже.
Что такое Bounce Tracking на самом деле
Представьте обычную ссылку: вы кликаете по ней, и браузер сразу переходит к месту назначения. Bounce tracking добавляет в этот путь невидимую промежуточную остановку. Ссылка ведёт не напрямую к цели — она указывает на домен трекера, который тут же выполняет собственный редирект дальше. Этот крюк может принимать несколько форм:
- Редирект на стороне сервера — сервер трекера возвращает HTTP-ответ 30x, указывающий на реальный адрес назначения.
- Редирект на стороне клиента — на домене трекера на мгновение загружается страница, а JavaScript (или meta-refresh) через долю секунды отправляет вас дальше.
В любом случае на этот короткий миг ваш браузер действительно находится на домене трекера — не встроен в iframe, не подгружает сторонний скрипт, а по-настоящему туда перешёл. Именно в этом вся суть: пока вы на собственном домене трекера, всё, что он сохраняет, с точки зрения браузера является first-party хранилищем — точно так же, как если бы вы сами ввели этот домен в адресную строку.
Link Decoration: как идентификатор переживает bounce
Один лишь редирект вас не идентифицирует — трекеру нужно ещё знать, какой именно клик только что попал на его домен, особенно в первый раз, когда он вас видит (пока у него ещё ничего не сохранено). Здесь в игру вступает link decoration: идентификатор добавляется прямо в URL как query-параметр — что-то вроде ?click_id=a1b2c3d4, прицепленного к обычной на вид ссылке.
Этот паттерн постоянно встречается в партнёрском маркетинге и атрибуции рекламы, где «click ID» должен пережить путь от показа объявления до страницы покупки, иногда через несколько промежуточных доменов. Bounce tracking заимствует тот же механизм для другой цели: декорированный URL позволяет домену трекера прочитать идентификатор прямо из самой навигации, записать его в собственное first-party хранилище этого домена и передать вас дальше. При следующем bounce через тот же трекер он считывает своё же хранилище и связывает оба визита — без какого-либо обмена cookie с сайтом назначения.
Почему это обходит блокировку third-party cookie
Ограничения на third-party cookie работают так: домену, который отличается от того, что указан в адресной строке, запрещено устанавливать или читать cookie, пока вы находитесь на чужой странице, — классический случай: рекламный скрипт, встроенный в страницу издателя, пытается установить cookie для собственного домена. Bounce tracking никогда не ставит браузер в такую ситуацию. Во время bounce домен трекера на мгновение сам оказывается тем доменом, что указан в адресной строке. Всё, что он там сохраняет, — это first-party хранилище, точка; ни одно правило про third-party cookie никогда не проектировалось так, чтобы ограничивать действия домена с собственным first-party хранилищем, пока вы на самом деле на него перешли.
Именно поэтому решением не могло стать «немного расширить блокировку cookie» — весь механизм обходит саму границу third-party/first-party, вокруг которой построена блокировка cookie. Чтобы это остановить, нужно распознавать паттерн домена, который появляется исключительно как мимолётный bounce и никогда — как адрес назначения, на котором вы действительно задерживаетесь.
Защита браузеров от Bounce Tracking
Поскольку bounce tracking эксплуатирует саму навигацию, а не конкретный storage API, защита вынуждена отслеживать поведение браузинга во времени, а не блокировать один-единственный вызов.
Bounce Tracking Mitigations из Privacy Sandbox в Chrome работают так: браузер отслеживает, через какие домены пользователя редиректят, ни разу не провзаимодействовав с ними и не задержавшись надолго, а затем периодически очищает хранилище и cookie этого домена. Домен, который всегда оказывается лишь мимолётным посредником и никогда — местом назначения, обрабатывается иначе, чем сайт, который вы действительно посещаете, — и именно этот паттерн отличает bounce-tracking-посредника от обычного сайта, на который вы переходите намеренно.
Intelligent Tracking Prevention в Safari пошёл похожим, но более ранним путём. Как описывает собственный пост WebKit Intelligent Tracking Prevention 2.0, ITP изначально проектировался так, чтобы учитывать кросс-сайтовый навигационный трекинг, а не только встроенные third-party запросы, — то есть именно тот паттерн «редирект + decoration», на который опирается bounce tracking, решается классификацией и ограничением хранилища для доменов с трекинг-подобным навигационным поведением, а не только фильтрацией заголовков third-party cookie.
Enhanced Tracking Protection в Firefox преследует ту же цель через собственные списки классификации трекеров и партиционирование хранилища, ограничивая то, что классифицированный трекер способен сохранить, — независимо от того, произошло взаимодействие через встраивание или через редирект.
Ни одна из этих мер не описывается собственными авторами как окончательное, постоянное решение — см. обзор MDN про third-party cookie, чтобы увидеть, как базовая модель приватности продолжает эволюционировать по мере того, как браузеры закрывают одну лазейку за другой. Меры против bounce tracking правильнее понимать как активную, непрекращающуюся защиту от движущейся цели, а не как окончательно решённую задачу.
Чем Bounce Tracking отличается от других семейств трекинга
BrowserInsight описывает несколько разных межсессионных механизмов трекинга, и важно точно понимать, с каким именно вы имеете дело:
| Механизм | Что сохраняется | Где хранится состояние |
|---|---|---|
| Bounce/redirect-трекинг | Идентификатор в декорированном URL | First-party хранилище на самом bounce-домене |
| Фингерпринтинг браузера | Не сохраняется вообще ничего | Пересчитывается при каждом визите из сигналов устройства/рендеринга |
| Постоянные visitor ID | Значение, выведенное из отпечатка | Пересчитывается из стабильных сигналов оборудования/браузера или восстанавливается (respawn) из нескольких хранилищ |
| Суперкуки на основе кеша | Идентификатор, спрятанный в кешированных ответах | HTTP-кеш браузера |
Фингерпринтингу и постоянным ID на основе отпечатка вообще не нужны ни хранилище, ни трюки с навигацией — один и тот же хеш canvas или строка рендерера WebGL возвращаются каждый раз просто потому, что считываются вживую с вашего устройства, и именно поэтому очистка данных, приватный режим или VPN их никак не затрагивают. Bounce tracking — техника прямо противоположного рода: она целиком построена на механике хранилища и навигации, эксплуатируя границу first-party/third-party, а не характеристики устройства. Сайт также может определить сам факт, что вы находитесь в приватном окне, через отдельные трюки с квотой хранилища — об этом отдельном механизме см. как сайты обнаруживают режим инкогнито и приватный просмотр. Важно понимать, к какому именно семейству относится то или иное заявление о трекинге, потому что защита, останавливающая одно (блокировка third-party cookie, рандомизация отпечатка), обычно никак не действует против остальных.
Что раскрывает ваш собственный браузер
Bounce tracking незаметен в адресной строке — цепочка редиректов происходит слишком быстро, чтобы её заметить, а большая часть того, на чём она основана, не поддаётся прямому изучению при загрузке одной-единственной страницы. Что вы всё же можете проверить — это более широкую поверхность сигналов, которую сайт способен скомбинировать с этой техникой: проверка отпечатка от BrowserInsight показывает сигналы хранилища, canvas и другие клиентские сигналы, которые ваш браузер раскрывает прямо сейчас, — полностью на стороне клиента и никогда не отправляется никуда для анализа.
Часто задаваемые вопросы
Останавливает ли блокировка third-party cookie bounce tracking?
Нет. Bounce tracking работает за счёт того, что домен трекера на время редиректа становится first-party, поэтому правила про third-party cookie вообще никогда не срабатывают. Чтобы это остановить, браузеры должны распознавать сам паттерн редиректа — именно это и делают такие меры, как Bounce Tracking Mitigations в Chrome и ITP в Safari.
Bounce tracking — это то же самое, что партнёрская ссылка или сокращатель URL?
Механика пересекается — оба подхода используют редирект и часто декорированный URL, — но цель разная. Сокращатель URL или заявленный партнёрский редирект существуют, чтобы направить вас куда-то, и сам редирект — это видимая, осознанная часть процесса. Bounce tracking использует абсолютно тот же технический паттерн специально для того, чтобы внедрить first-party идентификатор во время редиректа, который пользователь вообще не замечает.
Останавливает ли bounce tracking очистка cookie?
Только частично и только до следующего bounce. Очистка cookie стирает всё, что домен трекера уже успел сохранить, но при следующем клике по декорированной ссылке через тот же домен он может просто записать новый идентификатор прямо во время bounce. Меры, которые действительно нацелены на этот паттерн, работают за счёт распознавания и периодической очистки доменов, которые появляются исключительно как bounce-посредники, — а не за счёт того, что данные очистите вы сами.
Эффективен ли bounce tracking всё ещё в 2026 году?
Его эффективность снижается, но не исчезает. Меры на уровне браузера всё чаще обнаруживают и очищают хранилище доменов, которые ведут себя как чистые bounce-посредники, но эта защита всё ещё разворачивается неравномерно — в зависимости от браузера и конфигурации, — а базовая механика «редирект + decoration» никуда не делась. Это активная гонка вооружений, по форме похожая на игру в кошки-мышки вокруг обнаружения инкогнито.
Заключение
Bounce tracking напоминает: конец third-party cookie — это не конец кросс-сайтового трекинга, а лишь конец одного его механизма. Ненадолго превращая домен трекера в first-party во время редиректа и перенося идентификатор через link decoration, эта техника обходит именно ту границу, для соблюдения которой и была создана блокировка third-party cookie. Браузеры отвечают на это защитой, которая отслеживает навигационные паттерны, а не просто фильтрует заголовки cookie, но, как и с любой другой техникой на этом сайте, честный вывод таков: ни одно отдельное решение — ни очистка cookie, ни блокировка third-party хранилища, ни какая-то одна конкретная мера браузера — не закрывает все лазейки разом.
Рекомендуем прочитать:
