Защо PostHog изисква съгласие — и защо отговорът не е един и същ за всеки модул

Уеб SDK на PostHog не е пасивен таг на страница. При стандартна инициализация SDK записва един или повече записи за постоянство — по подразбиране комбинирана схема с бисквитка и localStorage под ключ ph_{projectKey}_posthog — генерира стабилен отличителен идентификатор, улавя началния преглед на страницата с реферер, UTM параметри и идентификатори на кликове, и отваря дългосрочен канал за събития към конфигурирания хост за поглъщане. Ако записът на сесии е активиран на ниво проект, SDK допълнително започва да предава непрекъснат запис на рендерирания DOM, координатите на мишката и входните събития. Ако са конфигурирани флагове за функции, SDK ги оценява спрямо отличителния идентификатор, съхранява решенията за сесията и излъчва събитие $feature_flag_called за всяка оценка.

Всяка от тези дейности съответства на различна порта за съгласие. Съхраняването на отличителен идентификатор е операция за съхранение и достъп по Article 5(3) от Директивата за ePrivacy и изисква предварително, свободно дадено, конкретно, информирано и недвусмислено съгласие в EEA, UK и всяка юрисдикция, която е приела същия стандарт. Улавянето на поведенчески събития е обработка на лични данни по GDPR, тъй като комбинацията от идентификатор, IP адрес и поведенческа следа е достатъчна, за да се идентифицира отделно лице. Записът на сесии попада в отделна, по-строга категория по насоките на EDPB за запис на сесии — записът улавя рендерирания DOM и всяко немаскирано поле за въвеждане и изисква изрично, детайлно съгласие, различно от общото съгласие за аналитика. Оценката на флаговете за функции е деликатното: проверката на флаг, която връща булева стойност, сама по себе си не изисква съгласие, но запазването на назначението на флага на потребителя към стабилен идентификатор между сесиите изисква, защото точно така експериментите с флагове създават проследими данни на ниво потребител.

Какво записва PostHog преди съгласие — и какво трябва да бъде потиснато

Стандартният PostHog Browser SDK записва следното при инициализация: един комбиниран запис с бисквитка и localStorage под ph_{projectKey}_posthog, съдържащ отличителния идентификатор, идентификатора на сесията и решенията за флаговете на функциите, плюс при активиран запис на сесии — допълнителен буфер за запис в паметта, който се изпразва към крайната точка за поглъщане на всеки няколко секунди. SDK изпраща и незабавно събитие $pageview, а ако автоулавянето е включено — всяко следващо кликване, взаимодействие с форма и яростно кликване на страницата.

Препоръчителният шаблон е да се инициализира PostHog с opt_out_capturing_by_default: true и disable_session_recording: true, след което да се превключат и двата флага, щом банерът за съгласие върне положителен сигнал. Това е позицията за интеграция, която документацията на PostHog вече препоръчва и оцелява при проверка от регулатор, защото обръща стандартното: нищо не се улавя, докато не бъде записано съгласие, а SDK осигурява чист преход вместо конфигурация на база на съществуващо състояние.

Бисквитките, записите в localStorage и идентификаторите, които PostHog съхранява

Browser SDK 1.x записва един запис за постоянство на проект, под ключ ph_{projectKey}_posthog, с изтичане по подразбиране 365 дни. Опцията за инициализация persistence управлява основния механизъм: само cookie, само localStorage, localStorage+cookie (по подразбиране), sessionStorage или memory. За деплоймент с приоритет на съгласието, memory постоянство е правилното по подразбиране, когато съгласие все още не е дадено — гарантира, че никой идентификатор не надживява сесията на страницата — с преход към localStorage+cookie след превключване на съгласието. SDK записва и маркер за включване или изключване под __ph_opt_in_out_{projectKey}, за да запомни избора на потребителя между посещенията; самият маркер е строго необходима бисквитка, тъй като съхранява решение за съгласие.

Съпоставяне на модулите на PostHog с рамките за съгласие

PostHog не имплементира нативно IAB TCF или IAB Global Privacy Platform и не е изграден като доставчик на адтех. Въпреки това се интегрира с Google Consent Mode v2 чрез мостово решение от страна на издателя, излага нативно API за включване и изключване и зачита хедъра Do Not Track чрез опцията за инициализация respect_dnt. Шаблонът, който работи в производство, третира всеки модул на PostHog като отделна порта, обвързана с конкретен сигнал от CMP.

• Продуктови аналитични събития са обвързани с аналитичната цел. В TCF терминология това най-често е цел 8 (измерване на ефективността на съдържанието) в комбинация с цел 1 (съхранение и/или достъп до информация). За Consent Mode това съответства на analytics_storage.
• Записът на сесии е зад по-строга порта. Записът на сесии на PostHog улавя рендерирания DOM и всяко немаскирано поле за въвеждане, затова включването на ниво предпочитания или изследване, отделно от аналитиката, е защитима позиция по насоките на EDPB.
• Флагове за функции и експериментиране могат да работят с временна, вътрешнопаметна оценка на основание законен интерес, когато целта е само да се промени рендерираната страница. Постоянното назначение на флага, свързано със стабилен идентификатор между сесиите, изисква същото съгласие като аналитиката, тъй като именно тогава флагът се превръща в проследима точка с данни на ниво потребител.
• Анкети и обратна връзка са обвързани с порта за запис на сесии, когато събират свободен текст, или с порта за аналитика, когато събират само оценки или единични отговори.

Шаблонът за интеграция, който работи

Референтният деплоймент има четири части: CMP, който излага събитие за промяна на съгласието в реално време; отложен bootstrap, инициализиращ PostHog с деактивирано улавяне и запис; слушател за съгласие, превключващ opt_in_capturing и ключа за запис при отваряне на съответните порти; и път за отказ, извикващ opt_out_capturing, спиращ буфера за запис и изчистващ постоянните идентификатори чрез API за нулиране на SDK.

Уеб имплементация

Най-чистият шаблон е да заредите PostHog SDK на всяка страница, но да извикате posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) като начален bootstrap. Абонирайте се за събитието за промяна на съгласието на CMP. Когато категорията аналитика преминава към true, извикайте posthog.set_config({ persistence: 'localStorage+cookie' }) последвано от posthog.opt_in_capturing(); това повторно активира улавянето на събития и преходът на постоянството започва да записва отличителния идентификатор. Когато категорията за запис на сесии премине към true, извикайте posthog.startSessionRecording(). Когато някоя порта бъде оттеглена, извикайте posthog.opt_out_capturing() за портата за аналитика или posthog.stopSessionRecording() за портата за запис, изтеклите постоянни записи чрез posthog.reset() и изпратете заявка за изтриване чрез GDPR API на PostHog, ако потребителят е упражнил правото си на заличаване.

Избор на регион: PostHog Cloud US срещу EU срещу самостоятелно хостван

PostHog работи в два облачни региона — US (us.posthog.com) и EU (eu.posthog.com) — и поддържа самостоятелно хоствани инсталации на собствена инфраструктура на клиента. За EEA и UK трафика EU облакът е правилното по подразбиране; поддържа поглъщането, обработката и съхранението вътре в EEA и намалява излагането на Schrems II, което носи всеки аналитичен деплоймент в US регион. Опцията за инициализация api_host фиксира региона. Самостоятелно хостваният PostHog премества целия стек върху собствената инфраструктура на издателя, което е най-силната позиция за резидентност на данните, но не премахва задълженията за съгласие — правното основание следва данните, а не оператора. Избраният вариант трябва да бъде отразен в уведомлението за поверителност и записите за обработка на администратора.

Сървърно улавяне

PostHog поддържа сървърно поглъщане на събития чрез Python, Node, Go, Ruby и PHP SDK-та. Сървърните събития не са освободени от съгласие — правното основание следва данните — но сървърното поглъщане дава на издателя пълен контрол върху това кои полета се излъчват и кога. Обичаен шаблон е да се улавя минимален набор от само необходими събития от страна на сървъра на основание законен интерес, след което да се обогатяват тези събития с поведенчески детайли от клиента само след като потребителят е дал съгласие за аналитика. Сървърните и клиентските събития се обединяват по един и същ отличителен идентификатор, когато съгласието е превключено; преди съгласие, сървърните събития се излъчват с анонимен, временен идентификатор, нулиран при всяка сесия.

Валидиране на интеграцията и одиторска следа

Стъпката за валидиране е това, което проверяват регулаторите и което издателите най-често пропускат. Правилно интегрираният деплоймент на PostHog трябва да премине четири теста последователно. Първо, чиста браузърна сесия с показан банер, но без направен избор, трябва да произведе нула заявки към конфигурирания api_host освен извличането на файла на SDK, нула ph_ бисквитки в document.cookie и нула ph_ записи в localStorage. Второ, отказът от аналитика трябва да запази това състояние — без улавяне, без запис, без постоянен идентификатор. Трето, приемането на аналитика трябва да произведе незабавно събитие $opt_in, очаквания запис за постоянство ph_{projectKey}_posthog с правилни атрибути SameSite и поток от събития към конфигурирания хост. Четвърто, оттеглянето на съгласие след факта трябва незабавно да спре по-нататъшното улавяне и запис, да изтече постоянните идентификатори и да задейства заявка за изтриване чрез GDPR API на PostHog, ако потребителят е упражнил заличаването.

Очакването за одиторска следа съгласно насоките за банери с бисквитки на EDPB от 2023 г. и подновените приоритети на работната група за 2026 г. е, че издателят може да докаже за всяко дадено събитие в проекта PostHog, че потребителят, генерирал го, е дал валидно съгласие в момента на улавяне. Стандартният шаблон е да се зададат версията на съгласието и клеймото за времеви момент като свойства на лице на отличителния ID чрез posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }), така че всяко отделно събитие да може да бъде проследено до конкретен запис в дневника за съгласие. Правилно портиран деплоймент, съчетан с избор на регион, съответстващ на аудиторията, постоянство с memory по подразбиране и път за изтриване, активиращ се при оттегляне, е това, което превръща PostHog от регулаторен риск за концентрация в защитим център на стека за продуктова аналитика.