Чаму PostHog патрабуе згоды — і чаму адказ не аднолькавы для кожнага модуля

Вэб-SDK PostHog — гэта не пасіўны тэг старонкі. Пры ініцыялізацыі па змаўчанні SDK усталёўвае адзін ці больш запісаў захоўвання першага боку — па змаўчанні камбінаваная схема cookie плюс localStorage, ключаваная пад ph_{projectKey}_posthog — генеруе стабільны асобны ідэнтыфікатар, захоплівае пачатковы прагляд старонкі з рэферэрам, параметрамі UTM і ідэнтыфікатарамі клікаў, і адкрывае доўгажыхалы канал падзей да настроенага хаста паглынання. Калі паўтор сеанса ўключаны на ўзроўні праекта, SDK дадаткова пачынае струменіць бесперапынны запіс рэндэраванага DOM, каардынат мышы і падзей уводу. Калі флагі функцый настроены, SDK ацэньвае іх супраць асобнага ідэнтыфікатара, захоўвае рашэнні для сеанса і выпускае падзею $feature_flag_called для кожнай ацэнкі.

Кожная з гэтых актыўнасцей супастаўляецца з рознымі варотамі згоды. Захаванне асобнага ідэнтыфікатара — гэта аперацыя захоўвання-і-доступу па Артыкуле 5(3) Дырэктывы ePrivacy і патрабуе папярэдняй, свабодна дадзенай, канкрэтнай, інфармаванай і адназначнай згоды па ўсёй ЕЭП, Вялікабрытаніі і любой юрысдыкцыі, якая імпартавала той жа стандарт. Захоп паводніцкіх падзей — гэта апрацоўка персанальных дадзеных па GDPR, бо камбінацыя ідэнтыфікатара, IP-адраса і паводніцкага следу дастатковая, каб вылучыць асобу. Паўтор сеанса сядзіць у асобнай, больш строгай катэгорыі па рэкамендацыі EDPB па паўторы сеанса — паўтор захоплівае рэндэраваны DOM і любое незамаскіраванае поле ўводу і патрабуе яўнай, гранулярнай згоды, якая адрозніваецца ад агульнай згоды на аналітыку. Ацэнка флага функцыі — тонкая: праверка флага, якая вяртае булева значэнне, сама па сабе не патрабуе згоды, але захаванне прызначэння флага карыстальніка да стабільнага ідэнтыфікатара праз сеансы патрабуе, бо менавіта так эксперыментаванне на аснове флагаў стварае адсочвальныя дадзеныя на ўзроўні карыстальніка.

Што PostHog піша да згоды — і што павінна быць падаўлена

SDK браўзера PostHog па змаўчанні піша наступнае пры ініцыялізацыі: адзін камбінаваны запіс cookie і localStorage пад ph_{projectKey}_posthog, які змяшчае асобны ідэнтыфікатар, ідэнтыфікатар сеанса і рашэнні флагаў функцый, плюс, калі паўтор сеанса ўключаны, дадатковы буфер запісу ў памяці, які скідаецца на эндпойнт паглынання кожныя некалькі секунд. SDK таксама адпраўляе неадкладную падзею $pageview і, калі ўключаны autocapture, кожны наступны клік, узаемадзеянне з формай і rage-click на старонцы.

Рэкамендаваны патэрн — ініцыялізаваць PostHog з opt_out_capturing_by_default: true і disable_session_recording: true, затым пераключыць абодва флагі, як толькі банер згоды вяртае станоўчы сігнал. Гэта пазіцыя інтэграцыі, якую цяпер рэкамендуе дакументацыя PostHog, і гэта пазіцыя, якая перажывае агляд рэгулятара, бо яна інвертуе значэнне па змаўчанні: нічога не захопліваецца да таго, як згода запісана, і SDK забяспечвае чысты пераход, а не stateful рэтрафіт.

Cookie, запісы localStorage і ідэнтыфікатары, якія захоўвае PostHog

Браўзерны SDK 1.x піша адзін запіс захоўвання на праект, ключаваны пад ph_{projectKey}_posthog, з тэрмінам дзеяння 365 дзён па змаўчанні. Опцыя ініцыялізацыі persistence кантралюе асноўны механізм: толькі cookie, толькі localStorage, localStorage+cookie (па змаўчанні), sessionStorage ці memory. Для разгортвання, якое ставіць згоду на першае месца, захоўванне memory — правільнае значэнне па змаўчанні, калі згода яшчэ не дадзена — яно гарантуе, што ніякі ідэнтыфікатар не перажыве сеанс старонкі — з пераходам да localStorage+cookie, як толькі згода пераключаецца. SDK таксама піша маркер opt-in ці opt-out пад __ph_opt_in_out_{projectKey}, каб запомніць выбар карыстальніка праз візіты; гэты маркер сам па сабе з'яўляецца строга неабходным cookie, бо ён захоўвае рашэнне згоды.

Супастаўленне модуляў PostHog з базамі згоды

PostHog не натыўна рэалізуе IAB TCF ці IAB Global Privacy Platform, і ён не пабудаваны як ad-tech пастаўшчык. Аднак ён інтэгруецца з Google Consent Mode v2 праз масток на баку выдаўца, паказвае натыўны API opt-in і opt-out, і паважае загаловак 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, спыняе буфер паўтору і ачышчае пастаянныя ідэнтыфікатары праз API скіду SDK.

Вэб-рэалізацыя

Самы чысты патэрн — загрузіць SDK PostHog на кожнай старонцы, але выклікаць 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. Калі катэгорыя аналітыкі пераходзіць у true, выклікайце posthog.set_config({ persistence: 'localStorage+cookie' }), а затым posthog.opt_in_capturing(); гэта зноў уключае захоп падзей, і пераход захоўвання пачынае пісаць асобны ідэнтыфікатар. Калі катэгорыя паўтору сеанса пераходзіць у true, выклікайце posthog.startSessionRecording(). Калі любыя вароты адклікаюцца, выклікайце posthog.opt_out_capturing() для варот аналітыкі ці posthog.stopSessionRecording() для варот паўтору, тэрмінуйце адпаведныя запісы захоўвання праз posthog.reset(), і адпраўце запыт на выдаленне праз GDPR API PostHog, калі карыстальнік выклікаў сваё права на сцiраннне.

Выбар рэгіёна: PostHog Cloud US супраць EU супраць self-hosted

PostHog кіруе двума cloud-рэгіёнамі — US (us.posthog.com) і EU (eu.posthog.com) — і падтрымлівае self-hosted усталёўкі на ўласнай інфраструктуры кліента. Для трафіку ЕЭП і Вялікабрытаніі EU cloud — правільнае значэнне па змаўчанні; ён трымае паглынанне, апрацоўку і захоўванне ўнутры ЕЭП і зніжае экспазіцыю Schrems II, якую нясе любое разгортванне аналітыкі ў рэгіёне ЗША. Опцыя ініцыялізацыі api_host замацоўвае рэгіён. Self-hosted PostHog перамяшчае ўвесь стэк на ўласную інфраструктуру выдаўца, што з'яўляецца самай моцнай пазіцыяй рэзідэнцыі дадзеных, але не выдаляе абавязацельствы згоды — прававая падстава вынікае за дадзенымі, а не за аператарам. Любая выбраная опцыя павінна быць адлюстравана ў паведамленні пра прыватнасць і запісе апрацоўкі кантролера.

Захоп на баку сервера

PostHog падтрымлівае паглынанне падзей на баку сервера праз SDK Python, Node, Go, Ruby і PHP. Падзеі на баку сервера не вызвалены ад згоды — прававая падстава вынікае за дадзенымі — але паглынанне на баку сервера дае выдаўцу поўны кантроль над тым, якія палі выпускаюцца і калі. Распаўсюджаны патэрн — захопліваць мінімальны толькі-істотны набор падзей на баку сервера пад законным інтарэсам, затым узбагачаць гэтыя падзеі паводніцкімі дэталямі з кліента толькі пасля таго, як карыстальнік даў згоду на аналітыку. Падзеі на баку сервера і на баку кліента злучаюцца на тым жа асобным ідэнтыфікатары, калі згода пераключылася; да згоды падзеі на баку сервера выпускаюцца з ананімным, эфемерным ідэнтыфікатарам, які скідаецца кожны сеанс.

Валідацыя інтэграцыі і аўдыт-след

Крок валідацыі — гэта тое, што правяраюць рэгулятары і што выдаўцы часцей за ўсё прапускаюць. Правільна інтэграванае разгортванне PostHog павінна прайсці чатыры тэсты ў паслядоўнасці. Па-першае, чысты сеанс браўзера з паказаным банерам, але без зробленага выбару, павінен вырабляць нуль запытаў да настроенага api_host па-за загрузкай файла SDK, нуль cookie ph_ у document.cookie і нуль запісаў ph_ у localStorage. Па-другое, адхіленне аналітыкі павінна трымаць гэты стан — без захопу, без запісу, без пастаяннага ідэнтыфікатара. Па-трэцяе, прыняцце аналітыкі павінна вырабляць неадкладную падзею $opt_in, чаканы запіс захоўвання ph_{projectKey}_posthog з правільнымі атрыбутамі SameSite і трафік падзей, які цячэ да настроенага хаста. Па-чацвёртае, адкліканне згоды пасля факту павінна неадкладна спыніць далейшы захоп і паўтор, тэрмінаваць пастаянныя ідэнтыфікатары і запусціць запыт на выдаленне праз GDPR API PostHog, калі карыстальнік выклікаў сцiраннне.

Чаканне аўдыт-следу па рэкамендацыях EDPB па банерах cookie 2023 года і абноўленых прыярытэтах мэтавай групы 2026 года ў тым, што выдавец можа даказаць, для любой дадзенай падзеі ў праекце PostHog, што карыстальнік, які яе згенераваў, даў сапраўдную згоду ў момант захопу. Стандартны патэрн — усталяваць версію згоды і часавую метку як уласцівасці асобы на асобным ID праз posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }), каб любая асобная падзея была адсочвальная назад да канкрэтнага запісу лога згоды. Правільна абгароджанае разгортванне, у спалучэнні з выбарам рэгіёна, які адпавядае аўдыторыі, захоўваннем, якое па змаўчанні memory, і шляхам выдалення, які актывуецца пры адкліканні, — гэта тое, што ператварае PostHog з рызыкі рэгулятарнай канцэнтрацыі ў абараняемы цэнтр стэка прадуктовай аналітыкі.