# Серверное тегирование и согласие: что меняется, а что нет

> Серверное тегирование убирает теги поставщиков из браузера, но правила согласия продолжают действовать. Что меняется, что нет и как передать согласие на сервер.

Source: https://www.cookiesh.eu/ru/blog/server-side-tagging-and-consent  
Published: 2026-09-01

## Key takeaways

- Серверное тегирование меняет то, где выполняется код поставщиков, но не отменяет необходимость согласия на сохранение или считывание данных на устройстве посетителя.
- Файлы cookie, которые устанавливает ваш сервер тегирования, все равно хранятся на устройстве посетителя, поэтому к ним по-прежнему применяются правила согласия ePrivacy.
- Каждое событие, отправляемое на ваш сервер, должно содержать состояние согласия посетителя, а сервер должен считать отсутствие согласия отказом.
- Сервер тегирования дает вам реальный контроль: вы можете удалять и минимизировать данные, прежде чем они попадут к поставщикам.
- Поставщиков, получающих данные напрямую от сервера к серверу, по-прежнему нужно раскрывать, хотя посетители больше не видят их в браузере.

Серверное тегирование переносит теги поставщиков из браузера посетителя на сервер, который вы контролируете: страница отправляет события на ваш эндпоинт, а ваш сервер пересылает их на платформы аналитики и рекламы. Это может улучшить производительность и контроль над данными, но не отменяет требований к согласию. Файлы cookie и идентификаторы по-прежнему хранятся на устройстве посетителя, а персональные данные по-прежнему попадают к поставщикам.

## Что такое серверное тегирование?

Это схема, при которой страница отправляет единый поток событий на сервер тегирования, и уже этот сервер, а не браузер, обращается к каждому поставщику. Обычно сервер работает на поддомене вашего сайта, например `metrics.example.com`.

Известный пример — серверные контейнеры Google Tag Manager, но та же схема работает и с edge-функцией или небольшим API, написанным вами самостоятельно. В классической клиентской схеме скрипт каждого поставщика выполняется в браузере посетителя и сам решает, что собирать. В серверной схеме браузер загружает меньше кода поставщиков, а поставщики получают то, что решит отправить ваш сервер.

## Что меняется при переносе тегов на сервер?

В основном производительность и контроль. Типичные преимущества:

- **Меньше кода в браузере.** Меньше скриптов поставщиков — меньше JavaScript, который нужно загрузить и выполнить, а это помогает скорости загрузки и отзывчивости.
- **Место для очистки данных.** Ваш сервер может проверять каждое событие перед пересылкой: удалять или усекать IP-адреса, убирать параметры URL, в которых могут оказаться адреса электронной почты, и удалять поля, которые поставщику не нужны.
- **Другая механика файлов cookie.** Ваш сервер может устанавливать собственные (first-party) файлы cookie через HTTP-заголовки `Set-Cookie`, а не через JavaScript. В некоторых случаях браузеры по-разному обращаются с файлами cookie, установленными скриптом и сервером, и эти правила постоянно меняются, поэтому не стройте планы в расчете на определенный срок жизни файла cookie.
- **Меньше прямых подключений к третьим сторонам.** Браузер посетителя обращается к вашему домену, а не к каждому поставщику.

## Что не меняется?

Юридическая оценка. Директиву ePrivacy и Общий регламент по защите данных (GDPR) интересует, что происходит на устройстве и что происходит с персональными данными, а не то, какой сервер стоит посередине.

| Вопрос | Клиентское тегирование | Серверное тегирование |
| --- | --- | --- |
| Хранятся ли идентификаторы на устройстве посетителя? | Да, их устанавливают скрипты поставщиков | Обычно да, их устанавливает ваш домен |
| Применяется ли согласие по ePrivacy к необязательному сохранению и доступу? | Да | Да |
| Попадают ли персональные данные к поставщикам? | Да, из браузера | Да, с вашего сервера |
| Нужно ли для каждой цели правовое основание по GDPR? | Да | Да |
| Нужно ли раскрывать посетителям получателей данных? | Да | Да |
| Кто решает, что получает каждый поставщик? | В основном скрипт поставщика | Вы |

Статья 5(3) Директивы ePrivacy касается сохранения информации на устройстве и доступа к ней. Если ваш сервер устанавливает файл cookie с идентификатором для аналитики и считывает его при каждом запросе, это сохранение информации на устройстве и доступ к ней — независимо от того, какой домен или какой код это делает. Исключение зависит от цели, то есть от того, является ли файл строго необходимым для услуги, которую запросил пользователь, а не от того, собственный ли это файл cookie; см. статью [типы файлов cookie](/ru/blog/types-of-cookies).

GDPR применяется и к данным событий. Идентификаторы, IP-адреса и URL страниц, относящиеся к человеку, являются персональными данными, поэтому для каждого потока данных к поставщику нужно правовое основание по статье 6, а если это основание — согласие, оно должно отвечать условиям статьи 7. Если на самом деле вам нужны измерения без идентификаторов, то [аналитика без файлов cookie](/ru/blog/cookieless-analytics) — это отдельный разговор.

## Как передать согласие на сервер?

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

На клиенте ничего не отправляйте без согласия и включайте его состояние в передаваемые данные:

```ts
type ConsentState = { analytics: boolean; marketing: boolean };

export function track(event: string, props: Record<string, unknown>, consent: ConsentState) {
  if (!consent.analytics && !consent.marketing) return; // ничего отправлять нельзя
  navigator.sendBeacon(
    'https://metrics.example.com/collect',
    JSON.stringify({ event, props, consent, ts: Date.now() }),
  );
}
```

На сервере пересылайте каждому получателю только то, что разрешает его категория:

```ts
export async function handleCollect(req: Request): Promise<Response> {
  const body = await req.json().catch(() => null);
  const analytics = body?.consent?.analytics === true; // отсутствие означает отказ
  const marketing = body?.consent?.marketing === true;
  if (!analytics && !marketing) return new Response(null, { status: 204 });

  const event = minimize(body); // удаляем IP, параметры запроса и неиспользуемые поля
  const jobs: Promise<unknown>[] = [];
  if (analytics) jobs.push(sendToAnalytics(event));
  if (marketing) jobs.push(sendToAdPlatform(event));
  await Promise.allSettled(jobs);

  return new Response(null, { status: 204 });
}
```

Если вы используете теги Google с режимом согласия, состояние согласия передается вместе с запросами, которые отправляют теги, а Google документирует, как его теги ведут себя при каждом сигнале. Убедитесь, что каждый тег в вашем серверном контейнере, особенно сторонние шаблоны, действительно учитывает это состояние, а не исходите из того, что так и есть. Четыре сигнала описаны в нашем [руководстве по Google Consent Mode v2](/ru/blog/google-consent-mode-v2-guide).

## Что сервер должен делать с данными?

Относитесь к серверу тегирования как к системе обработки данных со своими правилами, а не как к трубе:

1. **По умолчанию — отказ.** Отбрасывайте события с отсутствующими или некорректными полями согласия.
2. **Маршрутизируйте по целям.** Отправляйте поставщикам аналитики только события с согласием на аналитику, а рекламным поставщикам — только события с согласием на маркетинг.
3. **Минимизируйте данные перед пересылкой.** Усекайте или удаляйте IP-адреса, убирайте строки запроса и фрагменты URL и отправляйте каждому поставщику только нужные ему поля.
4. **Ограничьте срок хранения.** Необработанные журналы событий на вашем сервере — тоже персональные данные. Установите короткий срок хранения и ограничьте доступ.
5. **Документируйте каждый поток данных.** Перечислите каждого поставщика, получаемые им данные и цель в уведомлении о конфиденциальности и политике использования файлов cookie, ведь посетители больше не видят эти потоки в своем браузере.
6. **Проверяйте обе стороны.** Сканеры, работающие в браузере, не видят трафик между серверами, поэтому сочетайте регулярный [аудит файлов cookie](/ru/blog/how-to-run-a-cookie-audit) с проверкой тегов и получателей в вашем серверном контейнере.

## Итоги

Серверное тегирование меняет то, где выполняются теги, и дает вам больше контроля над тем, что получают поставщики. Оно не меняет того, когда вам нужно согласие, что считается персональными данными и что вы обязаны раскрывать. Сделайте согласие частью каждого события, проверяйте его на сервере и минимизируйте то, что с него уходит. Такие инструменты, как Cookiesh, могут предоставлять состояние согласия, необходимое вашим тегам и серверу, благодаря поддержке Google Consent Mode v2, шаблону для Google Tag Manager и JavaScript API.

*Эта статья носит общий информационный характер и не является юридической консультацией. Для решений, касающихся вашей конкретной ситуации, обратитесь к квалифицированному специалисту по защите данных.*

## FAQ

### Освобождает ли собственный поддомен файлы cookie для отслеживания от требования согласия?

Нет. Нужно ли согласие для файла cookie, зависит от его цели, а не от домена, который его устанавливает. Аналитическому или рекламному файлу cookie, установленному с вашего собственного поддомена для сбора метрик, нужно такое же согласие, как и установленному с домена поставщика.

### Нужен ли баннер cookie, если все мои теги работают на сервере?

Да, если вы используете необязательные файлы cookie или другое хранилище на устройстве либо опираетесь на согласие как на правовое основание для отправки данных поставщикам. Перенос тегов на сервер меняет то, куда данные направляются после сбора, но не согласие, необходимое для их сбора.

### Можно ли использовать серверное тегирование, чтобы обходить блокировщики рекламы?

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

### Кто отвечает за данные, которые пересылает сервер тегирования?

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

## Sources

- [Directive 2002/58/EC (ePrivacy Directive), EUR-Lex](https://eur-lex.europa.eu/eli/dir/2002/58/oj)
- [Regulation (EU) 2016/679 (GDPR), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [Google: обзор режима согласия](https://developers.google.com/tag-platform/security/guides/consent)
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en)