Consimțământ cookies: Consent Mode sau blocare totală

Există două feluri de a implementa un banner de cookies, iar diferența dintre ele nu se vede în interfață. Se vede în tabul Network, în primele două sute de milisecunde de la încărcarea paginii.

Într-o variantă, tag-ul Google se încarcă imediat și trimite semnale către serverele Google chiar dacă vizitatorul n-a apăsat încă nimic. În cealaltă, nu pleacă niciun request către niciun terț până când nu există un clic. Prima variantă îți păstrează conversiile modelate în Google Ads. A doua e mai strictă legal și mult mai simplu de apărat în fața unui control. Nu le poți avea pe amândouă, iar în română aproape nimeni nu spune asta răspicat.

Ce urmează e o comparație între cele două arhitecturi, plus cele patru detalii de implementare care fac diferența dintre un banner conform și unul decorativ: categoriile pe scop, prominența refuzului, reînnoirea și ștergerea la retragere.

Ce e deja stabilit legal, și ce rămâne o decizie de arhitectură

Temeiul e Legea nr. 506/2004, articolul 4 alineatul (5): consimțământul se obține înainte de stocarea sau citirea informațiilor pe terminalul utilizatorului, iar informarea despre scop trebuie să fie anterioară exprimării acordului. Cerința ca refuzul să fie la fel de accesibil ca acceptul nu apare literal în lege — vine din definiția consimțământului din Regulamentul (UE) 2016/679, articolul 4 alineatul (11), și din practica de sancționare a autorităților europene.

Cadrul, calibrarea amenzilor din România și povestea propunerii legislative respinse în iunie 2026 sunt tratate la punctul 4 din checklist-ul legal al unui site de firmă; celelalte obligații care cad pe același site, de la identificare la accesibilitate, sunt grupate în conformitate legală web. De aici încolo articolul e despre cod: ce se încarcă, când, ce se șterge și cum dovedești.

Consent Mode avansat față de blocarea totală: două arhitecturi

Google Consent Mode e o interfață de comunicare între bannerul tău și tag-urile Google. Îi spui tag-ului starea consimțământului pe patru parametri — ad_storage, analytics_storage, ad_user_data, ad_personalization — iar tag-ul își schimbă comportamentul. Ce nu e Consent Mode: un temei legal. E un mecanism de transmitere a unei decizii pe care tot tu trebuie s-o obții valid.

Documentația Google descrie două moduri de implementare, iar diferența dintre ele e exact axa acestui articol.

Modul avansat, în request-uri

Tag-ul Google se încarcă odată cu pagina, cu toți parametrii setați pe denied ca stare implicită. Atât timp cât consimțământul e refuzat, tag-urile nu scriu și nu citesc cookie-uri — dar trimit către Google ceea ce documentația numește cookieless pings: semnale fără cookie-uri și fără identificatori persistenți, care comunică starea consimțământului și faptul că s-a produs o vizită sau un eveniment de conversie.

Le poți vedea singur. În DevTools, filtrează requesturile după collect sau google și caută parametrul gcs din query string. Valoarea are forma G1XX: cifra fixă 1 arată că modul de consimțământ e activ, iar ultimele două sunt ad_storage și analytics_storage. Deci gcs=G100 înseamnă că ambele tipuri de stocare sunt refuzate, gcs=G111 că sunt acordate. Dacă vezi gcs=G100 înainte să fi apăsat ceva, rulezi modul avansat.

1// Starea implicită, înainte de orice interacțiune cu bannerul
2gtag('consent', 'default', {
3  ad_storage: 'denied',
4  analytics_storage: 'denied',
5  ad_user_data: 'denied',
6  ad_personalization: 'denied',
7  wait_for_update: 500
8});

1// Starea implicită, înainte de orice interacțiune cu bannerul
2gtag('consent', 'default', {
3  ad_storage: 'denied',
4  analytics_storage: 'denied',
5  ad_user_data: 'denied',
6  ad_personalization: 'denied',
7  wait_for_update: 500
8});

wait_for_update e detaliul care se sare cel mai des: dă bannerului tău un interval în care să apuce să trimită starea reală înainte ca tag-ul să acționeze pe cea implicită.

Blocarea totală, în request-uri

Aici scriptul Google nu ajunge deloc în pagină până la un clic. Nu e o setare din Google, ci o proprietate a felului în care îți încarci tag-urile: platforma de consimțământ ține scripturile în așteptare și le injectează abia după decizie. Google numește asta modul de bază și îl descrie exact așa — tag-urile sunt blocate până când utilizatorul exprimă o opțiune, iar înainte de acel moment nu se transmite nimic, nici măcar starea consimțământului.

1<!-- Scriptul nu se execută: tipul e neutru pentru browser -->
2<script type="text/plain" data-consent="marketing"
3        src="https://www.googletagmanager.com/gtag/js?id=AW-XXXXXXX"></script>

1<!-- Scriptul nu se execută: tipul e neutru pentru browser -->
2<script type="text/plain" data-consent="marketing"
3        src="https://www.googletagmanager.com/gtag/js?id=AW-XXXXXXX"></script>

1// După clic pe categoria respectivă, îl promovezi la script executabil
2document.querySelectorAll('script[data-consent="marketing"]')
3  .forEach((el) => {
4    const s = document.createElement('script');
5    s.src = el.src;
6    s.async = true;
7    document.head.appendChild(s);
8  });

1// După clic pe categoria respectivă, îl promovezi la script executabil
2document.querySelectorAll('script[data-consent="marketing"]')
3  .forEach((el) => {
4    const s = document.createElement('script');
5    s.src = el.src;
6    s.async = true;
7    document.head.appendChild(s);
8  });

Zona gri: sunt ping-urile o prelucrare?

Aici sursele diverg, iar divergența e chiar informația pe care merită s-o iei cu tine.

Poziția Google e că ping-urile fără cookie-uri nu conțin identificatori persistenți și nu sunt folosite pentru urmărirea individuală, construirea de liste de remarketing sau profiluri. Poziția conservatoare, susținută de o parte din consultanții de confidențialitate și de furnizori de analytics concurenți, e că un request către un server terț transportă oricum adresa IP, URL-ul paginii și un moment de timp — deci o prelucrare de date personale care, nefiind strict necesară, ar cere consimțământ.

Niciuna dintre autoritățile europene mari nu a tranșat formal întrebarea printr-o decizie dedicată. Asta înseamnă două lucruri simultan: nu ai o interdicție pe care s-o poți invoca împotriva modului avansat, dar nici o confirmare pe care s-o poți invoca în apărarea ta. Autoritățile din Franța, Germania și Olanda au avut istoric cea mai strictă lectură pe analytics, deci dacă traficul tău e concentrat acolo, calculul de risc se schimbă.

Care e compromisul, spus răspicat

Modelarea conversiilor nu e o funcție decorativă. Când consimțământul e refuzat, Google folosește semnalele agregate ca să estimeze statistic conversiile pe care nu le mai vede direct, iar aceste estimări intră în raportare și în licitarea automată. Fără ele, algoritmul optimizează pe fracțiunea de trafic care a acceptat.

Prețul e clar: ca să existe semnale de modelat, trebuie să pleace ceva spre Google înainte de acord. Asta e tot compromisul, fără ambalaj.

Când alegi modul avansat

Când cheltuiala pe Google Ads e destul de mare ca modelarea să conteze economic și când ai volum. Modelarea nu pornește pe orice site: Google aplică praguri de trafic, iar sub ele plătești costul de risc fără să primești beneficiul. Un site cu câteva sute de sesiuni pe lună alege modul avansat degeaba.

Un al doilea criteriu, mai puțin discutat: cât de mult din decizia ta de buget depinde de cifra de conversii. Dacă licitezi manual și te uiți oricum la comenzile din back-office, modelarea îți schimbă un raport, nu o decizie.

Când alegi blocarea totală

Când nu faci publicitate plătită, sau când o faci la scară mică. Când ai clienți instituționali sau din sectoare reglementate care îți cer un răspuns simplu la întrebarea „ce pleacă de pe site înainte de acord?”. Și când vrei ca implementarea să poată fi verificată de oricine în treizeci de secunde, cu DevTools deschis — ceea ce e, în practică, cel mai bun argument de apărare pe care îl poți avea.

Ce nu îți cumpără niciunul

Consent Mode e o cerință de politică Google, nu una legală. Din 6 martie 2024 e obligatoriu pentru advertiserii care folosesc Google Ads, GA4 sau Floodlight pe trafic din Spațiul Economic European și Regatul Unit; potrivit mai multor furnizori de platforme de consimțământ care urmăresc schimbările de politică, din vara lui 2025 absența lui dezactivează efectiv urmărirea conversiilor și remarketingul pentru acel trafic. Dar niciun mod, nici bază, nici avansat, nu produce singur un consimțământ valid. Valabilitatea vine din ce urmează mai jos.

Categorii separate pe scop

Un singur da/nu care acoperă și analytics, și publicitate, nu produce un consimțământ specific. Regulamentul cere consimțământ specific pentru fiecare scop, iar analytics-ul și măsurarea campaniilor publicitare sunt scopuri diferite, cu destinatari diferiți și cu consecințe diferite pentru utilizator.

Practic: cineva poate accepta rezonabil să numeri câți oameni citesc o pagină, dar să refuze ca vizita lui să alimenteze o listă de remarketing. Un buton unic îi ia această alegere.

Maparea corectă categorie → parametru

Cele patru semnale Google nu se mapează unu-la-unu pe categoriile din banner, și acolo apar cele mai multe erori de configurare.

1// Utilizatorul a bifat statistici, a refuzat marketing
2gtag('consent', 'update', {
3  analytics_storage: 'granted',   // categoria statistici
4  ad_storage: 'denied',           // categoria marketing
5  ad_user_data: 'denied',         // tot marketing
6  ad_personalization: 'denied'    // tot marketing
7});

1// Utilizatorul a bifat statistici, a refuzat marketing
2gtag('consent', 'update', {
3  analytics_storage: 'granted',   // categoria statistici
4  ad_storage: 'denied',           // categoria marketing
5  ad_user_data: 'denied',         // tot marketing
6  ad_personalization: 'denied'    // tot marketing
7});

ad_user_data și ad_personalization sunt cei doi parametri adăugați de versiunea 2 și sunt cei mai des lăsați pe granted din neatenție. Verifică-i separat: un banner care setează corect ad_storage și greșit ad_user_data transmite un consimțământ pe care utilizatorul nu l-a dat.

Cookie-urile care nu cer consimțământ

Categoria „strict necesare” e reală, dar mai îngustă decât se folosește. Acoperă sesiunea de autentificare, coșul de cumpărături, balansarea de trafic, protecția anti-fraudă și — util de reținut — chiar cookie-ul în care stochezi decizia despre cookie-uri. Nu acoperă analytics-ul, oricât de „intern” ar fi, și nu acoperă instrumentele de înregistrare a sesiunii, care sunt urmărire comportamentală, nu măsurare.

Butonul de refuz la aceeași prominență

Dintre toate cerințele, asta e cea care produce cele mai multe sancțiuni în Europa. Nu pentru că ar fi cea mai gravă, ci pentru că e cea mai ușor de constatat: un inspector deschide site-ul și vede în două secunde dacă „Acceptă” e un buton plin și „Respinge” un link gri sub trei paragrafe.

Calibrarea din 2025 e cea mai clară de până acum. Autoritatea franceză a sancționat pe 1 septembrie 2025 două companii pe regulile de cookies: Google, cu 325 de milioane de euro, printre altele pentru module plasate la crearea contului fără consimțământ valid, și filiala irlandeză a grupului SHEIN, cu 150 de milioane de euro. Ambele decizii se întemeiază pe articolul din legea franceză care transpune aceeași directivă ePrivacy pe care o transpune la noi Legea 506/2004 — deci pe același text european care se aplică și site-ului tău.

Ce înseamnă „aceeași prominență” în CSS

Regula operațională e că refuzul trebuie să coste același număr de clicuri ca acceptul și să aibă aceeași greutate vizuală la primul nivel al bannerului. Nu „un buton de refuz există undeva”.

1/* Ambele butoane, aceeași clasă de bază; diferă doar culoarea */
2.consent-btn {
3  min-height: 44px;
4  padding: 12px 24px;
5  border-radius: 8px;
6  font-size: 16px;
7  font-weight: 600;
8  border: 2px solid currentColor;
9}
10.consent-btn--accept { background: #ff7000; color: #0f1117; }
11.consent-btn--reject { background: transparent; color: #fff1e6; }

1/* Ambele butoane, aceeași clasă de bază; diferă doar culoarea */
2.consent-btn {
3  min-height: 44px;
4  padding: 12px 24px;
5  border-radius: 8px;
6  font-size: 16px;
7  font-weight: 600;
8  border: 2px solid currentColor;
9}
10.consent-btn--accept { background: #ff7000; color: #0f1117; }
11.consent-btn--reject { background: transparent; color: #fff1e6; }

Ce încalcă regula chiar dacă butonul e prezent: refuzul mutat la al doilea nivel, în spatele unui „Preferințe”; refuzul redat ca text fără chenar lângă un buton plin; refuzul cu font mai mic; refuzul poziționat sub linia de fold a bannerului pe mobil.

Și un caz separat: închiderea bannerului cu X sau clicul în afara lui nu poate fi interpretat ca acceptare. Absența unei alegeri clare se citește ca refuz, iar continuarea navigării nu mai valorează consimțământ de la intrarea în aplicare a Regulamentului.

Durata și reînnoirea

Cookie-ul în care stochezi decizia are propria durată, iar aceasta determină cât de des reapare bannerul. Autoritatea franceză consideră, ca bună practică generală, păstrarea alegerii pentru șase luni — apreciată însă de la caz la caz, în funcție de natura site-ului și de audiența lui.

Șase luni e un reper util și pentru România, în absența unei recomandări interne echivalente: e destul de lung ca să nu hărțuiești vizitatorul și destul de scurt ca decizia să rămână informată după ce îți schimbi lista de terți.

Simetria dintre accept și refuz

Aici e defectul de implementare cel mai răspândit și cel mai puțin discutat: multe site-uri memorează acceptul pentru un an și uită refuzul la fiecare vizită. Efectul practic e că cine refuză primește bannerul de fiecare dată, până cedează. Design-ul e eficient și e exact ce descriu autoritățile ca presiune asupra libertății consimțământului.

Regula simplă: aceeași durată pentru ambele decizii, în același cookie.

1// Aceeași durată, indiferent de decizie
2const SASE_LUNI = 60 * 60 * 24 * 182;
3
4function salveazaDecizia(stare) {
5  const payload = {
6    v: 3,                              // versiunea politicii de cookies
7    t: new Date().toISOString(),       // momentul deciziei
8    c: stare                           // { statistici: false, marketing: false }
9  };
10  document.cookie =
11    `consimtamant=${encodeURIComponent(JSON.stringify(payload))}` +
12    `; Max-Age=${SASE_LUNI}; Path=/; SameSite=Lax; Secure`;
13}

1// Aceeași durată, indiferent de decizie
2const SASE_LUNI = 60 * 60 * 24 * 182;
3
4function salveazaDecizia(stare) {
5  const payload = {
6    v: 3,                              // versiunea politicii de cookies
7    t: new Date().toISOString(),       // momentul deciziei
8    c: stare                           // { statistici: false, marketing: false }
9  };
10  document.cookie =
11    `consimtamant=${encodeURIComponent(JSON.stringify(payload))}` +
12    `; Max-Age=${SASE_LUNI}; Path=/; SameSite=Lax; Secure`;
13}

Ce se pregătește la nivel european

Pachetul Digital Omnibus, publicat de Comisia Europeană pe 19 noiembrie 2025, propunea mutarea regulilor de cookies din directiva ePrivacy direct în Regulament, printr-un articol 88a care ar fi interzis re-solicitarea consimțământului pentru același scop timp de cel puțin șase luni după un refuz, și un articol 88b care ar fi obligat site-urile să respecte semnalele de preferință exprimate la nivel de browser.

Traseul e instructiv. În poziția Consiliului din 18 iunie 2026, articolul 88b a fost eliminat: semnalul de browser cade, iar bannerele per-site rămân. Articolul 88a a supraviețuit însă în textul de compromis — refuzul printr-un singur clic și interdicția de a recere consimțământul pentru același scop cel puțin șase luni după un refuz sunt încă pe masa de negociere. Organizația noyb a caracterizat eliminarea lui 88b drept o victorie a lobby-ului industriei de publicitate online. Textul nu e final, deci nu construi nimic pe el — dar reperul de șase luni de mai sus merge exact în direcția în care se îndreaptă regula.

Retragerea: pasul pe care aproape toată lumea îl sare

Un utilizator care a acceptat luna trecută intră azi în centrul de preferințe și dezactivează marketingul. Ce fac majoritatea implementărilor: actualizează starea internă și opresc încărcarea scripturilor la următoarea pagină. Ce nu fac: nimic cu cookie-urile deja puse pe dispozitiv.

Rezultatul e că _gcl_au rămâne acolo încă nouăzeci de zile și continuă să fie citit de tag-urile care se mai încarcă. Din perspectiva legii, citirea unei informații deja stocate e la fel de reglementată ca scrierea ei — articolul 4 alineatul (5) vorbește despre stocare și acces.

Nu e un scenariu teoretic. În decizia din septembrie 2025 împotriva filialei irlandeze a SHEIN, autoritatea franceză a reținut exact acest defect: când utilizatorul apăsa „Respinge tot” sau își retrăgea consimțământul, se plasau totuși module noi, iar cele deja prezente continuau să fie citite.

Cum ștergi concret

Ștergerea unui cookie înseamnă rescrierea lui cu o dată de expirare în trecut, pe același domeniu și aceeași cale. Detaliul care rupe implementările: cookie-urile Google se pun frecvent pe domeniul rădăcină, deci trebuie să încerci și varianta cu punct în față.

1const PREFIXE_MARKETING = ['_gcl_', '_gac_', '_fbp', '_fbc'];
2const RADACINA = '.' + location.hostname.split('.').slice(-2).join('.');
3
4function stergeCookiesMarketing() {
5  document.cookie.split(';').forEach((raw) => {
6    const nume = raw.split('=')[0].trim();
7    if (!PREFIXE_MARKETING.some((p) => nume.startsWith(p))) return;
8    [location.hostname, RADACINA].forEach((domeniu) => {
9      document.cookie =
10        `${nume}=; Max-Age=0; Path=/; Domain=${domeniu}`;
11    });
12    document.cookie = `${nume}=; Max-Age=0; Path=/`;
13  });
14  localStorage.removeItem('_gcl_ls');   // conversion linker scrie și aici
15}

1const PREFIXE_MARKETING = ['_gcl_', '_gac_', '_fbp', '_fbc'];
2const RADACINA = '.' + location.hostname.split('.').slice(-2).join('.');
3
4function stergeCookiesMarketing() {
5  document.cookie.split(';').forEach((raw) => {
6    const nume = raw.split('=')[0].trim();
7    if (!PREFIXE_MARKETING.some((p) => nume.startsWith(p))) return;
8    [location.hostname, RADACINA].forEach((domeniu) => {
9      document.cookie =
10        `${nume}=; Max-Age=0; Path=/; Domain=${domeniu}`;
11    });
12    document.cookie = `${nume}=; Max-Age=0; Path=/`;
13  });
14  localStorage.removeItem('_gcl_ls');   // conversion linker scrie și aici
15}

Ce nu poți șterge din JavaScript: cookie-urile terțe puse de alte domenii și cele marcate HttpOnly. Pentru acelea, singura măsură reală e să nu ajungă acolo — argument în plus pentru blocarea totală dacă publicul tău e sensibil.

Ordinea operațiilor la retragere

Trei pași, în ordinea asta: transmite starea nouă către tag-uri cu gtag('consent', 'update', ...), șterge cookie-urile din categoriile dezactivate, apoi scrie noua decizie în cookie-ul de consimțământ. Inversarea ultimelor două lasă o fereastră în care un tag se poate reinițializa pe starea veche.

Verificarea durează un minut: fereastră privată, accept, navighează două pagini, retrage din centrul de preferințe, apoi Application → Cookies. Dacă mai vezi ceva cu prefix _gcl, ștergerea nu funcționează.

Dovada consimțământului: ce e suficient pentru o firmă mică

Regulamentul cere operatorului să poată demonstra că a obținut consimțământul. Nu spune cum, iar de aici pornește o exagerare pe care merită s-o dezamorsezi: ideea că orice site are nevoie de un log server-side de consimțământ.

Minimul care ține

Pentru un site de firmă fără publicitate agresivă și fără volum mare, dovada rezonabilă e chiar cookie-ul de consimțământ, dacă îi pui înăuntru trei lucruri: decizia pe fiecare categorie, versiunea politicii de cookies afișate în momentul deciziei și data. Adaugă la asta arhivarea versiunilor politicii — un fișier în repo, cu istoric în Git, e suficient — și un screenshot al bannerului la fiecare schimbare de design.

Ce demonstrează combinația: că în ziua X, bannerul arăta așa, politica spunea asta, iar mecanismul înregistra alegerea pe categorii. Versionarea unui document legal afișat utilizatorului urmează același tipar și pentru termenii și condițiile citite ca specificație de produs: versiunea acceptată, data și textul exact, păstrate împreună. Într-o investigație pornită dintr-o sesizare, asta acoperă întrebarea reală, care e despre configurația site-ului, nu despre un utilizator anume.

Ce adaugă un log server-side

Un log server-side înseamnă că fiecare decizie ajunge într-o înregistrare pe care o controlezi tu: identificator pseudonim, moment, alegerea pe categorii, versiunea textului, uneori și amprenta cererii. Avantajul e că poți răspunde punctual — „utilizatorul cu identificatorul acesta a acceptat marketingul pe 12 martie, la versiunea 4 a politicii” — fără să depinzi de un cookie pe care utilizatorul îl poate șterge.

Costul e mai mare decât pare: un endpoint în plus, o bază de date, o politică de retenție pentru datele de consimțământ (care sunt ele însele date personale) și o linie nouă în propria ta politică de confidențialitate. Platformele comerciale de consimțământ îl includ și rețin dovezile, de regulă, doi-trei ani.

Când chiar îți trebuie

Trei situații îl fac necesar, nu opțional. Prima: consimțământul e legat de un cont, iar utilizatorul revine de pe mai multe dispozitive — cookie-ul nu poate demonstra continuitatea. A doua: transmiți date către terți pe baza consimțământului și ai obligații contractuale de a proba baza legală. A treia: ai deja un istoric de plângeri sau operezi într-un sector cu control frecvent.

În rest, un cookie bine structurat plus versionarea politicii e o poziție onestă și apărabilă. Ce nu e apărabil, indiferent de infrastructură: să nu poți spune ce afișa bannerul tău acum șase luni.

Ce rulează pe basetech.ro

O secțiune cu cărțile pe masă, pentru că exemplul de eroare e mai util decât un model teoretic.

Până în august 2026, bannerul de pe basetech.ro avea un singur da/nu, care acoperea simultan analytics-ul și măsurarea campaniilor Google Ads. În paralel, politica de cookies afirma că site-ul nu folosește cookies de marketing — în timp ce site-ul încărca tag-ul Google Ads și seta _gcl_au. Două probleme distincte din același defect de proiectare: consimțământ nespecific pe scopuri și o descriere care nu corespundea comportamentului real al paginii.

Reparat pe 15 august 2026: două categorii independente, statistici și marketing, cu parametrii Consent Mode mapați separat; refuz și accept la aceeași prominență, la primul nivel al bannerului; ștergerea cookie-urilor din categoria dezactivată la retragere, inclusiv variantele de domeniu rădăcină.

Merită reținut tiparul, nu incidentul. Defectul nu a apărut dintr-o decizie de a ignora regula, ci din felul obișnuit în care se construiește un banner: se instalează o componentă cu o categorie, se adaugă mai târziu un tag de publicitate, iar textul politicii rămâne cel scris la lansare. Nimic din stack nu semnalează divergența. Singurul mod de a o prinde e să deschizi periodic Application → Cookies pe propriul site și să compari lista cu ce scrie în pagina de politică.

Întrebări frecvente

Dacă folosesc Consent Mode, mai am nevoie de banner?

Da. Consent Mode transmite o decizie, nu o produce. Fără un mecanism care obține consimțământul valid — informare prealabilă, categorii pe scop, refuz la fel de accesibil — parametrii pe care îi trimiți către Google descriu o alegere care nu a fost făcută. Cerința legală rămâne integral asupra ta.

Analytics-ul „intern” e exceptat de la consimțământ?

Nu în forma în care îl folosește majoritatea. Excepția pentru măsurarea de audiență e îngustă: date agregate, folosite strict pentru statistici proprii, fără transmitere către terți și fără corelare cu alte prelucrări. Google Analytics 4 în configurația standard nu se încadrează, pentru că datele ajung la un terț. Instrumentele de analytics fără cookie-uri, găzduite de tine, sunt calea prin care unele site-uri ies din problemă în loc s-o gestioneze.

Pot bloca accesul la site dacă vizitatorul refuză?

Nu, dacă alternativa lipsește. Condiționarea accesului la conținut de acceptarea urmăririi face consimțământul neliber, pentru că refuzul produce un prejudiciu semnificativ. Modelul „acceptă sau plătește” e tolerat în anumite condiții, cu alternativă plătită la preț rezonabil, dar e o construcție pentru publisheri, nu pentru un site de firmă.

Cât de des trebuie să reafișez bannerul?

Aproximativ la șase luni, cu aceeași durată pentru accept și pentru refuz. În plus, la fiecare schimbare materială: adaugi un terț nou, schimbi scopul unei categorii, modifici destinatarii. O schimbare de design a bannerului nu cere reînnoire; o schimbare a listei de terți, da.

Un plugin gratuit de banner e suficient?

Depinde exclusiv de un lucru: dacă blochează efectiv scripturile sau doar afișează o fereastră. Multe pluginuri populare afișează bannerul în timp ce tag-urile s-au încărcat deja în <head>. Testul e același de fiecare dată — fereastră privată, nu apeși nimic, Application → Cookies. Dacă apar cookie-uri non-esențiale, pluginul e decorativ.

Cine răspunde dacă bannerul e configurat de o agenție?

Firma care operează site-ul, ca operator de date. Contractul cu agenția reglementează raportul dintre voi și poate include răspundere pentru prejudiciu, dar nu mută obligația față de autoritate. Practic, cere-i agenției o captură a configurației pe categorii și lista de cookie-uri pe care le acoperă fiecare.

Notă: textul acoperă implementarea, nu ține loc de consultanță juridică. Configurațiile particulare — publisheri cu parteneri publicitari multipli, aplicații mobile, prelucrări de categorii speciale — cer analiză dedicată.

Bannerul de cookies e singurul element pe care îl vede absolut fiecare vizitator și, în același timp, ultimul pe care cineva îl mai deschide după livrare. Merită pus pe lista de regresie, alături de checkout și de formularul de contact.

Există și o suprapunere pe care puțini o testează: același banner e primul element interactiv al paginii, deci și primul care poate rupe navigarea din tastatură — tratat ca tipar separat în ghidul de accesibilitate sub Legea 232/2022. Pentru o verificare pe configurația ta concretă sau o implementare care nu depinde de un plugin, vezi serviciile de dezvoltare și restul materialelor de pe hub-ul SaaS.