ePrivacy ломает трекинг не через GDPR, а через доступ к устройству: что проверять заранее

ePrivacy ломает трекинг не через GDPR, а через доступ к устройству: что проверять заранее

ePrivacy бьёт по тем местам, где маркетинг чаще всего «не замечает» согласие: cookies, localStorage, fingerprinting, доступ к информации на устройстве, исходящие идентификаторы в SDK и web-view. Если инструмент читает или пишет что-то в браузер до явного разрешения — это уже зона риска.

Что обычно забывают проверить:
— пиксели и теги, которые грузятся до consent;
— серверные события, если они завязаны на клиентский ID без правовой базы;
— CDN, A/B-платформы и чаты, которые ставят свои cookies;
— скрипты ретаргетинга, собирающие сигнал через fingerprinting или нестандартные storage-метки.

Отдельная ловушка — «технические» cookies. Не всё, что названо necessary, действительно необходимо. Если без этого можно показать баннер, измерить визит или персонализировать рекламу, значит, это уже не чисто служебная штука. Для аудита смотрите не название cookie, а функцию: зачем она нужна, кто её ставит, когда и можно ли жить без неё.

Что делать на практике: разделить теги на до-consent и after-consent, документировать каждый storage-объект, убрать автозагрузку рекламных пикселей, а в server-side передавать только то, на что есть база. Иначе вы просто переносите старую проблему с браузера на сервер ⚠️

Если коротко: ePrivacy — это не про текст баннера, а про то, что именно ваш стек делает с устройством до разрешения. Начинайте аудит не с юристов, а с карты всех скриптов, cookies и SDK.