Cookies se še vedno nastavijo po Rejectu

Zakaj je to pomembno

Reject gumb, ki optional obdelave dejansko ne blokira, je eden najjasnejših znakov, da consent mehanizem ni pravilno uveljavljen.

Kako to ročno preveriti

1. V čisti seji zavrnite optional obdelavo in nato stran ponovno naložite.
2. Po Rejectu preglejte cookies in omrežne zahtevke.
3. Primerjajte vedenje pred in po Rejectu, da potrdite dejansko ustavitev optional storagea.

Tipični vzroki

• Reject posodobi samo vizualno stanje bannerja, ne pa denied statusa.
• Optional tagi se po reloadih znova sprožijo kljub uporabnikovi zavrnitvi.
• Shranjene vrednosti soglasja se berejo napačno ali pa se po navigaciji ignorirajo.

Popravek v GTM

1. Poskrbite, da se denied stanje naloži, preden se lahko tagi po reloadu ponovno zaženejo.
2. Consent kontrole povežite z vsemi optional tagi, ne samo z dogodki ob prvem nalaganju.
3. V GTM Preview potrdite, da Reject pravilno vztraja med reloadi.

Popravek v WordPressu ali CMP vtičnikih

1. Preglejte integracije vtičnikov, ki po Rejectu še vedno nalagajo optional tage.
2. Potrdite, da CMP vtičnik shrani in uporabi denied stanje ob vsakem page loadu.
3. Odstranite prekrivajoče tracking vtičnike, ki ignorirajo CMP stanje.

Splošen developerski popravek

1. Reject obravnavajte kot izvršljivo runtime stanje, ne zgolj kot UI akcijo.
2. Na vsaki strani blokirajte optional loaderje, kadar je shranjeni status soglasja denied.
3. Testirajte scenarije reloadov, ponovnih obiskov in navigacije med stranmi, ne samo prvega nalaganja.

Kako potrditi, da popravek deluje

• Reject in reload: potrdite, da optional cookies še vedno manjkajo.
• Reject in reload: potrdite, da optional zahtevki ostanejo blokirani.
• Zaženite nov scan in preverite, da findings povezani z Rejectom izginejo.