Pse PostHog kërkon pëlqim — dhe pse përgjigja nuk është e njëjtë për çdo modul

SDK-ja web e PostHog nuk është një etiketë pasive faqeje. Në inicializimin e parazgjedhur SDK-ja vendos një ose më shumë hyrje të vazhdueshme të palës së parë — si parazgjedhje një skemë e kombinuar cookie plus localStorage e çelëzuar nën ph_{projectKey}_posthog — gjeneron një identifikues të qëndrueshëm të dallueshëm, kap pamjen fillestare të faqes me referues, parametrat UTM dhe identifikuesit e klikimeve, dhe hap një kanal ngjarjesh jetëgjatë ndaj hostit të konfiguruar të gëlltitjes. Nëse riprodhimi i sesionit është i aktivizuar në nivel projekti, SDK-ja gjithashtu fillon transmetimin e një regjistrimi të vazhdueshëm të DOM-it të paraqitur, koordinatave të miut dhe ngjarjeve të hyrjes. Nëse flamurët e funksioneve janë të konfiguruar, SDK-ja i vlerëson ato kundër identifikuesit të dallueshëm, vazhdon vendimet për sesionin dhe emeton një ngjarje $feature_flag_called për çdo vlerësim.

Secila nga këto aktivitete hartohet ndaj një porti të ndryshëm të pëlqimit. Persistimi i një identifikuesi të dallueshëm është një operacion ruajtje-dhe-qasje nën Nenin 5(3) të Direktivës ePrivacy dhe kërkon pëlqim paraprak, të dhënë lirisht, specifik, të informuar dhe të paqartë në të gjithë EEA, UK dhe çdo juridiksion që ka importuar të njëjtin standard. Kapja e ngjarjeve sjelljore është përpunim i të dhënave personale nën GDPR sepse kombinimi i identifikuesit, adresës IP dhe gjurmës sjelljore është i mjaftueshëm për të identifikuar një individ. Riprodhimi i sesionit qëndron në një kategori të veçantë, më strikte nën udhëzimin e EDPB për riprodhimin e sesionit — riprodhimi kap DOM-in e paraqitur dhe çdo fushë hyrje të pamaskuar dhe kërkon pëlqim explicit, të detajuar i cili dallon nga pëlqimi i përgjithshëm analitik. Vlerësimi i flamurit të funksionit është më delikati: një kontroll flamuri që kthen një boolean nuk kërkon vetë pëlqim, por persistimi i caktimit të flamurit të përdoruesit ndaj një identifikuesi të qëndrueshëm nëpër sesione kërkon, sepse kështu eksperimentimi i bazuar në flamur krijon të dhëna të gjurshme në nivel përdoruesi.

Çfarë shkruan PostHog para pëlqimit — dhe çfarë duhet të suprimore

SDK-ja e parazgjedhur e PostHog Browser shkruan sa vijon me inicializimin: një hyrje të kombinuar cookie dhe localStorage nën ph_{projectKey}_posthog që përmban identifikuesin e dallueshëm, identifikuesin e sesionit dhe vendimet e flamurit të funksionit, plus, kur riprodhimi i sesionit është i aktivizuar, një tampon shtesë regjistrimi në memorie që shkarkohej ndaj pikës fundore të gëlltitjes çdo disa sekonda. SDK-ja gjithashtu dërgon menjëherë një ngjarje $pageview dhe, nëse autocapture është aktiv, çdo klikim të mëpasshëm, ndërveprim formular dhe klikim të tërbuar në faqe.

Modeli i rekomanduar është të inicializosh PostHog me opt_out_capturing_by_default: true dhe disable_session_recording: true, pastaj të kthesh të dy flamurët pasi baneri i pëlqimit të kthejë një sinjal pozitiv. Ky është qëndrimi i integrimit që dokumentacioni i PostHog e rekomandon tani, dhe është qëndrimi që i mbijetojë rishikimit të rregullatorit sepse e kthen parazgjedhjen: asgjë nuk kapet deri sa të regjistrohet pëlqimi, dhe SDK-ja ofron një kalim të pastër në vend të një ripresi stateful.

Cookies, hyrjet e localStorage dhe identifikuesit që PostHog vazhdon

SDK-ja Browser 1.x shkruan një hyrje të vazhdueshme për projekt, të çelëzuar nën ph_{projectKey}_posthog, me skadim të parazgjedhur 365-ditor. Opsioni i inicializimit persistence kontrollon mekanizmin bazë: vetëm cookie, vetëm localStorage, localStorage+cookie (e parazgjedhur), sessionStorage ose memory. Për një vendosje me prioritet të pëlqimit, memory e vazhdueshme është e parazgjedhura e duhur kur pëlqimi nuk është dhënë ende — kjo siguron që asnjë identifikues të mos jetojë më gjatë se sesioni i faqes — me tranzicion ndaj localStorage+cookie pasi të ndryshojë pëlqimi. SDK-ja gjithashtu shkruan një shënues opt-in ose opt-out nën __ph_opt_in_out_{projectKey} për të kujtuar zgjedhjen e përdoruesit nëpër vizita; ky shënues vetë është një cookie rreptësisht e nevojshme sepse vazhdon një vendim të pëlqimit.

Hartimi i moduleve PostHog ndaj kornizave të pëlqimit

PostHog nuk implementon nativisht IAB TCF ose Platformën Globale të Privatësisë IAB, dhe nuk është ndërtuar si një shitës teknologjie reklamash. Megjithatë, ai integrohet me Google Consent Mode v2 nëpërmjet lidhjes nga ana e botuesit, ekspozon një API vendor opt-in dhe opt-out, dhe respekton kokën Do Not Track nëpërmjet opsionit të inicializimit respect_dnt. Modeli që funksionon në prodhim trajton çdo modul PostHog si një port të veçantë të lidhur me një sinjal specifik CMP.

• Ngjarjet e analitikës së produktit lidhen me qëllimin e analitikës. Në termat TCF kjo është më shpesh qëllimi 8 (matja e performancës së përmbajtjes) e kombinuar me qëllimin 1 (ruajtja dhe/ose qasja ndaj informacionit). Për Consent Mode kjo hartohet ndaj analytics_storage.
• Riprodhimi i sesionit qëndron pas një porti më strikt. Riprodhimi i sesionit të PostHog kap DOM-in e paraqitur dhe çdo fushë hyrje të pamaskuar, ndaj një opt-in në nivelin e preferencave ose hulumtimit i dallueshëm nga analitika është qëndrimi i mbrojtur nën udhëzimin e EDPB.
• Flamurët e funksioneve dhe eksperimentimi mund të funksionojnë me vlerësim efemer, në memorie nën një bazë interesi legjitim kur qëllimi është vetëm të ndryshojë faqen e paraqitur. Caktimi i vazhdueshëm i flamurit i lidhur me një identifikues të qëndrueshëm nëpër sesione kërkon të njëjtin pëlqim si analitika, sepse atëherë flamuri bëhet një pikë e të dhënave të gjurshme në nivel përdoruesi.
• Anketat dhe reagimet lidhen me të njëjtin port si riprodhimi i sesionit kur mbledhin hyrje me tekst të lirë, ose me portin e analitikës kur mbledhin vetëm vlerësime ose përgjigje me zgjedhje të vetme.

Modeli i integrimit që funksionon

Vendosja e referencës ka katër pjesë: një CMP që ekspozon një ngjarje të ndryshimit të pëlqimit në kohë reale, një bootstrap të shtyrë që inicializon PostHog me kapturim dhe riprodhim të çaktivizuara, një dëgjues të pëlqimit që kthen opt_in_capturing dhe çelësin e regjistrimit kur portat përkatëse hapen, dhe një shteg tërheqjeje që thërret opt_out_capturing, ndalon tamponin e riprodhimit dhe pastron identifikuesit e vazhdueshëm nëpërmjet API-së reset të SDK-së.

Implementimi Web

Modeli më i pastër është të ngarkosh SDK-në PostHog në çdo faqe, por të thërrasësh posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) si bootstrap fillestar. Abonohu ndaj ngjarjes së ndryshimit të pëlqimit të CMP. Kur kategoria e analitikës kalon ndaj true, thërrit posthog.set_config({ persistence: 'localStorage+cookie' }) e ndjekur nga posthog.opt_in_capturing(); kjo riaktivon kapturimin e ngjarjeve dhe tranzicioni i vazhdueshëm fillon të shkruajë identifikuesin e dallueshëm. Kur kategoria e riprodhimit të sesionit kalon ndaj true, thërrit posthog.startSessionRecording(). Kur njëri prej portave tërhiqet, thërrit posthog.opt_out_capturing() për portin e analitikës ose posthog.stopSessionRecording() për portin e riprodhimit, skado hyrjet e vazhdueshme përkatëse nëpërmjet posthog.reset(), dhe dërgon një kërkesë fshirjeje nëpërmjet API-së GDPR të PostHog nëse përdoruesi ka ushtruar të drejtën e fshirjes.

Zgjedhja e rajonit: PostHog Cloud US kundrejt EU kundrejt vetë-hostuar

PostHog operon dy rajone cloud — US (us.posthog.com) dhe EU (eu.posthog.com) — dhe mbështet instalimet e vetë-hostuara në infrastrukturën e vet të klientit. Për trafikun EEA dhe UK, cloud EU është parazgjedhja e duhur; ai mban gëlltitjen, përpunimin dhe ruajtjen brenda EEA dhe redukton ekspozimin Schrems II që çdo vendosje analitike në rajonin US mbart. Opsioni i inicializimit api_host fiksimin e rajonit. PostHog i vetë-hostuar e lëviz të gjithë grupin në infrastrukturën e vet të botuesit, i cili është qëndrimi më i fortë i qëndrueshmërisë së të dhënave, por nuk heq detyrimet e pëlqimit — baza ligjore ndjek të dhënat, jo operatorin. Çfarëdo opsioni të zgjidhet duhet të reflektohet në njoftimin e privatësisë dhe rekordin e kontrolluesit të përpunimit.

Kaptura nga ana e serverit

PostHog mbështet gëlltitjen e ngjarjeve nga ana e serverit nëpërmjet SDK-ve Python, Node, Go, Ruby dhe PHP. Ngjarjet nga ana e serverit nuk janë të përjashtuara nga pëlqimi — baza ligjore ndjek të dhënat — por gëlltitja nga ana e serverit i jep botuesit kontroll të plotë mbi cilat fusha emetohen dhe kur. Një model i zakonshëm është të kapturohet një grup minimal i ngjarjeve thelbësore vetëm nga serveri nën interes legjitim, pastaj të pasurojë ato ngjarje me detaje sjelljeje nga klienti vetëm pasi përdoruesi të ketë dhënë pëlqim analitik. Ngjarjet nga ana e serverit dhe klienti bashkohen me të njëjtin identifikues të dallueshëm kur pëlqimi ka ndryshuar; para pëlqimit, ngjarjet nga ana e serverit emetohen me një identifikues anonim, efemer i cili rivendoset në çdo sesion.

Validimi i integrimit dhe gjurma e auditimit

Hapi i validimit është ai që rregullatorët kontrollojnë dhe që botuesit më shpesh anashkalojnë. Një vendosje e saktë e integruar e PostHog duhet të kalojë katër teste me radhë. Së pari, një sesion i pastër shfletuesi me banerin e shfaqur por pa asnjë zgjedhje të bërë duhet të prodhojë zero kërkesa ndaj api_host të konfiguruar përtej marrjes së skedarit SDK, zero cookies ph_ në document.cookie dhe zero hyrje ph_ në localStorage. Së dyti, refuzimi i analitikës duhet ta mbajë atë gjendje — pa kapturim, pa regjistrim, pa identifikues të vazhdueshëm. Së treti, pranimi i analitikës duhet të prodhojë menjëherë një ngjarje $opt_in, hyrjen e vazhdueshme të pritur ph_{projectKey}_posthog me atribute të sakta SameSite dhe trafik ngjarjesh që rrjedh ndaj hostit të konfiguruar. Së katërti, tërheqja e pëlqimit pas faktit duhet të ndalojë menjëherë kapturimin dhe riprodhimin e mëtejshëm, të skadojë identifikuesit e vazhdueshëm dhe të aktivizojë një kërkesë fshirjeje nëpërmjet API-së GDPR të PostHog nëse përdoruesi ka ushtruar fshirjen.

Pritshmëria e gjurmës së auditimit nën udhëzimet e bannerit të cookies të EDPB të 2023 dhe prioritetet e ripërtëritura të task-forcës 2026 është se botuesi mund të provojë, për çdo ngjarje të caktuar në projektin PostHog, se përdoruesi që e gjeneroi kishte dhënë pëlqim të vlefshëm në momentin e kapturimit. Modeli standard është të vendosësh versionin e pëlqimit dhe vulën kohore si vetitë e personit ndaj ID-së së dallueshme nëpërmjet posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) në mënyrë që çdo ngjarje individuale të gjursohet deri në një hyrje specifike të regjistrit të pëlqimit. Një vendosje e gated saktë, e çiftëzuar me zgjedhjen e rajonit që përputhet me audiencën, persistence që parazgjedh memorie dhe një shteg fshirjeje që aktivizohet me tërheqjen, është ajo që e kthen PostHog nga një rrezik i përqendruar rregullator në një qendër të mbrojtur të grumbulit të analitikës së produktit.