Чому PostHog потребує згоди — і чому відповідь не однакова для кожного модуля

Веб-SDK PostHog — це не пасивний тег сторінки. При стандартній ініціалізації SDK встановлює один або більше записів постійності першої сторони — за замовчуванням комбінована схема cookie плюс localStorage з ключем під ph_{projectKey}_posthog — генерує стабільний окремий ідентифікатор, захоплює початковий перегляд сторінки з реферером, параметрами UTM та ідентифікаторами кліків, і відкриває довгостроковий канал подій до налаштованого хоста прийому. Якщо відтворення сеансу увімкнено на рівні проекту, SDK також починає транслювати безперервний запис відтвореного DOM, координат миші та подій введення. Якщо налаштовано прапорці функцій, SDK оцінює їх щодо окремого ідентифікатора, зберігає рішення для сеансу та випромінює подію $feature_flag_called для кожної оцінки.

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

Що PostHog записує до згоди — і що слід придушити

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

Рекомендований підхід полягає в ініціалізації PostHog з opt_out_capturing_by_default: true та disable_session_recording: true, а потім перемиканні обох прапорців після того, як банер згоди поверне позитивний сигнал. Це інтеграційна позиція, яку документація PostHog зараз рекомендує, і це позиція, яка витримає перевірку регулятора, оскільки вона інвертує замовчування: нічого не захоплюється, поки не зареєстровано згоду, і SDK забезпечує чистий перехід, а не ретрофіт зі станом.

Файли cookie, записи localStorage та ідентифікатори, які зберігає PostHog

Browser SDK 1.x записує один запис постійності на проект, з ключем під ph_{projectKey}_posthog, з типовим терміном дії 365 днів. Параметр ініціалізації persistence контролює основний механізм: лише cookie, лише localStorage, localStorage+cookie (за замовчуванням), sessionStorage або memory. Для розгортання, де згода є першочерговою, постійність memory є правильним замовчуванням, коли згода ще не надана — це гарантує, що жоден ідентифікатор не переживе сеанс сторінки — з переходом на localStorage+cookie після зміни згоди. SDK також записує маркер opt-in або opt-out під __ph_opt_in_out_{projectKey}, щоб запам'ятати вибір користувача між відвідуваннями; цей маркер сам по собі є строго необхідним файлом cookie, оскільки він зберігає рішення про згоду.

Відображення модулів PostHog на фреймворки згоди

PostHog не реалізує IAB TCF або IAB Global Privacy Platform у рідному вигляді і не побудований як постачальник рекламних технологій. Однак він інтегрується з Google Consent Mode v2 через мости на стороні видавця, надає рідний API opt-in та opt-out і поважає заголовок Do Not Track через параметр ініціалізації respect_dnt. Підхід, який працює у виробництві, розглядає кожен модуль PostHog як окремий шлюз, прив'язаний до конкретного сигналу CMP.

• Події аналітики продуктів прив'язані до мети аналітики. У термінах TCF це найчастіше мета 8 (вимірювання ефективності контенту) у поєднанні з метою 1 (зберігання та/або доступ до інформації). Для Consent Mode це відповідає analytics_storage.
• Відтворення сеансу знаходиться за суворішим шлюзом. Відтворення сеансу PostHog захоплює відтворений DOM та будь-яке незамасковане поле введення, тому opt-in на рівні налаштувань або досліджень, відмінний від аналітики, є захищеною позицією відповідно до вказівок 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 США проти ЄС проти self-hosted

PostHog керує двома хмарними регіонами — США (us.posthog.com) та ЄС (eu.posthog.com) — і підтримує self-hosted інсталяції на власній інфраструктурі клієнта. Для трафіку EEA та Великобританії хмара ЄС є правильним замовчуванням; вона зберігає прийом, обробку та зберігання всередині EEA і зменшує ризик Schrems II, який несе будь-яке аналітичне розгортання в регіоні США. Параметр ініціалізації api_host фіксує регіон. Self-hosted PostHog переміщує весь стек на власну інфраструктуру видавця, що є найміцнішою позицією резидентності даних, але не знімає зобов'язань щодо згоди — правова підстава слідує за даними, а не за оператором. Будь-який обраний варіант повинен бути відображений у повідомленні про конфіденційність та записах обробки контролера.

Захоплення на стороні сервера

PostHog підтримує прийом подій на стороні сервера через SDK Python, Node, Go, Ruby та PHP. Події на стороні сервера не звільнені від згоди — правова підстава слідує за даними — але прийом на стороні сервера дає видавцю повний контроль над тим, які поля випромінюються і коли. Поширений підхід полягає у захопленні мінімального набору лише основних подій на стороні сервера за законним інтересом, а потім збагаченні цих подій поведінковими деталями з клієнта лише після того, як користувач надав аналітичну згоду. Події на стороні сервера та клієнта поєднуються на тому ж окремому ідентифікаторі, коли згода змінилася; до згоди події на стороні сервера випромінюються з анонімним, тимчасовим ідентифікатором, який скидається в кожному сеансі.

Валідація інтеграції та слід аудиту

Крок валідації — це те, що перевіряють регулятори і що видавці найчастіше пропускають. Правильно інтегроване розгортання PostHog повинно пройти чотири тести послідовно. По-перше, чистий сеанс браузера з показаним банером, але без зробленого вибору, повинен давати нуль запитів до налаштованого api_host крім отримання файлу SDK, нуль файлів cookie ph_ у document.cookie та нуль записів ph_ у localStorage. По-друге, відхилення аналітики повинне зберігати цей стан — без захоплення, без запису, без постійного ідентифікатора. По-третє, прийняття аналітики повинне негайно давати подію $opt_in, очікуваний запис постійності ph_{projectKey}_posthog з правильними атрибутами SameSite та потік трафіку подій до налаштованого хоста. По-четверте, відкликання згоди після факту повинне негайно зупиняти подальше захоплення і відтворення, закінчувати термін дії постійних ідентифікаторів та ініціювати запит на видалення через GDPR API PostHog, якщо користувач ініціював видалення.

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