Dlaczego PostHog wymaga zgody — i dlaczego odpowiedź nie jest taka sama dla każdego modułu

Webowy SDK PostHog nie jest pasywnym tagiem strony. Przy domyślnej inicjalizacji SDK ustawia jeden lub więcej wpisów trwałości pierwszej strony — domyślnie kombinowany schemat pliku cookie i localStorage pod kluczem ph_{projectKey}_posthog — generuje stabilny unikalny identyfikator, przechwytuje początkowe wyświetlenie strony z referrerem, parametrami UTM i identyfikatorami kliknięć, a następnie otwiera długotrwały kanał zdarzeń do skonfigurowanego hosta pozyskiwania. Jeśli odtwarzanie sesji jest włączone na poziomie projektu, SDK dodatkowo zaczyna strumieniować ciągły zapis wyrenderowanego DOM, współrzędnych myszy i zdarzeń wejściowych. Jeśli flagi funkcji są skonfigurowane, SDK ocenia je względem unikalnego identyfikatora, utrwala decyzje na czas sesji i emituje zdarzenie $feature_flag_called dla każdej oceny.

Każda z tych czynności odpowiada innej bramce zgody. Utrwalanie unikalnego identyfikatora jest operacją przechowywania i dostępu w rozumieniu Article 5(3) dyrektywy ePrivacy i wymaga uprzedniej, swobodnie wyrażonej, konkretnej, świadomej i jednoznacznej zgody w całym EOG, UK i każdej jurysdykcji, która przyjęła ten sam standard. Przechwytywanie zdarzeń behawioralnych stanowi przetwarzanie danych osobowych w rozumieniu GDPR, ponieważ kombinacja identyfikatora, adresu IP i śladu behawioralnego jest wystarczająca do wyróżnienia osoby. Odtwarzanie sesji należy do odrębnej, bardziej rygorystycznej kategorii zgodnie z wytycznymi EDPB dotyczącymi odtwarzania sesji — odtwarzanie przechwytuje wyrenderowany DOM i wszelkie niemaskowane pola wejściowe i wymaga wyraźnej, szczegółowej zgody, odrębnej od ogólnej zgody na analitykę. Ocena flag funkcji jest subtelna: sprawdzenie flagi zwracające wartość logiczną samo w sobie nie wymaga zgody, ale utrwalanie przypisania flagi użytkownika do stabilnego identyfikatora w sesjach już tak, ponieważ w ten sposób eksperymentowanie oparte na flagach tworzy identyfikowalne dane na poziomie użytkownika.

Co PostHog zapisuje przed udzieleniem zgody — i co należy wyeliminować

Domyślny Browser SDK PostHog zapisuje podczas inicjalizacji: jeden kombinowany wpis pliku cookie i localStorage pod kluczem ph_{projectKey}_posthog zawierający unikalny identyfikator, identyfikator sesji i decyzje dotyczące flag funkcji, a ponadto — gdy odtwarzanie sesji jest włączone — dodatkowy bufor nagrywania w pamięci, który opróżnia się do endpointu pozyskiwania co kilka sekund. SDK wysyła też natychmiastowe zdarzenie $pageview i — jeśli automatyczne przechwytywanie jest włączone — każde kolejne kliknięcie, interakcję z formularzem i kliknięcie z frustracji na stronie.

Zalecany wzorzec polega na inicjalizacji PostHog z parametrami opt_out_capturing_by_default: true i disable_session_recording: true, a następnie odwróceniu obu flag po tym, jak baner zgody zwróci pozytywny sygnał. Jest to pozycja integracji, którą dokumentacja PostHog teraz zaleca, i jest to pozycja, która przetrwa przegląd regulatora, ponieważ odwraca domyślne ustawienie: nic nie jest przechwytywane, dopóki zgoda nie zostanie zarejestrowana, a SDK zapewnia czystą tranzycję zamiast modernizacji opartej na stanie.

Pliki cookie, wpisy localStorage i identyfikatory, które PostHog utrwala

Browser SDK 1.x zapisuje jeden wpis trwałości na projekt, pod kluczem ph_{projectKey}_posthog, z domyślnym wygaśnięciem 365 dni. Opcja init persistence steruje mechanizmem bazowym: tylko cookie, tylko localStorage, localStorage+cookie (domyślnie), sessionStorage lub memory. Dla wdrożenia opartego na zgodzie trwałość memory jest właściwym domyślnym ustawieniem, gdy zgoda nie została jeszcze udzielona — gwarantuje to, że żaden identyfikator nie przeżyje sesji strony — z przejściem do localStorage+cookie po udzieleniu zgody. SDK zapisuje też znacznik opt-in lub opt-out pod kluczem __ph_opt_in_out_{projectKey} w celu zapamiętania wyboru użytkownika między wizytami; sam ten znacznik jest ściśle niezbędnym plikiem cookie, ponieważ utrwala decyzję o zgodzie.

Mapowanie modułów PostHog na ramowe struktury zgody

PostHog nie implementuje natywnie IAB TCF ani IAB Global Privacy Platform i nie jest zbudowany jako dostawca ad-tech. Integruje się jednak z Google Consent Mode v2 poprzez mostkowanie po stronie wydawcy, udostępnia natywne API opt-in i opt-out oraz respektuje nagłówek Do Not Track za pośrednictwem opcji init respect_dnt. Wzorzec działający w produkcji traktuje każdy moduł PostHog jako oddzielną bramkę powiązaną z konkretnym sygnałem CMP.

• Zdarzenia analityki produktowej są powiązane z celem analitycznym. W terminologii TCF jest to najczęściej cel 8 (mierzenie wydajności treści) w połączeniu z celem 1 (przechowywanie informacji i/lub dostęp do nich). W przypadku Consent Mode odpowiada to analytics_storage.
• Odtwarzanie sesji znajduje się za bardziej rygorystyczną bramką. Odtwarzanie sesji PostHog przechwytuje wyrenderowany DOM i wszelkie niemaskowane pola wejściowe, więc opt-in na poziomie preferencji lub badań, odrębny od analityki, jest defensywną pozycją zgodnie z wytycznymi EDPB.
• Flagi funkcji i eksperymentowanie mogą działać na podstawie ulotnej, pamięciowej oceny na podstawie uzasadnionego interesu, gdy celem jest jedynie zróżnicowanie wyrenderowanej strony. Trwałe przypisanie flagi powiązane ze stabilnym identyfikatorem w sesjach wymaga tej samej zgody co analityka, ponieważ wtedy flaga staje się identyfikowalnym punktem danych na poziomie użytkownika.
• Ankiety i opinie są powiązane z tą samą bramką co odtwarzanie sesji, gdy zbierają wprowadzone przez użytkownika wolny tekst, lub z bramką analityki, gdy zbierają jedynie oceny lub odpowiedzi jednokrotnego wyboru.

Wzorzec integracji, który działa

Wdrożenie referencyjne składa się z czterech części: CMP, który udostępnia zdarzenie zmiany zgody w czasie rzeczywistym, odroczonego bootstrap inicjalizującego PostHog z wyłączonym przechwytywaniem i odtwarzaniem, listenera zgody, który przełącza opt_in_capturing i przełącznik nagrywania po otwarciu odpowiednich bramek, oraz ścieżki wycofania, która wywołuje opt_out_capturing, zatrzymuje bufor odtwarzania i czyści trwałe identyfikatory przez API resetowania SDK.

Implementacja webowa

Najczystszy wzorzec polega na wczytywaniu SDK PostHog na każdej stronie, ale wywołaniu posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) jako wstępnego bootstrapu. Zasubskrybuj zdarzenie zmiany zgody CMP. Gdy kategoria analityki przełączy się na true, wywołaj posthog.set_config({ persistence: 'localStorage+cookie' }), a następnie posthog.opt_in_capturing(); spowoduje to ponowne włączenie przechwytywania zdarzeń, a tranzycja trwałości zacznie zapisywać unikalny identyfikator. Gdy kategoria odtwarzania sesji przełączy się na true, wywołaj posthog.startSessionRecording(). Gdy którakolwiek bramka zostanie wycofana, wywołaj posthog.opt_out_capturing() dla bramki analityki lub posthog.stopSessionRecording() dla bramki odtwarzania, wygaś odpowiednie wpisy trwałości przez posthog.reset() i wyślij żądanie usunięcia przez API GDPR PostHog, jeśli użytkownik skorzystał z prawa do usunięcia danych.

Wybór regionu: PostHog Cloud USA vs UE vs własny

PostHog obsługuje dwa regiony chmury — USA (us.posthog.com) i UE (eu.posthog.com) — oraz obsługuje własne instalacje w infrastrukturze klienta. W przypadku ruchu z EOG i UK chmura UE jest właściwym domyślnym wyborem; utrzymuje pozyskiwanie, przetwarzanie i przechowywanie w obrębie EOG i redukuje ekspozycję Schrems II, jaką niesie każde wdrożenie analityki w regionie USA. Opcja init api_host ustala region. Własny PostHog przenosi cały stos na własną infrastrukturę wydawcy, co stanowi najmocniejszą pozycję pod względem rezydencji danych, ale nie eliminuje obowiązków dotyczących zgody — podstawa prawna podąża za danymi, a nie za operatorem. Wybrana opcja musi być odzwierciedlona w polityce prywatności i rejestrze czynności przetwarzania administratora.

Przechwytywanie po stronie serwera

PostHog obsługuje pozyskiwanie zdarzeń po stronie serwera za pośrednictwem SDK Python, Node, Go, Ruby i PHP. Zdarzenia po stronie serwera nie są zwolnione ze zgody — podstawa prawna podąża za danymi — ale pozyskiwanie po stronie serwera daje wydawcy pełną kontrolę nad tym, jakie pola są emitowane i kiedy. Popularnym wzorcem jest przechwytywanie minimalnego zestawu zdarzeń wyłącznie niezbędnych po stronie serwera na podstawie uzasadnionego interesu, a następnie wzbogacanie tych zdarzeń o szczegóły behawioralne po stronie klienta dopiero po udzieleniu przez użytkownika zgody na analitykę. Zdarzenia po stronie serwera i po stronie klienta łączą się na tym samym unikalnym identyfikatorze po udzieleniu zgody; przed udzieleniem zgody zdarzenia po stronie serwera są emitowane z anonimowym, ulotnym identyfikatorem, który jest resetowany przy każdej sesji.

Walidacja integracji i ścieżki audytu

Krok walidacji jest tym, co sprawdzają organy regulacyjne i co wydawcy najczęściej pomijają. Prawidłowo zintegrowane wdrożenie PostHog musi przejść cztery testy kolejno. Po pierwsze, czysta sesja przeglądarki z wyświetlonym banerem, ale bez dokonanego wyboru, musi generować zero żądań do skonfigurowanego api_host poza pobraniem pliku SDK, zero plików cookie ph_ w document.cookie i zero wpisów ph_ w localStorage. Po drugie, odrzucenie analityki musi utrzymywać ten stan — bez przechwytywania, bez nagrywania, bez trwałego identyfikatora. Po trzecie, akceptacja analityki musi generować natychmiastowe zdarzenie $opt_in, oczekiwany wpis trwałości ph_{projectKey}_posthog z poprawnymi atrybutami SameSite i ruch zdarzeń płynący do skonfigurowanego hosta. Po czwarte, wycofanie zgody po fakcie musi natychmiast zatrzymać dalsze przechwytywanie i odtwarzanie, wygasić trwałe identyfikatory i uruchomić żądanie usunięcia przez API GDPR PostHog, jeśli użytkownik skorzystał z prawa do usunięcia danych.

Oczekiwania dotyczące ścieżki audytu zgodnie z wytycznymi EDPB z 2023 roku dotyczącymi banerów plików cookie i odnowionymi priorytetami grupy zadaniowej na 2026 rok są takie, że wydawca może udowodnić dla każdego zdarzenia w projekcie PostHog, że użytkownik, który je wygenerował, udzielił ważnej zgody w momencie przechwycenia. Standardowym wzorcem jest ustawienie wersji zgody i znacznika czasu jako właściwości osoby na unikalnym ID przez posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }), tak aby każde indywidualne zdarzenie było identyfikowalne z powrotem do konkretnego wpisu dziennika zgody. Prawidłowo zabezpieczone wdrożenie, połączone z wyborem regionu odpowiadającym odbiorcom, trwałością domyślnie ustawioną na pamięć i ścieżką usunięcia aktywowaną przy wycofaniu, przekształca PostHog z regulacyjnego ryzyka koncentracji w defensywne centrum stosu analityki produktowej.