Зашто PostHog захтева сагласност — и зашто одговор није исти за сваки модул

PostHog веб SDK није пасивна странична ознака. При подразумеваној иницијализацији SDK поставља један или више уноса трајности прве стране — подразумевано комбинована шема колачића плус localStorage означена кључем ph_{projectKey}_posthog — генерише стабилни јединствени идентификатор, хвата почетни приказ странице са упућивачем, UTM параметрима и идентификаторима кликова, и отвара дуготрајни канал за događaje ка конфигурисаном хосту за унос. Ако је снимање сесија омогућено на нивоу пројекта, SDK такође почиње да стриммује непрекидни запис приказаног DOM-а, координата миша и улазних догађаја. Ако су заставице функција конфигурисане, SDK их процењује према јединственом идентификатору, чува одлуке за сесију и емитује $feature_flag_called догађај за свако процењивање.

Свака од ових активности одговара различитом пролазу сагласности. Одржавање јединственог идентификатора је операција складиштења и приступа под чланом 5(3) Директиве о ePrivacy и захтева претходну, слободно дату, специфичну, информисану и недвосмислену сагласност у читавом EEA, UK и свакој јурисдикцији која је увела исти стандард. Хватање бихевиоралних догађаја је обрада личних података под GDPR-ом јер је комбинација идентификатора, IP адресе и бихевиоралног трага довољна за идентификацију појединца. Снимање сесија спада у посебну, строжу категорију под смерницама EDPB-а о снимању сесија — снимање хвата приказани DOM и свако неприкривено поље за унос и захтева изричиту, грануларну сагласност различиту од опште аналитичке сагласности. Евалуација заставице функције је суптилна: провера заставице која враћа булову вредност сама по себи не захтева сагласност, али одржавање корисниковог доделе заставице ка стабилном идентификатору кроз сесије захтева, јер тако експериментисање засновано на заставицама ствара пративе податке на нивоу корисника.

Шта PostHog записује пре сагласности — и шта мора бити потиснуто

Подразумевани PostHog Browser SDK записује следеће при иницијализацији: један комбиновани унос колачића и localStorage под ph_{projectKey}_posthog који садржи јединствени идентификатор, идентификатор сесије и одлуке о заставицама функција, плус, када је снимање сесије омогућено, додатни бафер за снимање у меморији који се испразњује ка крајњој тачки уноса сваких неколико секунди. SDK такође одмах шаље $pageview догађај и, ако је аутоматско снимање укључено, сваки наредни клик, интеракцију са формом и клик бесом на страници.

Препоручени образац је иницијализовати PostHog са opt_out_capturing_by_default: true и disable_session_recording: true, затим обрнути оба заставице када банер сагласности врати позитиван сигнал. Ово је интеграциони положај који PostHog документација сада препоручује, и то је положај који преживи регулаторни преглед јер инвертује подразумевано: ништа се не хвата све до евидентирања сагласности, а SDK пружа чист прелаз уместо реконфигурације са стањем.

Колачићи, LocalStorage уноси и идентификатори које PostHog чува

Browser SDK 1.x записује један унос трајности по пројекту, означен кључем ph_{projectKey}_posthog, са подразумеваним истеком од 365 дана. Опција иницијализације persistence контролише основни механизам: само cookie, само localStorage, localStorage+cookie (подразумевано), sessionStorage или memory. За имплементацију засновану на сагласности, memory трајност је прави подразумевани режим када сагласност још није дата — осигурава да ниједан идентификатор не прежivi страничну сесију — уз прелаз на localStorage+cookie када се сагласност промени. SDK такође записује маркер opt-in или opt-out под __ph_opt_in_out_{projectKey} да запамти корисников избор кроз посете; тај маркер је сам по себи строго неопходни колачић јер чува одлуку о сагласности.

Мапирање PostHog модула на оквире сагласности

PostHog не имплементира нативно IAB TCF или IAB Global Privacy Platform, и није изграђен као добављач рекламне технологије. Ипак, интегрише се са Google Consent Mode v2 кроз мостове на страни издавача, излаже нативни opt-in и opt-out API, и поштује заглавље Do Not Track кроз опцију иницијализације respect_dnt. Образац који функционише у производњи третира сваки PostHog модул као засебну капију везану за специфични CMP сигнал.

• Догађаји аналитике производа везују се за сврху аналитике. У TCF терминима, ово је најчешће сврха 8 (мерење перформанси садржаја) у комбинацији са сврхом 1 (складиштење и/или приступ информацијама). За Consent Mode ово се пресликава на analytics_storage.
• Снимање сесија стоји иза строже капије. PostHog-ово снимање сесија хвата приказани DOM и свако неприкривено поље за унос, тако да је opt-in на нивоу преференција или истраживања различит од аналитике одбрањив положај под смерницама EDPB-а.
• Заставице функција и експериментисање могу радити са ефемерном евалуацијом у меморији под основом легитимног интереса када је циљ само варирање приказане странице. Трајна додела заставице везана за стабилни идентификатор кроз сесије захтева исту сагласност као аналитика, јер тада заставица постаје пратива тачка података на нивоу корисника.
• Анкете и повратне информације везују се за исту капију као снимање сесија када прикупљају слободни текст, или за аналитичку капију када прикупљају само оцене или одговоре са јединственим избором.

Образац интеграције који функционише

Референтна имплементација има четири дела: CMP који излаже догађај промене сагласности у реалном времену, одложени bootstrap који иницијализује PostHog са онемогућеним снимањем и хватањем, слушалац сагласности који укључује opt_in_capturing и прекидач снимања када се отворе релевантне капије, и пут повлачења који позива opt_out_capturing, зауставља бафер снимања и брише трајне идентификаторе кроз SDK-ов reset API.

Веб имплементација

Најчистији образац је учитати PostHog SDK на свакој страници, али позвати posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) као почетни bootstrap. Претплатите се на CMP-ов događaj промене сагласности. Када категорија аналитике пређе на true, позовите posthog.set_config({ persistence: 'localStorage+cookie' }) праћено са posthog.opt_in_capturing(); ово поново омогућава хватање događaja и прелаз трајности почиње да записује јединствени идентификатор. Када категорија снимања сесије пређе на true, позовите posthog.startSessionRecording(). Када се нека капија повуче, позовите posthog.opt_out_capturing() за аналитичку капију или posthog.stopSessionRecording() за капију снимања, истекните релевантне уносе трајности кроз posthog.reset(), и пошаљите захтев за брисање кроз PostHog GDPR API ако је корисник затражио своје право на брисање.

Избор региона: PostHog Cloud US против EU против самостално хостованог

PostHog управља са два cloud региона — US (us.posthog.com) и EU (eu.posthog.com) — и подржава самостално хостоване инсталације на властитој инфраструктури клијента. За EEA и UK саобраћај, EU cloud је прави подразумевани; задржава унос, обраду и складиштење унутар EEA и смањује Schrems II изложеност коју носи свака аналитичка имплементација у US региону. Опција иницијализације api_host фиксира регион. Самостално хостовани PostHog помера цео стек на властиту инфраструктуру издавача, што је најјачи положај резиденције података, али не уклања обавезе сагласности — правна основа прати податке, а не оператора. Која год опција да се одабере мора бити одражена у обавештењу о приватности и евиденцији контролора обраде.

Снимање са стране сервера

PostHog подржава унос događaja са стране сервера кроз Python, Node, Go, Ruby и PHP SDK-ове. Догађаји са стране сервера нису изузети од сагласности — правна основа прати податке — али унос са стране сервера даје издавачу потпуну контролу над тим која поља се емитују и када. Уобичајени образац је снимити минималан скуп само суштинских događaja са стране сервера под легитимним интересом, затим обогатити те události бихевиоралним детаљима са клијента само након што корисник да аналитичку сагласност. Догађаји са стране сервера и клијента спајају се на исти јединствени идентификатор када се сагласност промени; пре сагласности, događaji са стране сервера се емитују са анонимним, ефемерним идентификатором који се ресетује на свакој сесији.

Валидација интеграције и ревизијски траг

Корак валидације је оно што регулатори проверавају и шта издавачи најчешће прескачу. Исправно интегрисана PostHog имплементација мора проћи четири теста у низу. Прво, чиста сесија претраживача са приказаним банером, али без донетог избора, мора произвести нула захтева ка конфигурисаном api_host осим преузимања SDK датотеке, нула ph_ колачића у document.cookie, и нула ph_ уноса у localStorage. Друго, одбијање аналитике мора задржати то стање — без хватања, без снимања, без трајног идентификатора. Треће, прихватање аналитике мора одмах произвести $opt_in događaj, очекивани унос трајности ph_{projectKey}_posthog са исправним SameSite атрибутима, и проток ereignis саобраћаја ка конфигурисаном хосту. Четврто, повлачење сагласности накнадно мора одмах зауставити даље хватање и снимање, истећи трајне идентификаторе и покренути захтев за брисање кроз PostHog GDPR API ако је корисник покренуо брисање.

Очекивање ревизијског трага под EDPB-овим смерницама за банере колачића из 2023. и обновљеним приоритетима радне групе за 2026. је да издавач може доказати, за сваки дати ereignis у PostHog пројекту, да је корисник који га је генерисао дао важећу сагласност у тренутку снимања. Стандардни образац је поставити верзију сагласности и временску ознаку као особине особе на јединственом ID кроз posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) тако да се сваки pojedinačni ereignis може пратити назад до специфичног уноса у евиденцији сагласности. Исправно конфигурисана имплементација, упарена са избором региона који одговара публици, трајношћу која подразумевано користи меморију и путом брисања који се активира на повлачењу, је оно што претвара PostHog из регулаторног ризика концентрације у одбрањиви центар стека аналитике производа.