PostHog brez piškotkov: en klic znova ustvari osebni identifikator

Za osnovno analitiko brez trajnega identifikatorja v brskalniku vključite strežniški način za izračun zgoščene vrednosti ter nastavite cookieless_mode: 'always' in person_profiles: 'never'. PostHogova navodila za merjenje brez piškotkov opozarjajo, da lahko klic identify() brez izključenih profilov kljub prazni shrambi pošlje dogodek $identify s trajnim identifikatorjem uporabnika.

Če želite meriti obiske po zavrnitvi soglasja, po privolitvi pa omogočiti običajno povezovanje dogodkov z uporabnikom, uporabite on_reject in ga povežite z uporabnikovo izbiro. Če trajnega povezovanja ne želite niti po privolitvi, izključite profile oseb tudi v tem načinu. Pri takšni izbiri obiskov iste osebe med dnevi ali napravami ni mogoče zanesljivo združiti.

Nastavitev načina always

V projektu najprej odprite Project Settings → Web analytics in vključite Cookieless server hash mode. Nato spletni SDK inicializirajte z nastavitvama cookieless_mode: 'always' in person_profiles: 'never'; pri api_host uporabite naslov regije svojega projekta. Primer zapisa je posthog.init('PROJEKTNI_ZETON', { api_host: 'NASLOV_REGIJE', cookieless_mode: 'always', person_profiles: 'never' }).

V načinu always PostHog ne zapisuje svojih podatkov v piškotke, lokalno shrambo ali sejno shrambo. Za omejeno štetje obiskovalcev na strežniku izračuna zgoščeno vrednost iz identifikatorja projekta, dnevno menjane soli, naslova IP, oznake brskalnika in imena gostitelja. Ker se sol menja vsak dan, takšno štetje ne ohrani iste identitete med dnevi.

Nastavitev person_profiles: 'never' spremeni klice identify() v klice brez učinka. V integraciji vseeno poiščite poti, ki kličejo identify(), alias() ali nastavljajo lastnosti osebe: ob poznejši spremembi konfiguracije lahko spet postanejo pomembne. V načinu brez piškotkov se dogodki alias() ob sprejemu zavržejo, zato nanje ne računajte za združevanje identitet. Preglejte tudi lastnosti svojih dogodkov: e-poštni naslov ali ID računa v dogodku lahko razkrije uporabnika, čeprav SDK ne shrani piškotka.

Kdaj uporabiti on_reject

Način cookieless_mode: 'on_reject' je namenjen strani, ki uporabniku ponudi izbiro. Pred odločitvijo PostHog ne zajema dogodkov in ne zapisuje svojih podatkov v shrambo brskalnika. Po zavrnitvi lahko nadaljuje omejeno štetje brez piškotkov, po privolitvi pa uporablja običajni zajem s shranjevanjem v brskalniku.

Inicializirajte SDK z on_reject ter prikaz izbire povežite z posthog.opt_in_capturing() za privolitev in posthog.opt_out_capturing() za zavrnitev. Pred prikazom lahko stanje preverite s posthog.get_explicit_consent_status(); vrednost pending pomeni, da odločitve še ni. Če dodate še person_profiles: 'never', identify() tudi po privolitvi ne bo ustvaril prepoznanega profila. Zato je odločitev o profilih ločena od odločitve o piškotkih.

Preizkus v orodjih brskalnika

Preverjanje opravite v preskusnem okolju s svežim profilom brskalnika. V orodjih za razvijalce odprite razdelka Application oziroma Storage ter Network in osvežite stran. Pri pregledu shrambe ločite PostHogove zapise od piškotkov za prijavo, druge analitike in lastne aplikacije.

1. Pri načinu always preglejte Cookies, Local Storage in Session Storage za domeno strani. Po obisku in osvežitvi tam ne pričakujte PostHogovega trajnega zapisa.
2. V Network odprite zahteve za zajem dogodkov. V namenski preskusni konfiguraciji brez person_profiles: 'never' sprožite identify() s preskusnim ID in preverite, ali zahteva vsebuje $identify ter poslani distinct ID. Nato vključite person_profiles: 'never', ponovite klic in preverite, da dogodka $identify ni.
3. Pri on_reject ločeno preverite stanje pred izbiro, po zavrnitvi in po privolitvi. Pred izbiro ne pričakujte zajetih dogodkov; po zavrnitvi preverite zajem brez PostHogovega zapisa v shrambo; po privolitvi preverite še vedenje glede na nastavitev profilov.

To je postopek za preverjanje vaše integracije, ne trditev o že opravljenem preizkusu konkretne strani. Prazen seznam piškotkov sam ne pokaže, kaj je bilo poslano v omrežni zahtevi, seznam zahtev pa ne pokaže vseh zapisov, ki jih lahko ustvarijo druge skripte. Zato je treba pregledati oba razdelka.

Katere funkcije se spremenijo

Odsotnost trajnega identifikatorja spremeni pomen nekaterih meritev, odsotnost shrambe pa vpliva na funkcije, ki jo uporabljajo. Za osnovne oglede strani in dogodke ostane zajem uporaben, pri naslednjih rezultatih pa velja drugačna meja:

• Obiskovalci skozi več dni: zaradi dnevno menjane soli je lahko ista oseba v večdnevnem prikazu šteta večkrat. Možna je tudi kolizija zgoščene vrednosti, pri kateri se različna obiskovalca štejeta kot eden.
• Povezovanje med napravami: brez identifikacije ni zanesljive povezave med obiskom na telefonu, obiskom v drugem brskalniku in poznejšo prijavo iste osebe.
• Profili oseb: pri person_profiles: 'never' ni prepoznanega profila, na katerega bi vezali lastnosti uporabnika za filtre in analizo oseb.
• Posnetki sej in ankete: brez privolitve sta v načinu brez piškotkov izključeni, ker potrebujeta shranjevanje v brskalniku.
• Funkcijske zastavice: brez predpomnjenih vrednosti v brskalniku so lahko ob nalaganju strani na voljo pozneje, razen če so vrednosti pripravljene vnaprej.
• Lokacija in zaznavanje botov: pri vključenem strežniškem načinu za zgoščeno vrednost se dogodki ne obogatijo z lokacijo prek GeoIP ali z zaznavo botov na podlagi naslova IP.

Če storitev potrebuje analizo vračanja iste osebe, segmentiranje prijavljenih računov ali personalizacijo po lastnostih uporabnika, rezultatov načina always ni mogoče obravnavati enako kot rezultatov analitike s prepoznavo uporabnikov. Za štetje obiskov strani je menjava lahko sprejemljiva, vendar je treba večdnevno število edinstvenih obiskovalcev razlagati ob dnevnem menjavanju identifikatorja.

Tehnična nastavitev še ni pravna podlaga

Odsotnost piškotkov sama ne določa, katere podatke obdelujete ali zakaj jih smete obdelovati. Naslov IP in oznaka brskalnika sta vhodna podatka pri strežniškem izračunu zgoščene vrednosti; tudi lastnosti vaših dogodkov lahko vsebujejo osebne podatke. Člen 6 Splošne uredbe o varstvu podatkov za obdelavo osebnih podatkov zahteva ustrezno pravno podlago, ki je vrednost cookieless_mode sama ne izbere.

PostHogova dokumentacija o zasebnosti navaja oblak EU s strežniki v Frankfurtu, odgovornost za odločitev o zbranih podatkih, skladnosti in obveščanju uporabnikov pa pripisuje upravljavcu storitve. Pri slovenski storitvi zato skupaj z regijo projekta določite tudi nabor dogodkov in njihovih lastnosti, namen njihove obdelave ter ustrezno pravno podlago in obvestilo uporabnikom.

Preberite tudi:

• 16.326 baz Supabase je bilo berljivih brez prijave: težava je bila v nastavitvah
• YouTube preizkuša iskalnik ustvarjalcev, analitika ostaja prostovoljna
• XTB ali DEGIRO: brez provizije lahko izgubi pri menjavi valute