Мой дэйли дайджест

одно техническое понятие в день

Cookie-sync (синхронизация кук)

9 сентября 2026 · ~14 мин чтения

реклама приватность браузер adtech концепция

Cookie-sync (синхронизация кук)

Cookie-sync — процедура, в которой две рекламные системы обмениваются
своими внутренними идентификаторами одного и того же браузера и
записывают соответствие «мой ID = твой ID» в таблицу. Обмен идёт через
цепочку редиректов в браузере пользователя, заранее, до того как
понадобится показать рекламу.

История

Кука появилась в 1994 году. Придумал её Лу Монтулли (Lou Montulli),
инженер Netscape, чтобы у веб-сервера появилась память: HTTP сам по себе
не помнит, кто к нему только что приходил. Первая формальная спецификация —
RFC 2109 (1997, Крис Кристол и тот же Монтулли), потом RFC 2965 (2000),
и наконец действующий сегодня RFC 6265 (апрель 2011, редактор Адам Барт).

Кука изначально жёстко привязана к домену. Кука example.com читается
только сервером example.com. Это не баг, это фундамент безопасности —
иначе любой сайт читал бы твою сессию в банке. И вот из этого правила
вырос cookie-sync: рекламной индустрии понадобилось узнавать одного и
того же человека через границу доменов, а границу трогать нельзя.

Спрос появился вместе с программатик-аукционом. Вехи:

Итог по состоянию на сегодня: в Chrome (это большинство трафика) механизм
живой и работает, в Safari и Firefox — почти нет.

Что это такое

Представь двух участников аукциона. Слева SSP — сторона площадки, она
продаёт показ на сайте издателя. Справа DSP — сторона рекламодателя, она
покупает показы и решает, за какого пользователя сколько заплатить.

У SSP есть своя кука в браузере посетителя: скажем, ssp_uid = A123.
У DSP есть своя: dsp_uid = B987. Это один и тот же человек и один и тот
же браузер, но два разных случайных числа, и никто из двоих не может
прочитать чужое — same-origin policy (правило одного источника) не даёт.

Теперь в момент захода на страницу SSP отправляет DSP bid-запрос:
«продаю показ, ставь цену». DSP смотрит на запрос и видит A123 — строку,
которая ей ничего не говорит. Все накопленные знания у DSP лежат под
ключом B987: этот человек три дня назад смотрел двухкомнатную в
новостройке, за него готовы платить 120 рублей за тысячу показов. А под
A123 — пусто. Ставка будет минимальной или её не будет вовсе.

Cookie-sync решает ровно это. Заранее, в спокойный момент, две системы
проводят обмен и записывают у себя строчку SSP1:A123 ↔ B987. После
этого в bid-запросе SSP уже подставляет buyeruid = B987, и DSP мгновенно
узнаёт своего.

Ключевое, что важно понять: синхронизируются не данные, а ключи.
Никто не пересылает историю просмотров или профиль. Пересылается пара
чисел — «твоя метка и моя метка принадлежат одному браузеру». Профиль
остаётся там, где лежал. Это делает cookie-sync юридически скользким и
технически незаметным одновременно: по трафику это выглядит как загрузка
картинки размером 1×1 пиксель.

Cookie-sync vs фингерпринтинг. Синк — договорённость двух систем об
идентификаторе, который сам браузер и хранит. Фингерпринтинг — попытка
опознать браузер по его характеристикам (шрифты, разрешение, видеокарта)
без всякой куки и без спроса. Первое отключается очисткой кук, второе — нет.

Cookie-sync vs пиксель-счётчик. Обычный пиксель считает событие
(«зашёл на страницу», «купил»). Синк-пиксель ничего не считает — он
существует только ради редиректа, чтобы столкнуть браузер лбами с двумя
доменами подряд.

Cookie-sync vs Universal ID. Синк строит соответствие между случайными
техническими метками. Universal ID (например, UID 2.0) строит его вокруг
устойчивого якоря — обычно хешированной почты, которую ты сам ввёл.

Аналогии из жизни

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

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

Два бюро переводов с разной транслитерацией. Одно пишет «Пётр» как
Petr, второе — Pyotr. Чтобы обмениваться делами клиента, они завели
таблицу соответствий и сверяют её.

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

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

Где ломается: роуминг — это договор, регулятор, биллинг и твоё явное
согласие в тарифе. Cookie-sync происходит без договора с тобой, а часто и
без ведома владельца сайта, где всё это крутится. И IMSI в симке стабилен
годами, а кука умирает от чистки браузера, после чего всю таблицу надо
строить заново.

Как это работает

Классическая схема — цепочка редиректов (redirect chain), она же
piggybacking (езда на закорках).

Браузер                SSP-домен              DSP-домен
   |                       |                      |
   | GET /sync.gif  ------>|                      |
   |  (+ кука ssp_uid=A123)|                      |
   |                       | читает свою куку     |
   |<-- 302 Redirect ------|                      |
   |    Location: dsp/sync?ssp=SSP1&uid=A123      |
   |                       |                      |
   | GET /sync?ssp=SSP1&uid=A123 --------------->|
   |  (+ кука dsp_uid=B987)                       |
   |                       |     видит обе метки: |
   |                       |     пишет A123<->B987|
   |<---------------- 302 Redirect + пустой GIF --|
   |                       |                      |

По шагам:

  1. Пользователь открывает страницу издателя. В HTML есть невидимый
    элемент — картинка 1×1 или скрытый <iframe> (встроенный фрейм),
    указывающий на домен SSP.
  2. Браузер идёт на домен SSP. По правилам HTTP он автоматически
    прикладывает куки этого домена — ssp_uid = A123. Если куки нет,
    SSP её тут же ставит.
  3. SSP не отдаёт картинку. Она отвечает статусом 302 Redirect
    (временное перенаправление) с адресом DSP, в который свой ID вписан
    прямо в параметры URL: https://dsp.example/sync?ssp=SSP1&uid=A123.
  4. Браузер послушно идёт по редиректу на домен DSP — и снова
    автоматически прикладывает куки уже этого домена, dsp_uid = B987.
  5. DSP в одном запросе видит два числа сразу: своё B987 из куки и чужое
    A123 из URL. Пишет в match table (таблицу соответствий) строку
    SSP1:A123 ↔ B987.
  6. DSP отвечает либо пустой картинкой 1×1, либо ещё одним редиректом —
    обратно на callback-адрес SSP со своим ID, чтобы соответствие
    записали обе стороны. Двусторонний синк надёжнее, но стоит ещё один
    круг.
  7. Позже, когда человек зайдёт на страницу снова, SSP запустит аукцион
    и подставит в bid-запрос buyeruid = B987. DSP узнает своего и
    поставит осмысленную цену.

Два важных следствия из механики.

Синк всегда происходит заранее. Аукцион идёт за 100–200 миллисекунд,
внутри него на редиректы времени нет. Поэтому синк «прогревают» при любом
удобном заходе — отсюда десятки лишних запросов на каждой странице.

Цепочка ветвится. Один SSP-пиксель может редиректить не на одного
партнёра, а последовательно на пять, каждый из которых тянет ещё двух
своих. Владелец сайта поставил один счётчик — а в сетевой панели
оказывается восемь десятков доменов, о которых он никогда не слышал. Это
и есть piggybacking: партнёр второго уровня подключается «на закорках»
партнёра первого уровня, и разрешения у сайта на это никто не спрашивал.

Match rate. Совпадение никогда не полное. Часть пользователей зайдёт
на площадку и не попадёт в синк, часть почистит куки, часть сидит в
Safari. По разным оценкам индустрии типичный match rate между двумя
партнёрами — 40–70 процентов, выше 80 бывает редко. Умножь это на длину
цепочки, и станет ясно, почему таргетинг «промахивается» чаще, чем
обещают в презентациях.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Это стандартная практика всей программатик-индустрии, а не приём отдельных
компаний.

Главный вывод для владельца сайта

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

Альтернативы и конкуренты

Server-to-server синк (обмен на бэкенде).
Плюсы: не грузит браузер, не зависит от блокировок сторонних кук, быстрее
и надёжнее.
Минусы: нужен общий якорь, по которому сопоставлять (обычно хешированная
почта), нужен прямой договор между сторонами, охват заметно ниже.

Universal ID на почте (UID 2.0 от The Trade Desk, ID5, RampID от
LiveRamp).
Плюсы: работает без сторонних кук, живёт дольше, связывает устройства
одного человека.
Минусы: нужен логин или введённая почта, покрытие ограничено
залогиненной аудиторией, юридический статус в разных странах разный.

First-party ID плюс собственная CDP.
Плюсы: полный контроль, ничего не ломается от политики браузеров,
чистая история с согласиями.
Минусы: работает только внутри твоих доменов, требует своего стека и
команды, за пределами сайта пользователя не найдёшь.

Privacy Sandbox (Topics API, Protected Audience).
Плюсы: интерес считается внутри браузера, идентификатор наружу не уходит.
Минусы: только Chrome, статус инициативы менялся несколько раз, точность
таргетинга ниже, индустрия внедряет неохотно.

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

Когда НЕ стоит использовать

Проверять надо в браузере, а не в исходном коде

Синк-цепочки почти никогда не видны в HTML страницы — их разворачивает уже работающий JavaScript в скрытых фреймах. Скачивание страницы через curl покажет пустоту. Реальную картину даёт только прогон страницы в настоящем браузере с записью всех сетевых запросов.

Связанные понятия

Литература и источники

Где встретилось у меня

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

Краткое резюме