Miksi PostHog vaatii suostumusta — ja miksi vastaus ei ole sama jokaiselle moduulille

PostHogin verkko-SDK ei ole passiivinen sivutagline. Oletusalustuksessa SDK asettaa yhden tai useamman ensimmäisen osapuolen pysyvyysmerkinnän — oletuksena yhdistetty eväste plus localStorage-kaava avaimena ph_{projectKey}_posthog alla — luo vakaan erillisen tunnisteen, tallentaa ensimmäisen sivunäkymän viittaajalla, UTM-parametreilla ja klikkitunnisteilla sekä avaa pitkäkestoisen tapahtumakanavan määritettyyn vastaanottoisäntään. Jos istuntotallennus on otettu käyttöön projektitasolla, SDK alkaa lisäksi suoratoistaa jatkuvaa tallennetta renderoidusta DOM:ista, hiirikursorikoordinaateista ja syöttötapahtumista. Jos ominaisuusliput on määritetty, SDK arvioi ne erillisen tunnisteen suhteen, tallentaa päätökset istunnolle ja lähettää jokaisen arvioinnin osalta $feature_flag_called-tapahtuman.

Jokainen näistä toiminnoista vastaa eri suostumisportia. Erillisen tunnisteen pysyttäminen on tallennus- ja käyttöoperaatio ePrivacy-direktiivin 5(3) artiklan nojalla ja vaatii ennakkosuostumuksen, joka on vapaasti annettu, erityinen, tietoinen ja yksiselitteinen koko EEA:ssa, UK:ssa ja missä tahansa lainkäyttöalueessa, joka on omaksunut saman standardin. Käyttäytymistapahtumat on henkilötietojen käsittelyä GDPR:n nojalla, koska tunnisteen, IP-osoitteen ja käyttäytymistekijän yhdistelmä on riittävä yksilön yksilöimiseen. Istuntotallennus kuuluu erilliseen, tiukempaan luokkaan EDPB:n istuntotallennusohjeiden nojalla — toisto tallentaa renderoidun DOM:in ja kaikki peittämättömät syöttökentät ja vaatii selkeän, tarkan suostumuksen, joka eroaa yleisestä analytiikkasuostumuksesta. Ominaisuuslipun arviointi on hienovaraisin: lippucheck, joka palauttaa totuusarvon, ei itsessään vaadi suostumusta, mutta käyttäjän lippumäärityksen pysyttäminen vakaaseen tunnisteeseen istuntojen välillä vaatii sitä, koska siten lippupohjainen kokeilu luo jäljitettävää käyttäjätason dataa.

Mitä PostHog kirjoittaa ennen suostumusta — ja mitä täytyy estää

PostHogin oletusselain-SDK kirjoittaa alustuksessa seuraavaa: yhden yhdistetyn evästeen ja localStorage-merkinnän ph_{projectKey}_posthog alla, joka sisältää erillisen tunnisteen, istuntotunnisteen ja ominaisuuslippupäätökset, sekä istuntotallennuksen ollessa käytössä lisäksi muistinsisäisen tallennuspuskurin, joka tyhjentyy vastaanotto-päätepisteeseen muutaman sekunnin välein. SDK lähettää myös välittömän $pageview-tapahtuman ja automaattikaapauksen ollessa käytössä jokaisen myöhemmän klikkauksen, lomakeinteraktion ja raivoklikkaukseen sivulla.

Suositeltu malli on alustaa PostHog parametreilla opt_out_capturing_by_default: true ja disable_session_recording: true, sitten kääntää molemmat liput kun suostumusbanneri palauttaa positiivisen signaalin. Tämä on integraatioasema, jota PostHogin dokumentaatio nyt suosittelee, ja se on asema, joka selviytyy sääntelyviraston tarkistuksesta, koska se kääntää oletuksen: mitään ei tallenneta ennen kuin suostumus on kirjattu, ja SDK tarjoaa puhtaan siirtymän eikä tilallista jälkikäteismuokkausta.

Evästeet, localStorage-merkinnät ja tunnisteet, joita PostHog säilyttää

Selain SDK 1.x kirjoittaa yhden pysyvyysmerkinnän projektikohtaisesti avaimena ph_{projectKey}_posthog, oletuksena 365 päivän vanhenemisajalla. persistence-alustusvaihtoehto ohjaa taustamekanismia: vain cookie, vain localStorage, localStorage+cookie (oletus), sessionStorage tai memory. Suostumus-ensimmäinen käyttöönotto käyttää memory-pysyvyyttä oikeana oletuksena, kun suostumusta ei ole vielä myönnetty — se varmistaa, ettei mikään tunniste elinjakso ylitä sivuistuntoa — siirtyminen localStorage+cookie:een tapahtuu suostumuksen vaihtuessa. SDK kirjoittaa myös opt-in tai opt-out -merkinnän __ph_opt_in_out_{projectKey} alle muistaakseen käyttäjän valinnan eri vierailujen välillä; kyseinen merkintä itsessään on välttämätön eväste, koska se pysyttää suostumuspäätöksen.

PostHog-moduulien kartoittaminen suostumuskehyksiin

PostHog ei toteuta natiivisti IAB TCF:ää tai IAB-globaalin yksityisyysalustan, eikä sitä ole rakennettu mainosteknologiatoimittajana. Se kuitenkin integroituu Google Consent Mode v2:een julkaisijapuolen silloittamisen kautta, paljastaa natiivit opt-in ja opt-out API:t ja kunnioittaa Do Not Track -otsakkeen respect_dnt-alustusvaihtoehdon kautta. Tuotannossa toimiva malli käsittelee jokaista PostHog-moduulia erillisenä portina sidottuna tiettyyn CMP-signaaliin.

• Tuoteanalytiikkatapahtumat sidotaan analytiikkatarkoitukseen. TCF-termeinä tämä on yleisimmin tarkoitus 8 (sisältösuorituksen mittaaminen) yhdistettynä tarkoitukseen 1 (tietojen tallentaminen ja/tai käyttö). Consent Mode:lle tämä vastaa analytics_storage:ta.
• Istuntotallennus on tiukemman portin takana. PostHogin istuntotallennus tallentaa renderoidun DOM:in ja kaikki peittämättömät syöttökentät, joten EDPB:n ohjeiden mukainen mieltymys- tai tutkimustason opt-in, joka eroaa analytiikasta, on puolustettava asema.
• Ominaisuusliput ja kokeilu voivat toimia tilapäisellä, muistinsisäisellä arvioinnilla oikeutettujen intressien perusteella, kun tavoite on vain renderoitavan sivun vaihtelu. Pysyvä lippumääritys sidottuna vakaaseen tunnisteeseen istuntojen välillä vaatii saman suostumuksen kuin analytiikka, koska silloin lipusta tulee jäljitettävä käyttäjätason datapiste.
• Kyselyt ja palaute sidotaan samaan portiin kuin istuntotallennus, kun ne keräävät vapaamuotoista tekstisyötettä, tai analytiikkaporttiin, kun ne keräävät vain arvosanoja tai yksivalintavastauksia.

Toimiva integraatiomalli

Viitekäyttöönotolla on neljä osaa: CMP, joka paljastaa reaaliaikaisen suostumuksenmuutostapahtuman, viivästetty bootstrap, joka alustaa PostHogin kaappaus ja toisto pois käytöstä, suostumustendelija, joka kääntää opt_in_capturing ja tallennuskytkimen asiaankuuluvien porttien avautuessa sekä peruuttamispolku, joka kutsuu opt_out_capturing:n, pysäyttää toistovälimuistin ja tyhjentää pysyvät tunnisteet SDK:n reset-API:n kautta.

Verkkointegraatio

Puhtain malli on ladata PostHog SDK jokaiselle sivulle, mutta kutsua posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) alkuperäisenä bootstrapina. Tilaa CMP:n suostumuksenmuutostapahtuma. Kun analytiikkaluokka siirtyy tosi-tilaan, kutsu posthog.set_config({ persistence: 'localStorage+cookie' }) ja sen jälkeen posthog.opt_in_capturing(); tämä mahdollistaa tapahtumien kaappauksen uudelleen ja pysyvyyssiirtymä alkaa kirjoittaa erillistä tunnistetta. Kun istuntotallennusluokka siirtyy tosi-tilaan, kutsu posthog.startSessionRecording(). Kun jokin portti peruutetaan, kutsu posthog.opt_out_capturing() analytiikkaporttia varten tai posthog.stopSessionRecording() toistoporttia varten, vanhenna asiaankuuluvat pysyvyysmerkinnät posthog.reset():n kautta, ja lähetä poistopyyntö PostHogin GDPR API:n kautta, jos käyttäjä on käyttänyt poistoikeuttaan.

Alueen valinta: PostHog Cloud USA vs EU vs itse isännöity

PostHog käyttää kahta pilvialuetta — USA (us.posthog.com) ja EU (eu.posthog.com) — ja tukee itse isännöityjä asennuksia asiakkaan omassa infrastruktuurissa. EEA:n ja UK:n liikenteelle EU-pilvi on oikea oletus; se pitää vastaanoton, käsittelyn ja tallennuksen EEA:n sisällä ja vähentää Schrems II -altistusta, jota jokainen USA-alueen analytiikkakäyttöönotto kantaa. api_host-alustusvaihtoehto kiinnittää alueen. Itse isännöity PostHog siirtää koko pinon julkaisijan omalle infrastruktuurille, mikä on vahvin dataresidenssipositio, mutta ei poista suostumisvelvoitteita — oikeusperuste seuraa dataa, ei operaattoria. Valittu vaihtoehto on heijastettava tietosuojailmoituksessa ja rekisterinpitäjän käsittelyrekisterissä.

Palvelinpuolen kaappaus

PostHog tukee palvelinpuolen tapahtumaanottoa Python-, Node-, Go-, Ruby- ja PHP-SDK:iden kautta. Palvelinpuolen tapahtumat eivät ole vapautettuja suostumuksesta — oikeusperuste seuraa dataa — mutta palvelinpuolen vastaanotto antaa julkaisijalle täyden kontrollin siitä, mitkä kentät lähetetään ja milloin. Yleinen malli on kaapata minimaalinen välttämätön tapahtumajoukko palvelinpuolella oikeutettujen intressien nojalla, sitten rikastaa nämä tapahtumat käyttäytymistiedoilla asiakaspuolelta vasta sen jälkeen, kun käyttäjä on myöntänyt analytiikkasuostumuksen. Palvelinpuolen ja asiakaspuolen tapahtumat yhdistyvät samaan erilliseen tunnisteeseen, kun suostumus on vaihtunut; ennen suostumusta palvelinpuolen tapahtumat lähetetään anonyymillä, tilapäisellä tunnisteella, joka nollataan jokaisessa istunnossa.

Integraation ja auditointipolun validointi

Validointivaihe on se, mitä sääntelyviranomaiset tarkistavat ja mitä julkaisijat useimmiten ohittavat. Oikein integroidun PostHog-käyttöönoton on läpäistävä neljä testiä järjestyksessä. Ensiksi puhtaan selainistunnon, jossa banneri näytetään mutta valintaa ei ole tehty, on tuotettava nolla pyyntöä määritettyyn api_host:iin SDK-tiedoston haun lisäksi, nolla ph_-evästettä document.cookie:ssa ja nolla ph_-merkintää localStorage:ssa. Toiseksi analytiikan hylkäämisen on pidettävä kyseinen tila — ei kaappausta, ei tallennusta, ei pysyvää tunnistetta. Kolmanneksi analytiikan hyväksymisen on tuotettava välitön $opt_in-tapahtuma, odotettu ph_{projectKey}_posthog-pysyvyysmerkintä oikeilla SameSite-attribuuteilla ja tapahtumanliikenne määritettyyn isäntään. Neljänneksi suostumuksen peruuttamisen jälkikäteen on välittömästi lopetettava lisäkaappaus ja toisto, vanhennettava pysyvät tunnisteet ja käynnistettävä poistopyyntö PostHogin GDPR API:n kautta, jos käyttäjä on käyttänyt poistoaan.

EDPB:n 2023:n evästebanneriohjauksien ja uudistettujen 2026:n työryhmän prioriteettien mukainen auditointipolkuodotus on, että julkaisija voi todistaa jokaisesta PostHog-projektin tapahtumasta, että tapahtuman tuottanut käyttäjä oli antanut pätevän suostumuksen kaappaushetkellä. Standardimalli on asettaa suostumusversio ja aikaleima henkilöominaisuuksiksi erilliselle ID:lle posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }):n kautta, jotta jokainen yksittäinen tapahtuma on jäljitettävissä tiettyyn suostumuslokimerkintään. Oikein portoitu käyttöönotto, yhdistettynä alueen valintaan, joka vastaa yleisöä, pysyvyyteen, joka oletuksena on muisti, ja poistovolkuun, joka aktivoituu peruuttamisessa, muuttaa PostHogin sääntelykeskittymäriskistä puolustettavaksi tuoteanalytiikkapinon ytimeksi.