Чаму PWA — гэта пагранічны выпадак згоды

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

Дзе 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.
• Пры адкліканні выдаліце кэшаваныя скрыпты адсочвання і ачысціце захаваныя ідэнтыфікатары.
• Захоўвайце стан згоды свежым і бяспечным без падключэння, каб рэкламны даход не затрымліваўся на непэрсаналізаваных стаўках.