De ce PostHog necesită consimțământ — și de ce răspunsul nu este același pentru fiecare modul

SDK-ul web PostHog nu este o etichetă de pagină pasivă. La o inițializare implicită, SDK-ul setează una sau mai multe intrări de persistență de primă parte — implicit o schemă combinată de cookie și localStorage cu cheia ph_{projectKey}_posthog — generează un identificator distinct stabil, capturează vizualizarea inițială a paginii cu referitor, parametri UTM și identificatori de clic, și deschide un canal de evenimente de lungă durată către gazda de ingestie configurată. Dacă redarea sesiunii este activată la nivelul proiectului, SDK-ul începe de asemenea să transmită un înregistrare continuă a DOM-ului redat, coordonate ale mouse-ului și evenimente de intrare. Dacă flag-urile de funcționalități sunt configurate, SDK-ul le evaluează față de identificatorul distinct, persistă deciziile pentru sesiune și emite un eveniment $feature_flag_called pentru fiecare evaluare.

Fiecare dintre aceste activități corespunde unui alt poartă de consimțământ. Persistarea unui identificator distinct este o operațiune de stocare și acces în temeiul Article 5(3) din Directiva ePrivacy și necesită consimțământ prealabil, liber exprimat, specific, informat și neechivoc în SEE, Regatul Unit și orice jurisdicție care a adoptat același standard. Capturarea evenimentelor comportamentale reprezintă prelucrarea datelor cu caracter personal conform GDPR, deoarece combinația dintre identificator, adresă IP și urmă comportamentală este suficientă pentru a individualiza o persoană. Redarea sesiunii se încadrează într-o categorie separată, mai strictă, conform ghidului EDPB privind redarea sesiunii — redarea capturează DOM-ul redat și orice câmpuri de intrare neacoperite și necesită consimțământ explicit, granular, distinct de consimțământul generic pentru analiză. Evaluarea flag-urilor de funcționalități este cea subtilă: o verificare de flag care returnează un boolean nu necesită în sine consimțământ, dar persistarea atribuirii flag-ului utilizatorului la un identificator stabil între sesiuni da, deoarece astfel experimentarea bazată pe flag-uri creează date trasabile la nivel de utilizator.

Ce scrie PostHog înainte de consimțământ — și ce trebuie suprimat

SDK-ul Browser implicit PostHog scrie următoarele la inițializare: o intrare combinată de cookie și localStorage sub ph_{projectKey}_posthog care conține identificatorul distinct, identificatorul de sesiune și deciziile de flag-uri de funcționalități, plus — când redarea sesiunii este activată — un buffer suplimentar de înregistrare în memorie care se golește la endpoint-ul de ingestie la câteva secunde. SDK-ul trimite de asemenea un eveniment $pageview imediat și, dacă capturarea automată este activată, fiecare clic ulterior, interacțiune cu formularul și clic de furie pe pagină.

Modelul recomandat este de a inițializa PostHog cu opt_out_capturing_by_default: true și disable_session_recording: true, apoi să inverseze ambele flag-uri odată ce bannerul de consimțământ returnează un semnal pozitiv. Aceasta este postura de integrare pe care documentația PostHog o recomandă acum, și este postura care supraviețuiește unei revizii de reglementare deoarece inversează implicit: nimic nu este capturat până când consimțământul nu este înregistrat, iar SDK-ul oferă o tranziție curată, mai degrabă decât o modernizare stateful.

Cookie-urile, intrările localStorage și identificatorii pe care PostHog îi persistă

Browser SDK 1.x scrie o intrare de persistență per proiect, cu cheia ph_{projectKey}_posthog, cu o expirare implicită de 365 de zile. Opțiunea de inițializare persistence controlează mecanismul de bază: numai cookie, numai localStorage, localStorage+cookie (implicit), sessionStorage sau memory. Pentru o implementare consent-first, persistența memory este implicit-ul corect când consimțământul nu a fost încă acordat — asigură că niciun identificator nu supraviețuiește sesiunii paginii — cu o tranziție la localStorage+cookie odată ce consimțământul este acordat. SDK-ul scrie de asemenea un marcator opt-in sau opt-out sub __ph_opt_in_out_{projectKey} pentru a-și aminti alegerea utilizatorului între vizite; acel marcator în sine este un cookie strict necesar deoarece persistă o decizie de consimțământ.

Cartografierea modulelor PostHog la framework-uri de consimțământ

PostHog nu implementează nativ IAB TCF sau IAB Global Privacy Platform și nu este construit ca un furnizor ad-tech. Totuși, se integrează cu Google Consent Mode v2 prin bridging pe partea editorului, expune un API nativ de opt-in și opt-out și respectă antetul Do Not Track prin opțiunea de inițializare respect_dnt. Modelul care funcționează în producție tratează fiecare modul PostHog ca o poartă separată legată de un semnal CMP specific.

• Evenimentele de analiză a produsului sunt legate de scopul analitic. În termeni TCF, acesta este cel mai frecvent scopul 8 (măsurarea performanței conținutului) combinat cu scopul 1 (stocarea și/sau accesarea informațiilor). Pentru Consent Mode, aceasta corespunde la analytics_storage.
• Redarea sesiunii se află în spatele unei porți mai stricte. Redarea sesiunii PostHog capturează DOM-ul redat și orice câmpuri de intrare neacoperite, deci un opt-in de nivel preferințe sau cercetare distinct de analiză este postura defensabilă conform ghidului EDPB.
• Flag-uri de funcționalități și experimentare pot funcționa cu evaluare efemeră în memorie pe baza unui interes legitim când scopul este doar de a varia pagina redată. Atribuirea persistentă de flag legată de un identificator stabil între sesiuni necesită același consimțământ ca și analiza, deoarece atunci flag-ul devine un punct de date trasabil la nivel de utilizator.
• Sondaje și feedback sunt legate de aceeași poartă ca și redarea sesiunii când colectează text liber introdus de utilizator, sau de poarta analitică când colectează doar evaluări sau răspunsuri cu alegere unică.

Modelul de integrare care funcționează

Implementarea de referință are patru părți: un CMP care expune un eveniment de schimbare a consimțământului în timp real, un bootstrap amânat care inițializează PostHog cu capturarea și redarea dezactivate, un listener de consimțământ care inversează opt_in_capturing și comutatorul de înregistrare când se deschid porțile relevante, și o cale de retragere care apelează opt_out_capturing, oprește bufferul de redare și șterge identificatorii persistenți prin API-ul de resetare al SDK-ului.

Implementare web

Cel mai curat model este să încărcați SDK-ul PostHog pe fiecare pagină, dar să apelați posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) ca bootstrap inițial. Abonați-vă la evenimentul de schimbare a consimțământului CMP. Când categoria de analiză trece la true, apelați posthog.set_config({ persistence: 'localStorage+cookie' }) urmat de posthog.opt_in_capturing(); aceasta reactivează capturarea evenimentelor și tranziția de persistență începe să scrie identificatorul distinct. Când categoria de redare a sesiunii trece la true, apelați posthog.startSessionRecording(). Când oricare poartă este retrasă, apelați posthog.opt_out_capturing() pentru poarta analitică sau posthog.stopSessionRecording() pentru poarta de redare, expirați intrările relevante de persistență prin posthog.reset(), și trimiteți o cerere de ștergere prin API-ul GDPR al PostHog dacă utilizatorul și-a invocat dreptul de ștergere.

Selectarea regiunii: PostHog Cloud SUA vs UE vs auto-găzduit

PostHog operează două regiuni cloud — SUA (us.posthog.com) și UE (eu.posthog.com) — și suportă instalări auto-găzduite pe propria infrastructură a clientului. Pentru traficul SEE și al Regatului Unit, cloud-ul UE este implicit-ul corect; menține ingestia, prelucrarea și stocarea în SEE și reduce expunerea Schrems II pe care o poartă orice implementare de analiză în regiunea SUA. Opțiunea de inițializare api_host fixează regiunea. PostHog auto-găzduit mută întregul stack pe propria infrastructură a editorului, ceea ce reprezintă cea mai puternică poziție de rezidență a datelor, dar nu elimină obligațiile de consimțământ — baza juridică urmează datele, nu operatorul. Oricare opțiune este aleasă trebuie să fie reflectată în notificarea de confidențialitate și în registrul de activități de prelucrare al controlorului.

Capturare pe server

PostHog suportă ingestia evenimentelor pe server prin SDK-urile Python, Node, Go, Ruby și PHP. Evenimentele pe server nu sunt scutite de consimțământ — baza juridică urmează datele — dar ingestia pe server oferă editorului control deplin asupra câmpurilor emise și când. Un model comun este capturarea unui set minim de evenimente strict esențiale pe server sub interes legitim, apoi îmbogățirea acelor evenimente cu detalii comportamentale din client abia după ce utilizatorul a acordat consimțâmântul pentru analiză. Evenimentele pe server și pe client se unesc pe același identificator distinct când consimțământul a fost acordat; înainte de consimțământ, evenimentele pe server sunt emise cu un identificator anonim, efemer care este resetat la fiecare sesiune.

Validarea integrării și a traseului de audit

Pasul de validare este ceea ce verifică autoritățile de reglementare și ceea ce editorii sar cel mai des. O implementare PostHog corect integrată trebuie să treacă patru teste în secvență. În primul rând, o sesiune curată de browser cu bannerul afișat, dar fără nicio alegere făcută, trebuie să producă zero cereri la api_host configurat în afara descărcării fișierului SDK, zero cookie-uri ph_ în document.cookie și zero intrări ph_ în localStorage. În al doilea rând, refuzul analizei trebuie să mențină acea stare — fără capturare, fără înregistrare, fără identificator persistent. În al treilea rând, acceptarea analizei trebuie să producă un eveniment $opt_in imediat, intrarea de persistență așteptată ph_{projectKey}_posthog cu atributele SameSite corecte și trafic de evenimente curgând către gazda configurată. În al patrulea rând, retragerea consimțământului după fapt trebuie să oprească imediat capturarea și redarea ulterioară, să expire identificatorii persistenți și să declanșeze o cerere de ștergere prin API-ul GDPR al PostHog dacă utilizatorul a invocat ștergerea.

Așteptarea traseului de audit conform ghidurilor EDPB pentru bannere de cookie-uri din 2023 și prioritățile reînnoite ale grupului de lucru pentru 2026 este că editorul poate dovedi, pentru orice eveniment dat din proiectul PostHog, că utilizatorul care l-a generat acordase consimțământ valid la momentul capturării. Modelul standard este setarea versiunii consimțământului și a marcajului de timp ca proprietăți ale persoanei pe ID-ul distinct prin posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) astfel încât orice eveniment individual să fie trasabil înapoi la o intrare specifică în jurnalul de consimțământ. O implementare corect securizată, combinată cu selecția regiunii potrivite publicului, persistența care implicit este memorie și o cale de ștergere care se activează la retragere, este ceea ce transformă PostHog dintr-un risc de concentrare reglementară într-un centru defensabil al stack-ului de analiză a produselor.