PostHogがコンセントを必要とする理由、そしてすべてのモジュールで答えが同じでない理由

PostHogのWeb SDKは受動的なページタグではありません。デフォルトの初期化では、SDKは1つ以上のファーストパーティ永続化エントリを設定します。デフォルトではph_{projectKey}_posthogの下にキーされたcookieとlocalStorageの組み合わせスキームで、安定したdistinct識別子を生成し、リファラー、UTMパラメーター、クリック識別子を含む最初のページビューをキャプチャし、設定された取り込みホストへの長命なイベントチャンネルを開きます。セッションリプレイがプロジェクトレベルで有効になっている場合、SDKはさらにレンダリングされたDOM、マウス座標、入力イベントの継続的な記録のストリーミングを開始します。フィーチャーフラグが設定されている場合、SDKはdistinct識別子に対してそれらを評価し、セッションの決定を永続化し、各評価に対して$feature_flag_calledイベントを発行します。

これらの各アクティビティは異なるコンセントゲートにマップされます。distinct識別子の永続化は、ePrivacy指令の第5条(3)の下でのストレージとアクセス操作であり、EEA、英国、および同じ標準を採用したすべての管轄区域において、事前の、自由に与えられた、特定の、情報に基づいた、明確なコンセントが必要です。行動イベントのキャプチャは、識別子、IPアドレス、行動トレースの組み合わせが個人を特定するのに十分であるため、GDPRの下での個人データの処理です。セッションリプレイは、EDPBのセッションリプレイガイダンスの下では別の、より厳しいカテゴリーに属します。リプレイはレンダリングされたDOMとマスクされていない入力フィールドをキャプチャするため、一般的なアナリティクスコンセントとは異なる明示的で詳細なコンセントが必要です。フィーチャーフラグ評価は微妙なものです。ブール値を返すフラグチェック自体はコンセントを必要としませんが、セッションをまたいで安定した識別子にユーザーのフラグ割り当てを永続化することは必要です。それがフラグベースの実験が追跡可能なユーザーレベルデータを作成する方法だからです。

PostHogがコンセント前に書くもの、そして抑制すべきもの

デフォルトのPostHog Browser SDKは初期化時に次のものを書きます。ph_{projectKey}_posthogの下にdistinct識別子、セッション識別子、フィーチャーフラグの決定を含む1つの組み合わせcookieとlocalStorageエントリ、そしてセッションリプレイが有効な場合は、数秒ごとに取り込みエンドポイントにフラッシュされる追加のメモリ内記録バッファ。SDKはまた即座に$pageviewイベントを送信し、オートキャプチャがオンの場合はページ上のすべての後続のクリック、フォームインタラクション、レイジクリックも送信します。

推奨パターンは、opt_out_capturing_by_default: trueとdisable_session_recording: trueでPostHogを初期化し、コンセントバナーが肯定的なシグナルを返したら両方のフラグを切り替えることです。これはPostHogのドキュメントが現在推奨している統合姿勢であり、規制当局のレビューに耐える姿勢です。コンセントが記録されるまで何もキャプチャされず、SDKはステートフルな改修ではなくクリーンな移行を提供するため、デフォルトを逆転させます。

PostHogが永続化するcookie、localStorageエントリ、識別子

Browser SDK 1.xはプロジェクトごとに1つの永続化エントリを書き、ph_{projectKey}_posthogの下にキーされ、デフォルトで365日の有効期限があります。persistence initオプションが基礎となるメカニズムを制御します。cookieのみ、localStorageのみ、localStorage+cookie（デフォルト）、sessionStorage、またはmemory。コンセントファーストのデプロイメントでは、コンセントがまだ付与されていない場合はmemory永続化が適切なデフォルトです。識別子がページセッションを超えないことを保証し、コンセントが切り替わったらlocalStorage+cookieに移行します。SDKはまた__ph_opt_in_out_{projectKey}の下にオプトインまたはオプトアウトマーカーを書き、訪問をまたいでユーザーの選択を覚えています。そのマーカー自体はコンセント決定を永続化するため、厳密に必要なcookieです。

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のガイダンスの下では、アナリティクスとは異なる設定レベルまたは調査レベルのオプトインが守りやすい立場です。
• フィーチャーフラグと実験は、目標がレンダリングされたページを変更するだけの場合、正当な利益の根拠の下でエフェメラルなメモリ内評価で実行できます。セッションをまたいで安定した識別子に結び付けられた永続的なフラグ割り当ては、アナリティクスと同じコンセントを必要とします。それがフラグが追跡可能なユーザーレベルのデータポイントになる瞬間だからです。
• サーベイとフィードバックは、自由記述入力を収集する場合はセッションリプレイと同じゲートにバインドされ、評価や単一選択の回答のみを収集する場合はアナリティクスゲートにバインドされます。

機能する統合パターン

リファレンスデプロイメントには4つの部分があります。リアルタイムのコンセント変更イベントを公開するCMP、キャプチャとリプレイを無効にしてPostHogを初期化する遅延ブートストラップ、関連するゲートが開いたときにopt_in_capturingと記録スイッチを切り替えるコンセントリスナー、そしてopt_out_capturingを呼び出し、リプレイバッファを停止し、SDKのリセットAPIを通じて永続的な識別子をクリアする撤退パスです。

Web実装

最もクリーンなパターンは、すべてのページに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()を呼び出します。これによりイベントキャプチャが再有効化され、永続化の移行がdistinct識別子の書き込みを開始します。セッションリプレイカテゴリがtrueに移行したら、posthog.startSessionRecording()を呼び出します。いずれかのゲートが撤退したら、アナリティクスゲートにはposthog.opt_out_capturing()を、リプレイゲートにはposthog.stopSessionRecording()を呼び出し、posthog.reset()で関連する永続化エントリを期限切れにし、ユーザーが消去権を行使した場合はPostHogのGDPR APIを通じて削除リクエストを送信します。

リージョン選択：PostHog Cloud USとEUとセルフホスト

PostHogは2つのクラウドリージョンを運営しています。US（us.posthog.com）とEU（eu.posthog.com）で、顧客自身のインフラ上でのセルフホストインストールもサポートしています。EEAと英国のトラフィックには、EUクラウドが適切なデフォルトです。EEA内で取り込み、処理、ストレージを維持し、米国リージョンのアナリティクスデプロイメントが持つSchrems IIリスクを軽減します。api_host initオプションがリージョンを固定します。セルフホストのPostHogはスタック全体をパブリッシャー自身のインフラに移動させ、最強のデータレジデンシー姿勢ですが、コンセント義務を取り除きません。法的根拠はデータに従い、オペレーターには従いません。どちらのオプションを選択してもプライバシー通知と管理者の処理記録に反映する必要があります。

サーバーサイドキャプチャ

PostHogはPython、Node、Go、Ruby、PHP SDKを通じてサーバーサイドイベントの取り込みをサポートしています。サーバーサイドイベントはコンセントから免除されません。法的根拠はデータに従います。しかしサーバーサイドの取り込みにより、パブリッシャーはどのフィールドをいつ発行するかを完全に制御できます。一般的なパターンは、正当な利益の下でサーバーサイドで最小限の必須イベントセットをキャプチャし、ユーザーがアナリティクスコンセントを付与した後にのみクライアントからの行動の詳細でそれらのイベントを充実させることです。コンセントが切り替わった後、サーバーサイドとクライアントサイドのイベントは同じdistinct識別子で結合されます。コンセント前は、サーバーサイドのイベントはすべてのセッションでリセットされる匿名のエフェメラル識別子で発行されます。

統合と監査証跡の検証

検証ステップは規制当局が確認し、パブリッシャーが最もよくスキップするものです。正しく統合されたPostHogデプロイメントは、順番に4つのテストに合格する必要があります。第一に、バナーが表示されているが選択がされていないクリーンなブラウザセッションは、SDKファイルフェッチを超えた設定済みapi_hostへのゼロリクエスト、document.cookieのゼロのph_ cookie、localStorageのゼロのph_エントリを生成する必要があります。第二に、アナリティクスを拒否するとその状態を維持する必要があります。キャプチャなし、記録なし、永続的な識別子なし。第三に、アナリティクスを承認すると即座の$opt_inイベント、正しいSameSite属性を持つ期待されるph_{projectKey}_posthog永続化エントリ、設定されたホストに流れるイベントトラフィックを生成する必要があります。第四に、事後にコンセントを撤退すると、それ以降のキャプチャとリプレイを即座に停止し、永続的な識別子を期限切れにし、ユーザーが消去を行使した場合はPostHogのGDPR APIを通じて削除リクエストをトリガーする必要があります。

EDPBの2023年クッキーバナーガイドラインと更新された2026年タスクフォースの優先事項の下での監査証跡の期待は、パブリッシャーがPostHogプロジェクトの任意のイベントについて、それを生成したユーザーがキャプチャの瞬間に有効なコンセントを与えていたことを証明できることです。標準パターンは、posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts })を通じてdistinct IDにコンセントバージョンとタイムスタンプをパーソンプロパティとして設定し、個々のイベントを特定のコンセントログエントリに追跡できるようにすることです。適切にゲートされたデプロイメントは、オーディエンスに一致したリージョン選択、メモリをデフォルトとする永続化、撤退時に有効化される削除パスと組み合わせることで、PostHogを規制上の集中リスクからプロダクトアナリティクススタックの守れる中心へと変えます。