PostHog에 동의가 필요한 이유 — 그리고 모든 모듈에 대해 답이 동일하지 않은 이유

PostHog 웹 SDK는 수동적인 페이지 태그가 아닙니다. 기본 초기화 시 SDK는 하나 이상의 퍼스트파티 영속성 항목을 설정합니다. 기본적으로 ph_{projectKey}_posthog 아래에 키가 지정된 결합된 쿠키 플러스 localStorage 체계로, 안정적인 고유 식별자를 생성하고, 리퍼러, UTM 매개변수, 클릭 식별자가 포함된 초기 페이지뷰를 캡처하고, 구성된 수집 호스트에 장기 이벤트 채널을 엽니다. 세션 리플레이가 프로젝트 수준에서 활성화된 경우 SDK는 또한 렌더링된 DOM, 마우스 좌표, 입력 이벤트의 연속 기록 스트리밍을 시작합니다. 기능 플래그가 구성된 경우 SDK는 고유 식별자에 대해 평가하고, 세션에 대한 결정을 영속화하며, 각 평가에 대해 $feature_flag_called 이벤트를 발생시킵니다.

이러한 각 활동은 서로 다른 동의 게이트에 매핑됩니다. 고유 식별자를 영속화하는 것은 ePrivacy 지침의 제5조(3)에 따른 저장 및 액세스 작업이며 EEA, 영국, 동일한 표준을 도입한 모든 관할권에서 사전, 자유롭게 제공된, 특정, 정보에 기반한, 모호하지 않은 동의가 필요합니다. 행동 이벤트를 캡처하는 것은 식별자, IP 주소, 행동 추적의 조합이 개인을 식별하기에 충분하기 때문에 GDPR 하에서 개인 데이터 처리입니다. 세션 리플레이는 EDPB의 세션 리플레이 지침 하에서 별도의 더 엄격한 범주에 속합니다. 리플레이는 렌더링된 DOM과 마스킹되지 않은 입력 필드를 캡처하므로 일반적인 분석 동의와는 구별되는 명시적이고 세분화된 동의가 필요합니다. 기능 플래그 평가는 가장 미묘한 것입니다. 부울을 반환하는 플래그 확인 자체는 동의가 필요하지 않지만, 세션 전반에 걸쳐 안정적인 식별자에 대한 사용자의 플래그 할당을 영속화하는 것은 필요합니다. 이것이 플래그 기반 실험이 추적 가능한 사용자 수준 데이터를 만드는 방법이기 때문입니다.

PostHog가 동의 전에 쓰는 것 — 그리고 억제해야 하는 것

기본 PostHog Browser SDK는 초기화 시 다음을 씁니다. 고유 식별자, 세션 식별자, 기능 플래그 결정을 포함하는 ph_{projectKey}_posthog 아래의 하나의 결합된 쿠키 및 localStorage 항목, 그리고 세션 리플레이가 활성화된 경우 몇 초마다 수집 엔드포인트로 플러시되는 추가 메모리 내 기록 버퍼. SDK는 또한 즉시 $pageview 이벤트를 보내고, 자동 캡처가 켜진 경우 페이지의 모든 후속 클릭, 폼 인터랙션, 레이지 클릭을 보냅니다.

권장 패턴은 opt_out_capturing_by_default: true와 disable_session_recording: true로 PostHog를 초기화한 다음, 동의 배너가 긍정적인 신호를 반환하면 두 플래그를 모두 전환하는 것입니다. 이것은 PostHog 문서가 현재 권장하는 통합 자세이며, 기본값을 역전시키기 때문에 규제 기관의 검토를 견디는 자세입니다. 동의가 기록될 때까지 아무것도 캡처되지 않으며 SDK는 상태 저장 개조 대신 깔끔한 전환을 제공합니다.

PostHog가 영속화하는 쿠키, localStorage 항목, 식별자

Browser SDK 1.x는 프로젝트당 하나의 영속성 항목을 씁니다. ph_{projectKey}_posthog 아래에 키가 지정되고 기본적으로 365일 만료됩니다. persistence init 옵션이 기본 메커니즘을 제어합니다. 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를 노출하며, respect_dnt init 옵션을 통해 Do Not Track 헤더를 준수합니다. 프로덕션에서 작동하는 패턴은 각 PostHog 모듈을 특정 CMP 신호에 바인딩된 별도의 게이트로 처리합니다.

• 제품 분석 이벤트는 분석 목적에 바인딩됩니다. TCF 용어로 이것은 가장 일반적으로 목적 8(콘텐츠 성능 측정)과 목적 1(정보 저장 및/또는 액세스)의 조합입니다. Consent Mode의 경우 이것은 analytics_storage에 매핑됩니다.
• 세션 리플레이는 더 엄격한 게이트 뒤에 있습니다. PostHog의 세션 리플레이는 렌더링된 DOM과 마스킹되지 않은 입력 필드를 캡처하므로 EDPB 지침 하에서 분석과는 구별되는 기본 설정 수준 또는 연구 수준의 옵트인이 방어 가능한 자세입니다.
• 기능 플래그 및 실험은 목표가 렌더링된 페이지만 변경하는 것일 때 합법적 이익 근거 하에서 임시, 메모리 내 평가로 실행될 수 있습니다. 세션 전반에 걸쳐 안정적인 식별자에 연결된 영구적인 플래그 할당은 분석과 동일한 동의가 필요합니다. 플래그가 추적 가능한 사용자 수준 데이터 포인트가 되는 것은 그때이기 때문입니다.
• 설문 조사 및 피드백은 자유 텍스트 입력을 수집할 때 세션 리플레이와 동일한 게이트에 바인딩되고, 평가 또는 단일 선택 응답만 수집할 때 분석 게이트에 바인딩됩니다.

작동하는 통합 패턴

참조 배포에는 네 가지 부분이 있습니다. 실시간 동의 변경 이벤트를 노출하는 CMP, 캡처 및 리플레이를 비활성화하여 PostHog를 초기화하는 지연된 부트스트랩, 관련 게이트가 열릴 때 opt_in_capturing과 기록 스위치를 전환하는 동의 리스너, 그리고 opt_out_capturing을 호출하고, 리플레이 버퍼를 중지하고, SDK의 재설정 API를 통해 영구 식별자를 지우는 철회 경로입니다.

웹 구현

가장 깔끔한 패턴은 모든 페이지에 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 })를 호출하는 것입니다. CMP의 동의 변경 이벤트를 구독합니다. 분석 카테고리가 true로 전환되면 posthog.set_config({ persistence: 'localStorage+cookie' })를 호출한 다음 posthog.opt_in_capturing()를 호출합니다. 이렇게 하면 이벤트 캡처가 다시 활성화되고 영속성 전환이 고유 식별자 쓰기를 시작합니다. 세션 리플레이 카테고리가 true로 전환되면 posthog.startSessionRecording()을 호출합니다. 어느 게이트든 철회되면 분석 게이트에는 posthog.opt_out_capturing()를, 리플레이 게이트에는 posthog.stopSessionRecording()을 호출하고, posthog.reset()을 통해 관련 영속성 항목을 만료시키고, 사용자가 삭제 권리를 행사한 경우 PostHog의 GDPR API를 통해 삭제 요청을 보냅니다.

지역 선택: PostHog Cloud 미국 vs EU vs 셀프 호스팅

PostHog는 두 개의 클라우드 지역을 운영합니다. 미국(us.posthog.com)과 EU(eu.posthog.com)이며, 고객 자체 인프라에서 셀프 호스팅 설치를 지원합니다. EEA 및 영국 트래픽의 경우 EU 클라우드가 올바른 기본값입니다. EEA 내에서 수집, 처리, 저장을 유지하고 미국 지역 분석 배포가 지니는 Schrems II 노출을 줄입니다. api_host init 옵션이 지역을 고정합니다. 셀프 호스팅 PostHog는 전체 스택을 퍼블리셔 자체 인프라로 이동시키며, 이것이 가장 강력한 데이터 거주 자세이지만 동의 의무를 제거하지는 않습니다. 법적 근거는 데이터를 따르며 운영자를 따르지 않습니다. 선택된 옵션은 개인 정보 보호 고지와 관리자의 처리 기록에 반영되어야 합니다.

서버 측 캡처

PostHog는 Python, Node, Go, Ruby, PHP SDK를 통한 서버 측 이벤트 수집을 지원합니다. 서버 측 이벤트는 동의에서 면제되지 않습니다. 법적 근거는 데이터를 따릅니다. 그러나 서버 측 수집은 퍼블리셔에게 어떤 필드가 언제 발생되는지 완전한 제어권을 부여합니다. 일반적인 패턴은 합법적 이익 하에 서버 측에서 최소한의 필수 이벤트 세트를 캡처한 다음, 사용자가 분석 동의를 부여한 후에만 클라이언트의 행동 세부 정보로 해당 이벤트를 보강하는 것입니다. 동의가 전환된 후 서버 측과 클라이언트 측 이벤트는 동일한 고유 식별자에서 합쳐집니다. 동의 전에 서버 측 이벤트는 모든 세션에서 재설정되는 익명의 임시 식별자로 발생됩니다.

통합 및 감사 추적 검증

검증 단계는 규제 기관이 확인하고 퍼블리셔가 가장 자주 건너뛰는 것입니다. 올바르게 통합된 PostHog 배포는 순서대로 네 가지 테스트를 통과해야 합니다. 첫째, 배너가 표시되었지만 선택이 이루어지지 않은 깨끗한 브라우저 세션은 SDK 파일 가져오기를 제외한 구성된 api_host에 대한 제로 요청, document.cookie의 제로 ph_ 쿠키, localStorage의 제로 ph_ 항목을 생성해야 합니다. 둘째, 분석을 거부하면 그 상태를 유지해야 합니다. 캡처 없음, 기록 없음, 영구 식별자 없음. 셋째, 분석을 수락하면 즉각적인 $opt_in 이벤트, 올바른 SameSite 속성을 가진 예상된 ph_{projectKey}_posthog 영속성 항목, 구성된 호스트로 흐르는 이벤트 트래픽을 생성해야 합니다. 넷째, 이후에 동의를 철회하면 추가 캡처 및 리플레이를 즉시 중지하고, 영구 식별자를 만료시키고, 사용자가 삭제를 행사한 경우 PostHog의 GDPR API를 통해 삭제 요청을 트리거해야 합니다.

EDPB의 2023년 쿠키 배너 지침과 갱신된 2026년 태스크포스 우선 순위 하에서 감사 추적 기대는 퍼블리셔가 PostHog 프로젝트의 모든 이벤트에 대해 이를 생성한 사용자가 캡처 시점에 유효한 동의를 제공했음을 증명할 수 있어야 한다는 것입니다. 표준 패턴은 posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts })를 통해 고유 ID의 인물 속성으로 동의 버전과 타임스탬프를 설정하여 모든 개별 이벤트를 특정 동의 로그 항목까지 추적할 수 있도록 하는 것입니다. 올바르게 게이트된 배포는 대상과 일치하는 지역 선택, 기본적으로 메모리를 사용하는 영속성, 철회 시 활성화되는 삭제 경로와 결합하여 PostHog를 규제 집중 위험에서 제품 분석 스택의 방어 가능한 중심으로 변환시키는 것입니다.