Чому 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.
• При відкликанні очищайте кешовані скрипти відстеження та видаляйте збережені ідентифікатори.
• Тримайте стан згоди свіжим і безпечним для офлайну, щоб дохід від реклами не застрягав на неперсоналізованих ставках.