Proč PostHog vyžaduje souhlas — a proč odpověď není pro každý modul stejná

Webový SDK PostHog není pasivní tag stránky. Při výchozí inicializaci SDK nastaví jeden nebo více záznamů pro trvalost — standardně kombinované schéma cookie a localStorage s klíčem pod ph_{projectKey}_posthog — vygeneruje stabilní odlišný identifikátor, zachytí počáteční zobrazení stránky s odkazujícím zdrojem, parametry UTM a identifikátory kliknutí a otevře dlouhotrvající kanál událostí ke konfigurovanému hostiteli pro příjem. Pokud je přehrávání relací povoleno na úrovni projektu, SDK navíc začne streamovat nepřetržitý záznam vykresleného DOM, souřadnic myši a vstupních událostí. Pokud jsou nakonfigurovány příznaky funkcí, SDK je vyhodnotí vůči odlišnému identifikátoru, uchová rozhodnutí pro relaci a vydá událost $feature_flag_called pro každé vyhodnocení.

Každá z těchto činností odpovídá jiné bráně souhlasu. Uchování odlišného identifikátoru je operace ukládání a přístupu podle Article 5(3) směrnice ePrivacy a vyžaduje předchozí, svobodný, konkrétní, informovaný a jednoznačný souhlas v EHP, UK a v jakékoli jurisdikci, která přijala stejný standard. Zachytávání behaviorálních událostí je zpracování osobních údajů podle GDPR, protože kombinace identifikátoru, IP adresy a behaviorální stopy je dostatečná k identifikaci jednotlivce. Přehrávání relací spadá do samostatné přísnější kategorie podle pokynů EDPB pro přehrávání relací — přehrávání zachycuje vykreslený DOM a jakékoli nezamaskované vstupní pole a vyžaduje výslovný, podrobný souhlas odlišný od obecného souhlasu s analýzou. Vyhodnocení příznaků funkcí je to jemné: kontrola příznaku, která vrátí logickou hodnotu, sama o sobě nevyžaduje souhlas, ale uchování přiřazení příznaku uživatele ke stabilnímu identifikátoru napříč relacemi ano, protože tak experimentování na základě příznaků vytváří sledovatelné údaje na úrovni uživatele.

Co PostHog zapisuje před souhlasem — a co musí být potlačeno

Výchozí PostHog Browser SDK při inicializaci zapisuje: jeden kombinovaný záznam cookie a localStorage pod ph_{projectKey}_posthog obsahující odlišný identifikátor, identifikátor relace a rozhodnutí o příznacích funkcí, plus při povoleném přehrávání relací dodatečný nahrávací buffer v paměti, který se každých několik sekund vyprázdní do koncového bodu příjmu. SDK také okamžitě odešle událost $pageview a při zapnutém automatickém zachytávání každé následující kliknutí, interakci s formulářem a vzteklé kliknutí na stránce.

Doporučeným vzorem je inicializovat PostHog s opt_out_capturing_by_default: true a disable_session_recording: true, poté přepnout oba příznaky, jakmile banner souhlasu vrátí kladný signál. Toto je integrační postoj, který nyní doporučuje dokumentace PostHog, a je to postoj, který přežije přezkoumání regulátorem, protože obrací výchozí nastavení: nic se nezachycuje, dokud není zaznamenán souhlas, a SDK poskytuje čistý přechod místo stavové záplaty.

Soubory cookie, záznamy localStorage a identifikátory, které PostHog uchovává

Browser SDK 1.x zapisuje jeden záznam trvalosti na projekt s klíčem pod ph_{projectKey}_posthog s výchozí platností 365 dní. Možnost inicializace persistence řídí základní mechanismus: pouze cookie, pouze localStorage, localStorage+cookie (výchozí), sessionStorage nebo memory. Pro nasazení s prioritou souhlasu je trvalost memory správným výchozím nastavením, pokud souhlas ještě nebyl udělen — zajistí, že žádný identifikátor nepřežije relaci stránky — s přechodem na localStorage+cookie po přepnutí souhlasu. SDK také zapisuje marker opt-in nebo opt-out pod __ph_opt_in_out_{projectKey}, aby si pamatoval výběr uživatele mezi návštěvami; tento marker sám o sobě je nezbytně nutným souborem cookie, protože uchovává rozhodnutí o souhlasu.

Mapování modulů PostHog na rámce souhlasu

PostHog nativně neimplementuje IAB TCF ani IAB Global Privacy Platform a není postaven jako prodejce adtech. Přesto se integruje s Google Consent Mode v2 prostřednictvím přemostění na straně vydavatele, zpřístupňuje nativní API pro opt-in a opt-out a respektuje záhlaví Do Not Track prostřednictvím možnosti inicializace respect_dnt. Vzor, který funguje v produkci, přistupuje ke každému modulu PostHog jako k samostatné bráně vázané na konkrétní signál CMP.

• Události produktové analytiky jsou vázány na analytický účel. V terminologii TCF jde nejčastěji o účel 8 (měření výkonnosti obsahu) v kombinaci s účelem 1 (ukládání informací a/nebo přístup k nim). Pro Consent Mode to odpovídá analytics_storage.
• Přehrávání relací stojí za přísnější bránou. Přehrávání relací PostHog zachycuje vykreslený DOM a jakékoli nezamaskované vstupní pole, takže opt-in na úrovni preferencí nebo výzkumu odlišný od analytiky je obhajitelný postoj podle pokynů EDPB.
• Příznaky funkcí a experimentování mohou fungovat s dočasným vyhodnocením v paměti na základě oprávněného zájmu, pokud je cílem pouze obměňovat vykreslenou stránku. Trvalé přiřazení příznaku vázané na stabilní identifikátor napříč relacemi vyžaduje stejný souhlas jako analytika, protože tehdy se příznak stává sledovatelným datovým bodem na úrovni uživatele.
• Průzkumy a zpětná vazba jsou vázány na stejnou bránu jako přehrávání relací, pokud shromažďují volný text, nebo na bránu analytiky, pokud shromažďují pouze hodnocení nebo odpovědi s jednou možností.

Integrační vzor, který funguje

Referenční nasazení má čtyři části: CMP, který zpřístupňuje událost změny souhlasu v reálném čase; odložený bootstrap, který inicializuje PostHog s deaktivovaným zachycováním a přehráváním; listener souhlasu, který přepíná opt_in_capturing a přepínač nahrávání při otevření příslušných bran; a cesta pro odvolání, která volá opt_out_capturing, zastaví buffer přehrávání a vymaže trvalé identifikátory prostřednictvím API pro resetování SDK.

Webová implementace

Nejčistší vzor je načíst SDK PostHog na každé stránce, ale jako počáteční bootstrap zavolat posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }). Přihlaste se k odběru události změny souhlasu CMP. Když kategorie analytiky přejde na true, zavolejte posthog.set_config({ persistence: 'localStorage+cookie' }) a poté posthog.opt_in_capturing(); tím se znovu aktivuje zachytávání událostí a přechod trvalosti začne zapisovat odlišný identifikátor. Když kategorie přehrávání relací přejde na true, zavolejte posthog.startSessionRecording(). Když se jakákoli brána odvolá, zavolejte posthog.opt_out_capturing() pro bránu analytiky nebo posthog.stopSessionRecording() pro bránu přehrávání, vypršejte příslušné záznamy trvalosti prostřednictvím posthog.reset() a odešlete žádost o smazání prostřednictvím GDPR API PostHog, pokud uživatel uplatnil právo na výmaz.

Výběr regionu: PostHog Cloud USA vs EU vs vlastní hosting

PostHog provozuje dva cloudové regiony — USA (us.posthog.com) a EU (eu.posthog.com) — a podporuje instalace na vlastním serveru na zákaznické infrastruktuře. Pro provoz z EHP a UK je cloudová EU správným výchozím nastavením; udržuje příjem, zpracování a ukládání v rámci EHP a snižuje expozici Schrems II, kterou nese každé nasazení analytiky v regionu USA. Možnost inicializace api_host region fixuje. PostHog na vlastním hostingu přesouvá celý zásobník na vlastní infrastrukturu vydavatele, což je nejsilnější postoj k rezidenci dat, ale neodstraňuje povinnosti souhlasu — právní základ sleduje data, nikoli provozovatele. Jakákoli zvolená možnost musí být zohledněna v oznámení o ochraně osobních údajů a v záznamu o zpracování správce.

Zachytávání na straně serveru

PostHog podporuje příjem událostí na straně serveru prostřednictvím SDK pro Python, Node, Go, Ruby a PHP. Události na straně serveru nejsou osvobozeny od souhlasu — právní základ sleduje data — ale příjem na straně serveru dává vydavateli plnou kontrolu nad tím, která pole jsou vydávána a kdy. Běžným vzorem je zachytit na straně serveru minimální sadu nezbytných událostí na základě oprávněného zájmu a poté tyto události obohatit o behaviorální detaily od klienta až poté, co uživatel udělil souhlas s analýzou. Události na straně serveru a klienta se připojí ke stejnému odlišnému identifikátoru, jakmile je souhlas přepnut; před souhlasem jsou události na straně serveru vydávány s anonymním dočasným identifikátorem, který se resetuje při každé relaci.

Ověření integrace a auditní stopa

Krok ověření je to, co regulátoři kontrolují a co vydavatelé nejčastěji vynechávají. Správně integrované nasazení PostHog musí postupně projít čtyřmi testy. Za prvé, čistá relace prohlížeče s zobrazeným bannerem, ale bez provedeného výběru, musí vytvořit nulový počet požadavků na konfigurovaný api_host kromě načtení souboru SDK, nulový počet cookies ph_ v document.cookie a nulový počet záznamů ph_ v localStorage. Za druhé, odmítnutí analytiky musí tento stav udržet — žádné zachytávání, žádné nahrávání, žádný trvalý identifikátor. Za třetí, přijetí analytiky musí vytvořit okamžitou událost $opt_in, očekávaný záznam trvalosti ph_{projectKey}_posthog se správnými atributy SameSite a tok událostí ke konfigurovanému hostiteli. Za čtvrté, odvolání souhlasu následně musí okamžitě zastavit další zachytávání a přehrávání, nechat vypršet trvalé identifikátory a spustit žádost o smazání prostřednictvím GDPR API PostHog, pokud uživatel uplatnil výmaz.

Očekávání auditní stopy podle pokynů EDPB pro bannery cookies z roku 2023 a obnovených priorit pracovní skupiny pro rok 2026 je, že vydavatel může prokázat pro jakoukoli danou událost v projektu PostHog, že uživatel, který ji vygeneroval, v okamžiku zachycení udělil platný souhlas. Standardním vzorem je nastavit verzi souhlasu a časové razítko jako vlastnosti osoby na odlišném ID prostřednictvím posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }), aby bylo možné jakoukoli jednotlivou událost sledovat zpět ke konkrétnímu záznamu v protokolu souhlasů. Správně řízené nasazení v kombinaci s výběrem regionu odpovídajícím publiku, trvalostí s výchozím nastavením memory a cestou mazání aktivovanou při odvolání je tím, co přemění PostHog z regulačního rizika koncentrace na obhajitelné centrum zásobníku produktové analytiky.