Почему PostHog требует согласия — и почему ответ не одинаков для каждого модуля

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

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

Что PostHog пишет до согласия — и что должно быть подавлено

SDK браузера PostHog по умолчанию пишет следующее при инициализации: одну комбинированную запись cookie и localStorage под ph_{projectKey}_posthog, содержащую отдельный идентификатор, идентификатор сеанса и решения флагов функций, плюс, если повтор сеанса включён, дополнительный буфер записи в памяти, который сбрасывается на эндпоинт поглощения каждые несколько секунд. SDK также отправляет немедленное событие $pageview и, если включён autocapture, каждый последующий клик, взаимодействие с формой и rage-click на странице.

Рекомендуемый паттерн — инициализировать PostHog с opt_out_capturing_by_default: true и disable_session_recording: true, затем переключить оба флага, как только баннер согласия возвращает положительный сигнал. Это позиция интеграции, которую теперь рекомендует документация PostHog, и это позиция, которая переживает обзор регулятора, поскольку она инвертирует значение по умолчанию: ничего не захватывается до того, как согласие записано, и SDK обеспечивает чистый переход, а не stateful ретрофит.

Cookie, записи localStorage и идентификаторы, которые сохраняет PostHog

Браузерный 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, и он не построен как ad-tech поставщик. Однако он интегрируется с 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.

Веб-реализация

Самый чистый паттерн — загрузить SDK PostHog на каждой странице, но вызвать 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 против self-hosted

PostHog управляет двумя cloud-регионами — US (us.posthog.com) и EU (eu.posthog.com) — и поддерживает self-hosted установки на собственной инфраструктуре клиента. Для трафика ЕЭП и Великобритании EU cloud — правильное значение по умолчанию; он держит поглощение, обработку и хранение внутри ЕЭП и снижает экспозицию 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 }), чтобы любое отдельное событие было отслеживаемо обратно к конкретной записи лога согласия. Правильно ограждённое развёртывание, в сочетании с выбором региона, соответствующего аудитории, хранением, которое по умолчанию memory, и путём удаления, который активируется при отзыве, — это то, что превращает PostHog из риска регуляторной концентрации в защищаемый центр стека продуктовой аналитики.