Разбор: стоит ли собирать cookie-banner самостоятельно для React и Next.js

Сделать cookie-banner своими руками кажется простой задачей. Показал уведомление, сохранил выбор, спрятал — готово. На этом простота заканчивается.

Сложность в том, что баннер должен контролировать. Настоящий баннер в production-проекте умеет блокировать сторонние скрипты до согласия, хранить настройки, позволять отозвать согласие, учитывать региональные правила и вести записи для подотчётности. Для команд на React и Next.js это отдельная инфраструктура согласия внутри приложения.

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

Что решает баннер на самом деле

В ЕС и Великобритании необязательные cookie и аналогичные технологии по общему правилу требуют согласия до загрузки. Исключение — технически необходимые cookie, как отмечает Европейский совет по защите данных; британский ICO описывает требования PECR. Отсюда инженерный вывод: нельзя просто удалить cookie после того, как скрипт отработал. Третьи стороны ставят cookie на своих доменах, используют httpOnly и хранят состояние в памяти — вы не всегда можете до них добраться.

Поэтому управление согласием происходит на границе скриптов и ресурсов. Важно не то, как выглядит попап, а то, какие скрипты, iframe и сетевые запросы могут загрузиться.

Скрытые расходы на собственный баннер

Кастомный баннер даёт максимум контроля и максимум ответственности. Вот что придётся поддерживать:

• Хранение состояния согласия.
• Категории и отдельные предпочтения.
• Блокировку скриптов до согласия.
• Изменение выбора и отзыв согласия.
• Возможность открыть диалог настроек заново.
• Доступность и работу с клавиатуры.
• Перевод и локализацию.
• Региональные правила по умолчанию.
• Версионирование политик согласия.
• Бэкенд-записи для поддержки и подотчётности.
• Тесты, доказывающие, что скрипты не грузятся раньше времени.

Браузерного хранилища может хватить маленькому сайту. Но когда команда поддержки, приваси-офицер или юристы хотят знать, что выбрал посетитель, когда и какую версию политики видел, локального хранилища недостаточно. Требование подотчётности GDPR (статья 5(2)) не предписывает конкретную схему базы данных, но бэкенд-логи часто становятся частью дизайна.

Сравнение подходов

Таблица — отправная точка, а не юридическое решение. Количество вендоров, юрисдикции, внутренние процессы и советы юристов могут сместить выбор.

Промежуточный путь: consent-инфраструктура внутри приложения

Между самоделкой и внешним виджетом есть третий вариант — фреймворк-ориентированная платформа согласия. c15t, например, интегрируется с Next.js: даёт ConsentManagerProvider, готовые баннер и диалог, App Router, hosted-режим и офлайн-режим. Настройка занимает несколько строк: в конфиге указываете режим, адрес бэкенда и список категорий — необходимые, измерение, маркетинг. Баннер и диалог рендерятся автоматически, состояние согласия доступно приложению.

Важно: такая интеграция не находит все уже подключённые скрипты. Если на сайте есть аналитика в layout, пиксель через CMS или тег из менеджера — их всё равно нужно зарегистрировать в слое согласия.

Интерфейс настраивается пропсами, дизайн-токенами, CSS-переменными или headless-компонентами. Можно оставить базовый вид, можно заменить полностью.

Где кастомные баннеры чаще всего ломаются

Баннер сохранил выбор, а скрипты всё равно загрузились. Аналитика в layout-файле, маркетинговый тег из CMS, пиксель через tag manager, SDK продукт-аналитики в клиентском компоненте — если любой из этих путей обходит баннер, он перестаёт быть источником правды.

Централизованный загрузчик скриптов решает эту проблему: каждый скрипт объявляется в одном месте и привязывается к категории согласия. Управление аналитикой, пикселями, тегами и iframe остаётся в одной точке, без разбросанных по коду проверок.

Когда согласию нужен бэкенд

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

Платформы согласия умеют хранить записи. c15t предлагает hosted-бэкенд, self-hosted или offline-режим, когда запись не нужна. Что хранить, как долго и как раскрывать — определяет юридическая проверка.

Когда свой баннер ещё имеет смысл

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

Для компаний, которые уже владеют приватность-инфраструктурой, больше подходит внутренняя платформа. Для команд, где главное — сканирование, дашборды и закупки, — dashboard-first CMP. Речь про модель управления, а не про размер компании.

Решение упирается в один вопрос: что именно контролирует баннер. Если нужно просто показать уведомление на сайте без трекинга — баннер почти не нужен. Если за ним стоят скрипты, регионы и подотчётность — собственный баннер превращается в инфраструктуру, которую придётся проектировать и поддерживать. Взвешивайте не внешний вид попапа, а объём работы вокруг него.