Bakit nangangailangan ng consent ang PostHog — at bakit hindi pareho ang sagot para sa bawat module

Ang web SDK ng PostHog ay hindi isang passive na page-tag. Sa isang default na initialization, ang SDK ay nagtatakda ng isa o higit pang mga first-party na persistence entry — bilang default isang pinagsaming cookie plus localStorage scheme na naka-key sa ilalim ng ph_{projectKey}_posthog — gumagawa ng isang stable na distinct identifier, kumukuha ng paunang pageview na may referrer, UTM parameters, at click identifiers, at nagbubukas ng matagalang event channel sa configured na ingestion host. Kung ang session replay ay enabled sa antas ng project, ang SDK ay nagsisimula ring mag-stream ng patuloy na record ng rendered DOM, mouse coordinates, at input events. Kung ang mga feature flag ay configured, ang SDK ay ini-evaluate ang mga ito laban sa distinct identifier, pine-persist ang mga desisyon para sa session, at nagpapadala ng $feature_flag_called na event para sa bawat evaluation.

Ang bawat isa sa mga aktibidad na ito ay mapa sa ibang consent gate. Ang pag-persist ng isang distinct identifier ay isang storage-and-access operation sa ilalim ng Article 5(3) ng ePrivacy Directive at nangangailangan ng prior, freely given, specific, informed, at unambiguous na consent sa buong EEA, UK, at anumang hurisdiksyon na nag-import ng parehong pamantayan. Ang pagkuha ng behavioral na mga event ay pagpoproseso ng personal na datos sa ilalim ng GDPR dahil ang kombinasyon ng identifier, IP address, at behavioral na bakas ay sapat upang matukoy ang isang indibidwal. Ang session replay ay nasa isang hiwalay, mas mahigpit na kategorya sa ilalim ng gabay ng session-replay ng EDPB — ang replay ay kumukuha ng rendered DOM at anumang unmasked na input field at nangangailangan ng explicit, granular na consent na naiiba sa generic analytics consent. Ang feature flag evaluation ay ang pinaka-delikado: ang isang flag check na nagbabalik ng boolean ay hindi mismo nangangailangan ng consent, ngunit ang pag-persist ng flag assignment ng user sa isang stable identifier sa mga session ay nangangailangan, dahil ganun lumilikha ang flag-based na eksperimento ng traceable na user-level na datos.

Kung ano ang isinusulat ng PostHog bago ang consent — at kung ano ang dapat na pigilan

Ang default na PostHog Browser SDK ay isinusulat ang mga sumusunod sa initialization: isang pinagsaming cookie at localStorage entry sa ilalim ng ph_{projectKey}_posthog na naglalaman ng distinct identifier, session identifier, at mga desisyon sa feature-flag, kasama, kapag ang session replay ay enabled, isang karagdagang in-memory recording buffer na nagfa-flush sa ingestion endpoint bawat ilang segundo. Nagpapadala rin ang SDK ng agad na $pageview na event at, kung ang autocapture ay on, bawat kasunod na click, form interaction, at rage-click sa pahina.

Ang inirekomendang pattern ay i-initialize ang PostHog na may opt_out_capturing_by_default: true at disable_session_recording: true, pagkatapos ay i-flip ang parehong flags kapag ang consent banner ay nagbabalik ng positibong signal. Ito ang integration postura na inirerekumenda na ngayon ng PostHog documentation, at ito ang postura na nakakaligtas sa pagsusuri ng regulator dahil binaliktad nito ang default: walang kinukuha hanggang mairehistro ang consent, at nagbibigay ang SDK ng malinis na transisyon sa halip na isang stateful na retrofit.

Ang mga cookies, localStorage entry, at identifier na pine-persist ng PostHog

Ang Browser SDK 1.x ay nagsusulat ng isang persistence entry bawat project, na naka-key sa ilalim ng ph_{projectKey}_posthog, na may 365-araw na expiry bilang default. Ang persistence init option ay kumokontrol sa pinagbabatayan na mekanismo: cookie lamang, localStorage lamang, localStorage+cookie (ang default), sessionStorage, o memory. Para sa isang consent-first na deployment, ang memory persistence ang tamang default kapag hindi pa nagbibigay ng consent — tinitiyak nito na walang identifier na mas matagal kaysa sa page session — na may transisyon sa localStorage+cookie kapag nag-flip ang consent. Nagsusulat din ang SDK ng opt-in o opt-out na marker sa ilalim ng __ph_opt_in_out_{projectKey} upang matandaan ang pagpili ng user sa mga pagbisita; ang marker na iyon mismo ay isang strictly-necessary na cookie dahil nagtatago ito ng desisyon sa consent.

Pag-map ng mga PostHog module sa mga consent framework

Hindi native na nagpapatupad ang PostHog ng IAB TCF o ang IAB Global Privacy Platform, at hindi ito itinayo bilang isang ad-tech vendor. Gayunpaman, nag-iintegrate ito sa Google Consent Mode v2 sa pamamagitan ng publisher-side bridging, naglalantad ng native na opt-in at opt-out API, at gumagalang sa Do Not Track header sa pamamagitan ng respect_dnt init option. Ang pattern na gumagana sa production ay tinatrato ang bawat PostHog module bilang isang hiwalay na gate na nakatali sa isang tiyak na CMP signal.

• Mga product analytics event ay nakatali sa analytics na layunin. Sa TCF terms ito ay kadalasang purpose 8 (measure content performance) na pinagsama sa purpose 1 (store and/or access information). Para sa Consent Mode ito ay nag-map sa analytics_storage.
• Ang session replay ay nasa likod ng isang mas mahigpit na gate. Kinukuha ng session replay ng PostHog ang rendered DOM at anumang unmasked na input field, kaya ang isang preferences-level o research-level na opt-in na naiiba sa analytics ang mapagtatanggol na postura sa ilalim ng gabay ng EDPB.
• Ang mga feature flag at eksperimento ay maaaring tumakbo na may ephemeral, in-memory evaluation sa ilalim ng legitimate-interest basis kapag ang layunin ay mag-iba lamang ng rendered na pahina. Ang persistent flag assignment na nakatali sa isang stable identifier sa mga session ay nangangailangan ng parehong consent gaya ng analytics, dahil doon pa lamang nagiging traceable user-level na data point ang flag.
• Mga survey at feedback ay nakatali sa parehong gate gaya ng session replay kapag nangongolekta sila ng free-text input, o sa analytics gate kapag nangongolekta lamang sila ng mga rating o single-select na tugon.

Ang integration pattern na gumagana

Ang reference deployment ay may apat na bahagi: isang CMP na naglalantad ng real-time consent change event, isang deferred bootstrap na nagini-initialize ng PostHog na may capture at replay disabled, isang consent listener na nag-fli-flip ng opt_in_capturing at ng recording switch kapag nagbubukas ang mga kaugnay na gate, at isang withdrawal path na tumatawag ng opt_out_capturing, titigil ang replay buffer, at naglilinisa ng mga persistent identifier sa pamamagitan ng reset API ng SDK.

Web implementation

Ang pinakamaling pattern ay i-load ang PostHog SDK sa bawat pahina ngunit tawagan ang posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) bilang ang paunang bootstrap. Mag-subscribe sa consent change event ng CMP. Kapag ang analytics category ay nag-transition sa true, tawagan ang posthog.set_config({ persistence: 'localStorage+cookie' }) kasunod ng posthog.opt_in_capturing(); muling nagbubukas ito ng event capture at nagsisimulang magsulat ng distinct identifier ang persistence transition. Kapag ang session-replay category ay nag-transition sa true, tawagan ang posthog.startSessionRecording(). Kapag ang alinmang gate ay umatras, tawagan ang posthog.opt_out_capturing() para sa analytics gate o posthog.stopSessionRecording() para sa replay gate, i-expire ang mga kaugnay na persistence entry sa pamamagitan ng posthog.reset(), at magpadala ng deletion request sa pamamagitan ng GDPR API ng PostHog kung nag-invoke ang user ng kanilang erasure right.

Pagpili ng rehiyon: PostHog Cloud US vs EU vs self-hosted

Nagpapatakbo ang PostHog ng dalawang cloud region — US (us.posthog.com) at EU (eu.posthog.com) — at sumusuporta sa self-hosted na mga installation sa sariling imprastraktura ng customer. Para sa trapiko ng EEA at UK, ang EU cloud ang tamang default; pinapanatili nito ang ingestion, pagpoproseso, at imbakan sa loob ng EEA at binabawasan ang Schrems II exposure na dala ng anumang US-region analytics deployment. Ang api_host init option ay nag-pi-pin ng rehiyon. Ang self-hosted na PostHog ay inililipat ang buong stack sa sariling imprastraktura ng publisher, na siyang pinakamalakas na postura ng data-residency ngunit hindi nag-aalis ng mga consent obligation — ang legal basis ay sumusunod sa datos, hindi sa operator. Anumang pagpipiliang pinili ay dapat na makita sa privacy notice at sa record of processing ng controller.

Server-side capture

Sinusuportahan ng PostHog ang server-side na event ingestion sa pamamagitan ng mga SDK ng Python, Node, Go, Ruby, at PHP. Ang mga server-side event ay hindi exempt mula sa consent — ang legal basis ay sumusunod sa datos — ngunit ang server-side ingestion ay nagbibigay sa publisher ng ganap na kontrol sa kung aling mga field ang inilalabas at kailan. Ang isang karaniwang pattern ay ang kumuha ng minimal na essential-only na event set sa server-side sa ilalim ng legitimate interest, pagkatapos ay pagyamanin ang mga event na iyon ng behavioral na detalye mula sa client pagkatapos lamang na magbigay ng analytics consent ang user. Ang mga server-side at client-side na event ay nagkakaisa sa parehong distinct identifier kapag nag-flip na ang consent; bago ang consent, ang mga server-side na event ay inilalabas na may anonymous, ephemeral identifier na nire-reset sa bawat session.

Pag-validate ng integration at ng audit trail

Ang validation step ang sinusuri ng mga regulator at ang madalas na nilalaktawan ng mga publisher. Ang isang tamang na-integrate na PostHog deployment ay dapat pumasa sa apat na test nang sunud-sunod. Una, ang isang malinis na browser session na may banner na ipinapakita ngunit walang pagpipiliang ginawa ay dapat na gumawa ng zero na kahilingan sa configured na api_host higit sa SDK file fetch, zero na mga ph_ cookie sa document.cookie, at zero na mga ph_ entry sa localStorage. Pangalawa, ang pagtanggi sa analytics ay dapat panatilihing ang estadong iyon — walang capture, walang recording, walang persistent identifier. Pangatlo, ang pagtanggap ng analytics ay dapat gumawa ng agad na $opt_in na event, ang inaasahang ph_{projectKey}_posthog persistence entry na may tamang SameSite attributes, at event traffic na dumadaloy sa configured na host. Pang-apat, ang pag-withdraw ng consent pagkatapos ay dapat agad na huminto ng karagdagang capture at replay, mag-expire ng mga persistent identifier, at mag-trigger ng deletion request sa pamamagitan ng GDPR API ng PostHog kung nag-invoke ang user ng erasure.

Ang inaasahan sa audit trail sa ilalim ng 2023 cookie banner guidelines ng EDPB at sa mga renewed na 2026 task force priorities ay ang publisher ay makakapagpatunay, para sa anumang ibinigay na event sa PostHog project, na ang user na gumawa nito ay nagbigay ng valid na consent sa sandali ng capture. Ang standard na pattern ay itakda ang consent version at timestamp bilang person properties sa distinct ID sa pamamagitan ng posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) upang ang anumang indibidwal na event ay matrace pabalik sa isang tiyak na consent log entry. Ang isang tamang naka-gate na deployment, kasama ang pagpili ng rehiyon na tumutugma sa audience, persistence na nag-default sa memory, at isang deletion path na nag-a-activate sa withdrawal, ang nagpapalit ng PostHog mula sa isang regulatory concentration risk patungong mapagtatanggol na sentro ng product analytics stack.