Miért igényel a PostHog hozzájárulást – és miért nem ugyanaz a válasz minden modulra

A PostHog web SDK nem passzív oldaltag. Alapértelmezett inicializálás esetén az SDK egy vagy több elsőfél perzisztencia-bejegyzést állít be – alapértelmezésben egy kombinált cookie plusz localStorage sémát ph_{projectKey}_posthog kulcs alatt –, stabil egyedi azonosítót generál, rögzíti a kezdeti oldalmegjelenítést hivatkozóval, UTM paraméterekkel és kattintásazonosítókkal, és hosszú élettartamú eseménycsatornát nyit a konfigurált beolvasási gazdagéphez. Ha a munkamenet-visszajátszás engedélyezve van a projekt szintjén, az SDK emellett folyamatos folyamot indít el a leképezett DOM, egérkoordináták és beviteli események folyamatos rögzítéséről. Ha funkciójelzők vannak konfigurálva, az SDK kiértékeli azokat az egyedi azonosítóhoz képest, megőrzi a döntéseket a munkamenet során, és minden értékeléshez egy $feature_flag_called eseményt bocsát ki.

Ezek a tevékenységek mindegyike más hozzájárulási kapuhoz kapcsolódik. Egy egyedi azonosító megőrzése az ePrivacy irányelv 5(3). cikke szerinti tárolási és hozzáférési művelet, és előzetes, szabadon adott, konkrét, tájékozott és egyértelmű hozzájárulást igényel az EGT-ben, az Egyesült Királyságban, és minden olyan joghatóságban, amely ugyanezt a szabványt átvette. Viselkedési események rögzítése a GDPR szerinti személyes adatok kezelése, mivel az azonosító, az IP-cím és a viselkedési nyom kombinációja elegendő egy személy azonosításához. A munkamenet-visszajátszás az EDPB munkamenet-visszajátszási iránymutatása szerint külön, szigorúbb kategóriába esik – a visszajátszás rögzíti a leképezett DOM-ot és bármely maszkolatlan beviteli mezőt, és olyan explicit, részletes hozzájárulást igényel, amely elkülönül az általános analitikai hozzájárulástól. A funkciójelző-kiértékelés az árnyaltabb eset: egy logikai értéket visszaadó jelzőlekérdezés önmagában nem igényel hozzájárulást, de a felhasználó jelzőhozzárendelésének stabil azonosítóhoz való megőrzése munkamenetek között igen, mivel ez az, ahogyan a jelzőalapú kísérletezés nyomon követhető felhasználói szintű adatokat hoz létre.

Mit ír a PostHog hozzájárulás előtt – és mit kell elnyomni

Az alapértelmezett PostHog Böngésző SDK az inicializáláskor a következőket írja: egy kombinált cookie-t és localStorage-bejegyzést ph_{projectKey}_posthog alatt, amely tartalmazza az egyedi azonosítót, munkamenet-azonosítót és funkciójelző-döntéseket, plusz, ha a munkamenet-visszajátszás engedélyezve van, egy további memóriában tárolt rögzítési puffert, amely néhány másodpercenként kiürül a beolvasási végpontra. Az SDK azonnali $pageview eseményt is küld, és ha az automatikus rögzítés be van kapcsolva, minden ezt követő kattintást, űrlapinterakciót és dühös kattintást az oldalon.

Az ajánlott minta az, hogy a PostHog-ot opt_out_capturing_by_default: true és disable_session_recording: true beállítással inicializáljuk, majd mindkét jelzőt átbillentjük, amikor a hozzájárulási banner pozitív jelet ad vissza. Ez az az integrációs testtartás, amelyet a PostHog dokumentációja most javasol, és ez az a testtartás, amely túléli a szabályozó felülvizsgálatát, mivel megfordítja az alapértelmezett viselkedést: semmit sem rögzítenek, amíg a hozzájárulást nem rögzítik, és az SDK tiszta átmenetet biztosít az állapot-alapú visszaállítás helyett.

A cookie-k, localStorage-bejegyzések és azonosítók, amelyeket a PostHog megőriz

A Böngésző SDK 1.x projektenként egy perzisztencia-bejegyzést ír, amelynek kulcsa ph_{projectKey}_posthog, alapértelmezetten 365 napos lejárattal. A persistence init-opció vezérli az alapul szolgáló mechanizmust: csak cookie, csak localStorage, localStorage+cookie (az alapértelmezett), sessionStorage vagy memory. Hozzájárulás-első telepítésnél a memory perzisztencia a megfelelő alapértelmezés, ha a hozzájárulást még nem adták meg – ez biztosítja, hogy egyetlen azonosító sem éli túl az oldalmunkamenetet –, majd átváltunk localStorage+cookie-ra, ha a hozzájárulás bekapcsol. Az SDK szintén ír egy opt-in vagy opt-out jelzőt __ph_opt_in_out_{projectKey} alatt, hogy a felhasználó döntését látogatások között megjegyezze; ez a jelző maga egy feltétlenül szükséges cookie, mivel hozzájárulási döntést őriz meg.

A PostHog modulok leképezése hozzájárulási keretrendszerekre

A PostHog natívan nem valósítja meg az IAB TCF-et vagy az IAB Global Privacy Platform-ot, és nem ad-tech szállítóként épül fel. Ugyanakkor integrálódik a Google Consent Mode v2-vel közzétevői oldali hídkötésen keresztül, natív opt-in és opt-out API-t tesz elérhetővé, és tiszteletben tartja a Do Not Track fejlécet a respect_dnt init-opcióval. Az éles környezetben működő minta minden PostHog modult külön kapuként kezel, amely egy adott CMP-jelhez van kötve.

• Termékanalitika-események az analitikai célhoz kötődnek. TCF terminológiában ez leggyakrabban a 8. célkitűzés (tartalom teljesítményének mérése) kombinálva az 1. célkitűzéssel (információk tárolása és/vagy elérése). A Consent Mode-ban ez az analytics_storage-hoz van leképezve.
• A munkamenet-visszajátszás egy szigorúbb kapu mögött áll. A PostHog munkamenet-visszajátszása rögzíti a leképezett DOM-ot és bármely maszkolatlan beviteli mezőt, ezért az EDPB iránymutatása szerint az analitikától különálló preferencia- vagy kutatási szintű opt-in a védhető álláspontra.
• A funkciójelzők és kísérletezés futhatnak efemer, memóriában lévő kiértékeléssel jogos érdek alapján, ha a cél csak a leképezett oldal változtatása. A stabil azonosítóhoz munkamenetek között kötött állandó jelzőhozzárendelés ugyanolyan hozzájárulást igényel, mint az analitika, mivel ilyenkor válik a jelző nyomon követhető felhasználói szintű adattá.
• A felmérések és visszajelzések ugyanahhoz a kapuhoz kötődnek, mint a munkamenet-visszajátszás, ha szabad szöveges bevitelt gyűjtenek, vagy az analitikai kapuhoz, ha csak értékeléseket vagy egyetlen-kiválasztásos válaszokat gyűjtenek.

A működő integrációs minta

A referencia-telepítésnek négy része van: egy CMP, amely valós idejű hozzájárulás-változási eseményt tesz elérhetővé, egy halasztott bootstrap, amely rögzítés és visszajátszás letiltásával inicializálja a PostHog-ot, egy hozzájárulás-figyelő, amely átbillenti az opt_in_capturing-ot és a rögzítési kapcsolót, amikor a releváns kapuk megnyílnak, és egy visszavonási útvonal, amely meghívja az opt_out_capturing-ot, leállítja a visszajátszás pufferét, és az SDK reset API-ján keresztül törli az állandó azonosítókat.

Webes megvalósítás

A legtisztább minta az, hogy minden oldalon betöltjük a PostHog SDK-t, de a posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) hívást végezzük el kezdeti bootstrapként. Feliratkozunk a CMP hozzájárulás-változási eseményére. Amikor az analitikai kategória igaz értékre vált, meghívjuk a posthog.set_config({ persistence: 'localStorage+cookie' }) függvényt, majd a posthog.opt_in_capturing() függvényt; ez újra engedélyezi az eseményrögzítést, és a perzisztencia-átmenet megkezdi az egyedi azonosító írását. Amikor a munkamenet-visszajátszás kategória igaz értékre vált, meghívjuk a posthog.startSessionRecording() függvényt. Amikor bármelyik kapu visszavon, meghívjuk a posthog.opt_out_capturing() függvényt az analitikai kapuhoz, vagy a posthog.stopSessionRecording() függvényt a visszajátszási kapuhoz, lejáratjuk a releváns perzisztencia-bejegyzéseket a posthog.reset() segítségével, és törlési kérelmet küldünk a PostHog GDPR API-ján keresztül, ha a felhasználó élt törlési jogával.

Régióválasztás: PostHog Cloud US vs EU vs saját üzemeltetés

A PostHog két felhőrégiót üzemeltet – US (us.posthog.com) és EU (eu.posthog.com) –, és támogatja a saját infrastruktúrán való saját üzemeltetést. Az EGT és az Egyesült Királyság forgalmához az EU felhő az ajánlott alapértelmezés; ez az EGT-n belül tartja a beolvasást, feldolgozást és tárolást, és csökkenti a Schrems II-kitettséget, amelyet bármely US-régió analitika-telepítés hordoz. Az api_host init-opció rögzíti a régiót. A saját üzemeltetésű PostHog a teljes rendszert a közzétevő saját infrastruktúrájára helyezi, amely a legerősebb adat-rezidenció testtartás, de nem szünteti meg a hozzájárulási kötelezettségeket – a jogi alap az adatokat követi, nem az üzemeltetőt. Bármelyik opciót is választjuk, azt tükrözni kell az adatvédelmi nyilatkozatban és az adatkezelő adatkezelési nyilvántartásában.

Szerver oldali rögzítés

A PostHog támogatja a szerveroldali esemény-beolvasást a Python, Node, Go, Ruby és PHP SDK-kon keresztül. A szerveroldali események nem mentesülnek a hozzájárulás alól – a jogi alap az adatokat követi –, de a szerveroldali beolvasás teljes kontrollt ad a közzétevőnek arról, hogy mely mezőket bocsátja ki és mikor. Egy általános minta az, hogy minimális, csak alapvető eseménykészletet rögzítünk szerveren jogos érdek alapján, majd ezeket az eseményeket viselkedési részletekkel gazdagítjuk az ügyféltől csak azt követően, hogy a felhasználó megadta az analitikai hozzájárulást. A szerver- és ügyféloldali események ugyanazon az egyedi azonosítón csatlakoznak össze, ha a hozzájárulás bekapcsolt; hozzájárulás előtt a szerveroldali eseményeket névtelen, efemer azonosítóval bocsátják ki, amelyet minden munkamenetben visszaállítanak.

Az integráció és az auditnyom validálása

Az érvényesítési lépés az, amelyet a szabályozók ellenőriznek, és amelyet a közzétevők a leggyakrabban kihagynak. Egy helyesen integrált PostHog-telepítésnek négy teszten kell sorban átmennie. Először, egy tiszta böngészőmunkamenetnek, ahol a banner megjelenik, de nem születik döntés, nullára kell csökkentenie a konfigurált api_host-ra irányuló kérések számát az SDK-fájl letöltésén túl, nullára a ph_ cookie-kat a document.cookie-ban, és nullára a ph_ bejegyzéseket a localStorage-ban. Másodszor, az analitika visszautasításának meg kell tartania ezt az állapotot – nincs rögzítés, nincs visszajátszás, nincs állandó azonosító. Harmadszor, az analitika elfogadásának azonnali $opt_in eseményt kell generálnia, a várt ph_{projectKey}_posthog perzisztencia-bejegyzést helyes SameSite attribútumokkal, és a konfigurált gazdagépre irányuló eseményforgalmat. Negyedszer, a hozzájárulás utólagos visszavonásának azonnal le kell állítania a további rögzítést és visszajátszást, le kell járatnia az állandó azonosítókat, és törlési kérelmet kell indítania a PostHog GDPR API-ján keresztül, ha a felhasználó élt törlési jogával.

Az auditnyom-elvárás az EDPB 2023-as cookie-banner iránymutatása és a megújított 2026-os munkacsoport prioritások szerint az, hogy a közzétevő bizonyítani tudja bármely adott eseményre a PostHog projektben, hogy az azt generáló felhasználó érvényes hozzájárulást adott a rögzítés pillanatában. A szabványos minta az, hogy a hozzájárulás verzióját és időbélyegét személyes tulajdonságként állítjuk be az egyedi azonosítón a posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) segítségével, hogy bármely egyedi esemény visszakövethető legyen egy adott hozzájárulási naplóbejegyzésre. Egy helyesen kapuzott telepítés, párosítva a közönségnek megfelelő régióválasztással, a memóriát alapértelmezettként használó perzisztenciával és a visszavonáskor aktiválódó törlési útvonallal, az, ami a PostHog-ot egy szabályozói koncentrációs kockázatból a termékanalitika-rendszer védhető középpontjává teszi.