Server-side tracking и согласие

Что такое server-side tracking?

При обычном отслеживании всю работу делает браузер. Страница загружает скрипты Google, Meta и других поставщиков, и каждый скрипт отправляет данные прямо из браузера посетителя на серверы своего поставщика.

При серверном отслеживании (server-side tracking) браузер сначала отправляет данные в одно место: на сервер, который вы контролируете, обычно на поддомене вашего сайта, например metrics.example.com. Этот сервер принимает запрос, превращает его в события и решает, что и какому поставщику передать. Самый известный пример: серверный Google Tag Manager, «серверный контейнер», который работает в Google Cloud или у специализированного хостинг-провайдера рядом с обычным веб-контейнером в браузере. Типичные применения: GA4 через серверный контейнер и Meta Conversions API, с помощью которого ваш сервер отправляет конверсии напрямую в Meta.

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

Нужно ли согласие для server-side tracking?

Как и для любого другого отслеживания, действуют два набора правил (подробнее в руководстве Закон ЕС о cookie простым языком):

1. Правило о cookie: статья 5(3) Директивы ЕС о конфиденциальности и электронных коммуникациях (Директива ePrivacy) и национальные законы, которые её переносят. Сохранять информацию на устройстве посетителя или считывать её оттуда можно только с согласия, если это не строго необходимо для услуги, которую посетитель сам запросил.
2. GDPR: для обработки персональных данных нужны правовое основание, прозрачность и гарантии.

Server-side tracking не выводит вас из-под правила о cookie. Правило касается того, что происходит на устройстве, а не того, куда в итоге попадают данные. Оно действует для любой информации, независимо от того, персональные это данные или нет, что Суд ЕС подтвердил в деле Planet49 (2019). В Руководстве 2/2023 о техническом охвате статьи 5(3) Европейский совет по защите данных (EDPB) поясняет:

• сайт, который с помощью JavaScript заставляет браузер отправить информацию, получает доступ к этой информации, и это подпадает под правило;
• добавление идентификаторов в URL или в отслеживающие пиксели означает указание устройству отправить этот идентификатор обратно и тоже считается получением доступа;
• сбор уникального идентификатора, например хешированного адреса электронной почты, через код в браузере тоже подпадает под правило;
• даже отслеживание только по IP-адресу может подпадать под правило, если вы не можете гарантировать, что адрес не берётся с устройства посетителя.

Серверная схема делает именно это: тег Google в браузере отправляет события на ваш сервер, а серверный контейнер может установить cookie на вашем домене, чтобы узнавать посетителя. Поэтому собственный cookie, установленный через серверный контейнер, для аналитики или маркетинга требует согласия так же, как cookie, установленный скриптом. EDPB добавляет, что применение правила не всегда означает необходимость согласия: строго необходимое хранение освобождено, а некоторые страны допускают ограниченное измерение аудитории без согласия. Но эти исключения зависят от цели, а не от технологии, и в странах Балтии исключения для аналитики нет.

GDPR действует и на сервере

Когда данные попадают на ваш сервер, GDPR применяется ко всему, что вы с ними делаете: передаче в Google или Meta, обогащению данными заказов или CRM, построению аудиторий. Для каждой цели нужно правовое основание, а по руководству EDPB о согласии, если основанием служит согласие, его нужно получить до начала обработки.

Для рекламы и профилирования это основание на практике согласие. В деле Meta Platforms против Bundeskartellamt (C-252/21, 4 июля 2023 года) Суд ЕС постановил, что персонализированная реклама не оправдывает обработку данных пользователей Meta как законный интерес без согласия пользователя. Сайту, который передаёт данные посетителей рекламной платформе для таргетинга или измерения конверсий, будет трудно ссылаться на законный интерес там, где этого не может сама платформа. Литовская VDAI прямо напоминает, что законный интерес не подходит для необязательных cookie, а латвийская DVI называет такую ссылку одной из типичных ошибок.

Что server-side tracking действительно меняет

Server-side tracking не позволяет обойти согласие, но может сделать отслеживание бережнее к данным и проще в управлении:

• Контроль над тем, что получают поставщики. По словам Google, доступ к данным в серверном контейнере есть только у вас, пока вы сами не решите передать их дальше. Можно удалить поля, сократить URL или отбросить события до того, как они покинут ваш сервер.
• IP-адреса и идентификаторы. Можно не передавать полный IP-адрес или заменять идентификаторы перед отправкой. Это помогает минимизации данных (статья 5(1)(c) GDPR).
• Меньше сторонних запросов в браузере. Меньше скриптов поставщиков на странице означает меньше сторон, которые могут считывать данные напрямую с устройства посетителя.
• Передача данных за пределы Европы. Если ваш сервер находится в ЕС и очищает данные перед отправкой, к поставщикам за пределами Европы попадает меньше персональных данных. Французский регулятор CNIL описывает такой «прокси» для измерения аудитории при строгих условиях: IP-адрес не передаётся, идентификатор заменяется, реферер и параметры URL удаляются, никаких межсайтовых идентификаторов, а хостинг исключает передачу за пределы ЕС. CNIL представляет это как решение вопроса передачи данных, а не как повод обойтись без согласия.

Server-side tracking с cookie-баннером и Consent Mode

Рабочая схема такая же, как без серверного контейнера, с одним дополнительным шагом:

1. Cookie-баннер собирает выбор и блокирует аналитические и маркетинговые теги, пока посетитель не согласится.
2. Google Consent Mode v2 передаёт выбор дальше (см. Google Consent Mode v2 простым языком). По документации Google, Consent Mode достаточно настроить в веб-контейнере: тег Google добавляет состояние согласия к каждому запросу, который отправляет в серверный контейнер.
3. Теги Google в серверном контейнере следуют этому состоянию. В базовом режиме теги Analytics полностью блокируются, и cookie Analytics не устанавливаются и не считываются ни в браузере, ни на сервере. В расширенном режиме теги Analytics вместо этого отправляют анонимные измерения. Без согласия теги конверсий Google Ads не читают и не записывают cookie, а запросы ремаркетинга Google Ads и Floodlight блокируются.
4. Теги других поставщиков требуют вашего внимания. Google обещает это только для своих тегов. Тег Meta Conversions API или любой другой тег в серверном контейнере должен срабатывать только тогда, когда это позволяет состояние согласия; настройте это сами с помощью триггеров или условий.

Баннер вроде Cookie Confirm задаёт значения Consent Mode по умолчанию до загрузки любого тега Google и обновляет их после выбора посетителя, так что состояние согласия попадает в серверный контейнер с каждым запросом.

Meta Conversions API и согласие

Meta Conversions API связывает ваш сервер с Meta, чтобы отправлять события сайта, например покупки и заявки, не полагаясь только на Meta Pixel в браузере. Meta использует эти события для измерения и оптимизации рекламы.

Значит, это обработка в рекламных целях. Условия Meta для бизнес-инструментов (Business Tools Terms) требуют, чтобы у вас были все необходимые права и законное основание для передаваемых данных, а в странах, где для сохранения информации на устройствах или доступа к ней нужно согласие (условия называют ЕС), чтобы вы получали от посетителей подтверждаемое согласие. По этим условиям в ЕС контролёром этих данных являетесь вы. На практике:

• отправляйте события через Conversions API только по посетителям, которые приняли маркетинг в вашем баннере;
• не используйте Conversions API, чтобы «вернуть» конверсии посетителей, которые отказались;
• упомяните Meta и Conversions API в политике cookie и политике конфиденциальности.

Опция Meta «Limited Data Use» предназначена для некоторых законов о конфиденциальности отдельных штатов США. Механизмом согласия для ЕС она не является.

Что говорят регуляторы Латвии, Эстонии и Литвы

Отдельных разъяснений о server-side tracking DVI, AKI и VDAI мы не нашли. Но их общие требования к cookie прямо касаются серверных схем (подробнее в руководстве Правила о cookie в странах Балтии):

• Латвия. Инспекция государственных данных (DVI) требует согласия на аналитические и персонализирующие cookie и называет типичной ошибкой отнесение аналитических или маркетинговых cookie к «техническим». В нескольких решениях DVI указала на cookie Google Analytics, которые устанавливались до выбора или продолжали работать после отказа. Если серверный контейнер продолжает отправлять данные после отказа, это та же ошибка.
• Эстония. Инспекция по защите данных (AKI) после решения по делу Planet49 требует активного согласия на все cookie, на которые не распространяется исключение, независимо от того, обрабатываются ли персональные данные. Среди типичных ошибок AKI называет баннер, подключённый только «для вида» и не связанный с серверной частью, из-за чего cookie устанавливаются и после отказа.
• Литва. Государственная инспекция по защите данных (VDAI) требует согласия на все cookie, кроме строго необходимых, считает законный интерес неподходящим основанием для необязательных cookie и называет неверное отнесение cookie к «необходимым» нарушением.

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

• «Это без cookie, поэтому согласие не нужно». Правило о cookie шире, чем cookie: по EDPB, под него подпадают скрипты, которые заставляют браузер отправлять данные, отслеживающие пиксели, идентификаторы в URL и уникальные идентификаторы.
• «Теперь это собственные cookie». Правило не различает собственные и сторонние cookie, а также cookie от скрипта и от сервера. Решает цель.
• Отправка данных до выбора. Если серверный контейнер передаёт поставщикам просмотры страниц или конверсии до того, как посетитель нажал кнопку в баннере, вы обрабатываете данные без правового основания.
• «Хешированный адрес анонимен». Хешированный адрес электронной почты относится к псевдонимизированным данным, которые GDPR по-прежнему считает персональными (пункт 26 преамбулы). Его хешируют именно для того, чтобы платформа вроде Meta могла сопоставить его с человеком.
• Забытые теги не от Google. Consent Mode управляет только тегами Google. Каждому другому тегу в серверном контейнере нужна своя проверка согласия.
• Политика cookie не обновлена. Посетители должны знать, какие поставщики получают их данные, и тогда, когда данные сначала проходят через ваш сервер. Смотрите шаблон политики cookie и Google Analytics и GDPR.

Источники

• Директива ePrivacy 2002/58/ЕС (консолидированная версия), статья 5(3)
• Общий регламент по защите данных (ЕС) 2016/679
• EDPB: Руководство 2/2023 о техническом охвате ст. 5(3) Директивы ePrivacy
• EDPB: Руководство 05/2020 о согласии согласно Регламенту 2016/679
• Суд ЕС: дело C-673/17, Planet49 (1 октября 2019 года)
• Суд ЕС: пресс-релиз 113/23 по делу C-252/21, Meta Platforms против Bundeskartellamt (4 июля 2023 года)
• Google: Введение в серверную разметку
• Google: Режим согласия с серверным Tag Manager
• Google: Собственный домен для серверной разметки
• Meta for Developers: Conversions API
• Meta for Developers: Параметры обработки данных для пользователей из США
• Meta: Условия для бизнес-инструментов
• CNIL: Измерение аудитории и передача данных (на французском)
• Likumi.lv: Informācijas sabiedrības pakalpojumu likums, статья 7.1
• DVI: #DVIskaidro, что нужно знать о cookie (1 апреля 2022 года, на латышском)
• DVI: «Uzņēmēja ABC»: согласие, cookie и коммерческие сообщения, презентация (на латышском)
• DVI: решение по SIA «Tet», 20 марта 2025 года (на латышском)
• AKI: изменение порядка информирования о cookie, ежегодник 2019 (на эстонском)
• AKI: использование cookie, ежегодник 2021–2022 (на эстонском)
• e-seimas: Elektroninių ryšių įstatymas, статья 73
• VDAI: обзор практики использования cookie на сайтах (7 апреля 2025 года, на литовском)
• VDAI: напоминание о правильном использовании cookie (23 июля 2026 года, на литовском)