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

Прогрессивное веб-приложение ведёт себя как нативное приложение — оно устанавливается на главный экран, работает офлайн и агрессивно кэширует — но всё равно обслуживается из браузера, поэтому применяются правила для cookie и веб-хранилища. Именно эта гибридная природа сбивает издателей с толку: те же обязательства по согласию GDPR, что и для любого сайта, поверх которых накладываются service worker и постоянные кэши, которые могут тихо сохранять данные и скрипты после того, как пользователь сказал нет.

Где PWA хранят данные

Прежде чем ограничивать хранение согласием, нужно знать каждое место, где PWA может сохранять данные:

• Cookie — классическая поверхность, управляемая согласием, как всегда.
• LocalStorage / IndexedDB — часто используются для состояния приложения, но также для аналитики и рекламных идентификаторов.
• Cache Storage — service worker может кэшировать сторонние скрипты (аналитику, рекламные SDK), чтобы они работали даже офлайн.
• Сам service worker — сохраняется между сеансами и может повторно зарегистрировать отслеживание при следующем запуске.

Согласие должно управлять всем этим, а не только document.cookie.

Паттерн service worker «согласие прежде всего»

Основной принцип: service worker должен считать состояние согласия, прежде чем кэшировать или выполнять любой несущественный сторонний ресурс. Чистый паттерн выглядит так:

• Храните сигнал согласия там, где service worker может его считать — IndexedDB или запись в кэше, которую CMP обновляет при каждом выборе.
• В обработчике fetch service worker откажитесь кэшировать конечные точки аналитики/рекламы, если нет согласия на соответствующую цель.
• Когда пользователь отзывает согласие, отправьте сообщение service worker, чтобы очистить кэшированные скрипты отслеживания и очистить соответствующие хранилища IndexedDB.

Пропуск этого последнего шага — самый распространённый пробел в соответствии PWA: баннер говорит “отклонено,” но кэшированный скрипт аналитики продолжает срабатывать из service worker при следующем офлайн-запуске.

UX согласия в офлайне

PWA могут запускаться без сети. Ваш баннер согласия и сохранённый выбор пользователя должны оба работать офлайн — кэшируйте сам интерфейс CMP и никогда не устанавливайте по умолчанию “предоставлено” лишь потому, что сервер согласия недоступен. Если вы не можете подтвердить предыдущий выбор, относитесь к пользователю как к не давшему согласия и предоставляйте только существенную функциональность, пока не сможете.

Последствия для дохода от рекламы

Для PWA, поддерживаемых рекламой, состояние согласия должно достигнуть вашего рекламного SDK в момент запроса, онлайн или офлайн. Правильно подключённый PWA передаёт строку IAB TCF и сигналы Consent Mode v2 партнёрам спроса так же, как обычный сайт; неправильно настроенный кэширует устаревшее состояние “нет согласия” и обрушивает ваш eCPM до неперсонализированных ставок на неопределённый срок. Относитесь к свежести согласия как к метрике дохода.

Как помогает FlexyConsent

FlexyConsent хранит запись согласия в хранилище, доступном для service worker, выдаёт сигналы TCF и Consent Mode v2, которые переживают офлайн-запуски, и предоставляет хук отзыва, который вы можете подключить к очистке кэша — так что ваш PWA остаётся соответствующим, а ваш рекламный стек сохраняет максимально свежий возможный сигнал согласия на каждой поверхности.

Ключевые выводы

• PWA сталкиваются с полными обязанностями по согласию GDPR плюс осложнениями с service worker и кэшем.
• Ограничивайте cookie, LocalStorage, IndexedDB и Cache Storage согласием — не только cookie.
• При отзыве очищайте кэшированные скрипты отслеживания и удаляйте сохранённые идентификаторы.
• Держите состояние согласия свежим и безопасным для офлайна, чтобы доход от рекламы не застревал на неперсонализированных ставках.