Cookies продължават да се задават след Reject

Защо това е важно

Reject бутон, който не блокира реално optional processing, е един от най-ясните знаци, че consent механизмът не се прилага правилно.

Как да го проверите ръчно

1. Откажете optional processing в чиста сесия и презаредете страницата.
2. Инспектирайте cookies и network requests след Reject.
3. Сравнете поведението преди и след Reject, за да потвърдите, че optional storage наистина спира.

Типични причини

• Reject обновява само визуалното състояние на banner-а, но не предава denied статус.
• Optional таговете стартират отново след reload въпреки отказа на потребителя.
• Записаните consent стойности се четат грешно или се игнорират след навигация.

Корекция в GTM

1. Уверете се, че denied статусът се прочита, преди таговете да могат да стартират отново след reload.
2. Свържете consent checks към всички optional тагове, а не само към first-load събития.
3. Потвърдете в GTM Preview, че Reject се запазва коректно между reload-ите.

Корекция в WordPress или CMP плъгини

1. Прегледайте plugin integrations, които продължават да зареждат optional тагове след Reject.
2. Потвърдете, че CMP плъгинът записва и прилага denied статус при всяко page load.
3. Премахнете припокриващи се tracking плъгини, които игнорират CMP статуса.

Обща корекция за разработчици

1. Третирайте Reject като изпълним runtime статус, а не само като UI действие.
2. Блокирайте optional loaders на всяка страница, когато записаният consent статус е denied.
3. Тествайте reload, revisit и cross-page navigation сценарии, а не само първото зареждане.

Как да потвърдите, че корекцията работи

• Reject и reload: потвърдете, че optional cookies продължават да липсват.
• Reject и reload: потвърдете, че optional requests остават блокирани.
• Пуснете нов scan и проверете, че finding-ите, свързани с Reject, изчезват.