What it is
PostHog combines product analytics, session replay and feature flags in one library. The replay component carries the same masking considerations as any recording tool.
Self-hosting is common, and it genuinely changes some things: no transfer to a third party, no vendor processing agreement to negotiate. It changes nothing about the storage rule, because the identifier is still stored on the visitor’s device.
What a scan matches
A verification scan drives a real browser and records the outbound requests observed during its configured journeys, so PostHog is identified by request hosts and paths rather than by source-code claims. Requests on unvisited paths, after unperformed interactions or solely on the server remain outside that observation.
- posthog.com
- i.posthog.com
- posthog.net
Cookies are classified by name before domain because many analytics and advertising tags write first-party cookies through the page, which places a vendor-related identifier on your domain. Matching known names helps attribute those values without assuming that every first-party cookie came from your own application.
| Cookie | What it is for |
|---|---|
| ph_* | PostHog distinct ID and session state, matched by prefix |
Controlling it with consent
No named adapter. Gate it as a custom script attached to analytics. A self-hosted deployment on your own domain is still gated the same way.
If feature flags are used for anything a visitor experiences, check whether the flag evaluation itself needs to run before consent, and if it does, whether it can run without an identifier.
No named adapter: choose the appropriate control
The product ships named adapters for Google Tag Manager, Google Analytics, the Meta and TikTok pixels, and Klaviyo. Choose the control route that fits this technology: a custom HTTPS script declaration for a browser loader, an individual consent condition inside a tag manager, a platform or app setting, or a click-to-load placeholder for a frame. Server-side integrations need their own enforcement because a browser runtime cannot stop them.
What breaks if it is refused: analytics and replay for refusing visitors, and feature-flag evaluation if it depends on the same library.
Verifying it
Before consent there should be no ph_ cookie and no request to your PostHog host, self-hosted or not. Confirm replay masking on any page with form fields.
- Before a choice: optional tracking endpoints and optional identifiers are absent; any intentionally loaded necessary or functional surface matches the control model described above
- After rejecting optional categories: optional activity remains absent and the refusal persists across a reload
- After granting the relevant category: the expected loader or embed appears and the feature behaves normally
- After withdrawing: new optional activity stops; where the vendor supports a consent signal, verify that the signal is sent as well as checking network behavior
Common questions
Does self-hosting remove the need for consent?
No. The consent rule is about storing and accessing information on the visitor’s device, not about who receives it afterwards. Self-hosting removes a transfer, not the storage.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- PostHog: JavaScript web configuration
Vendor documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.