Server-side tracking и DSGVO — как настроить в Германии без штрафов?

Не ведитесь на сказки агентств в стиле «перенесли на сервер избавились от кук — согласие не нужно». Немецкие надзорные органы (особенно в Баварии и Баден-Вюртемберге) прекрасно знают эту схему. Как только вы прочитали с устройства хоть один байт в маркетинговых целях, вы сразу попадаете под TDDDG без вариантов.

В плане технической архитектуры ключевой момент такой: если ваш серверный контейнер передает в рекламную систему сырой IP, User-Agent и реферер из входящего запроса, это прямо считается передачей персональных данных. На своем прокси нужно обрезать последний октет IP-адреса и огрублять таймстемпы.

Не путайте два разных закона: статья 25 TDDDG регулирует именно доступ к устройству (куки или фингерпринтинг) и требует согласия. А статья 6 DSGVO регулирует последующую обработку уже полученных персданных (например, IP-адреса). Даже если серверный трекинг дает вам больше контроля с точки зрения DSGVO, барьер TDDDG он сам по себе не снимает.

edit: выше написал неправильно, извините.

Мы подняли похожую схему на отдельной машине во Франкфурте. На сервер уходит около 80 EUR в месяц. Передаем через сервер события только тех пользователей, кто дал добро в баннере. Потери данных из-за блокировщиков рекламы упали с 28% до 9%, но без согласия мы не отправляем ни строчки.

В прошлом году один консультант нам подкинул ту же идею, и мы отключили баннер согласия. Через два месяца прилетела претензия (Abmahnung) от юриста конкурентов: попали на 1.800 EUR судебных издержек плюс штраф по обязательству. Срочно вернули старую систему с согласием. В Германии этот риск точно того не стоит.

Контейнер на стороне сервера будет размещаться в дата-центре на территории ЕС? Планируете ли вы при отправке данных в рекламные сети сопоставлять офлайн-идентификаторы клиентов (например, хешированные email)?

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

Если в штате вашей компании или на аутсорсе есть сотрудник по защите данных (Datenschutzbeauftragter), то проверка этого изменения архитектуры в рамках оценки воздействия на защиту данных (DSFA) является законным требованием. Также обязательно обновить политику конфиденциальности (Datenschutzerklärung), чтобы она отражала эти новые потоки данных.

Именно так, и при этом об этом мало кто знает. Первые три месяца все идет хорошо, проблемы всплывают на четвертом.

Конечно, если ваша ситуация отличается, всё меняется.

Буду рад, если напишете о результате. Пытаться сделать это в одиночку — самый дорогой путь.

Если я правильно понял, вы имеете в виду следующее: Начните с небольшого эксперимента, не привязывайте всё сразу.

Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Вы правы. Чем сложнее отменить решение, тем медленнее его принимайте.

То, что делают все, не значит, что это правильно. Я бы пошел этим путем.

в этом пункте я с вами не согласен. если разрешение и объем тестирования не зафиксированы письменно тест не начинать.

на этом всё, извините, если затянул.

Согласен с этим. Не полагайтесь на одну меру защиты; действуйте слоями.

Надеюсь, это будет полезно.

Я тоже об этом думал. Большая часть потерь времени копится на задачах, ожидающих согласования.

Пишите, если есть вопросы, отвечу по мере возможности.

Согласен с этим. Спешка в решениях оборачивается исправлениями через полгода.

Проверено опытом.

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

Пытаться сделать это в одиночку — самый дорогой путь.

не знал об этом. изменение платежных данных никогда не подтверждается через тот же канал.

исправьте, если я ошибаюсь.