Cookies turpina iestatīties pēc Reject

Kāpēc tas ir svarīgi

Reject poga, kas patiesībā nebloķē optional apstrādi, ir viena no skaidrākajām pazīmēm, ka piekrišanas mehānisms netiek pareizi piemērots.

Kā to pārbaudīt manuāli

1. Tīrā sesijā noraidiet optional apstrādi un pēc tam pārlādējiet lapu.
2. Pēc Reject pārskatiet cookies un tīkla pieprasījumus.
3. Salīdziniet uzvedību pirms un pēc Reject, lai apstiprinātu, ka optional storage tiešām apstājas.

Tipiski cēloņi

• Reject atjaunina tikai bannera vizuālo stāvokli, bet neizplata denied statusu.
• Optional tagi pēc reload atkal palaižas, neskatoties uz lietotāja noraidījumu.
• Saglabātās piekrišanas vērtības tiek nolasītas nepareizi vai ignorētas pēc navigācijas.

Labojums GTM

1. Pārliecinieties, ka denied statuss ielādējas pirms tagu atkārtotas palaišanas pēc reload.
2. Piesaistiet piekrišanas pārbaudes visiem optional tagiem, ne tikai sākotnējiem notikumiem.
3. GTI Preview apstipriniet, ka Reject korekti saglabājas starp reload.

Labojums WordPress vai CMP spraudņos

1. Pārskatiet spraudņu integrācijas, kas joprojām ielādē optional tagus pēc Reject.
2. Apstipriniet, ka CMP spraudnis saglabā un piemēro denied statusu katrā page load.
3. Noņemiet pārklājošos tracking spraudņus, kas ignorē CMP stāvokli.

Vispārīgs izstrādātāja labojums

1. Uztveriet Reject kā izpildāmu runtime stāvokli, ne tikai UI darbību.
2. Bloķējiet optional loaderus katrā lapā, ja saglabātais piekrišanas statuss ir denied.
3. Testējiet reload, atkārtota apmeklējuma un pārejas starp lapām scenārijus, ne tikai pirmo ielādi.

Kā apstiprināt, ka labojums darbojas

• Reject un reload: apstipriniet, ka optional cookies joprojām neparādās.
• Reject un reload: apstipriniet, ka optional pieprasījumi paliek bloķēti.
• Palaidiet jaunu scan un pārbaudiet, ka ar Reject saistītie findings pazūd.