Conversion Optimization
PostHog
Rest of world Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 3 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by PostHog Inc. · posthog.com
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
PostHog is a product analytics suite with experiments and feature flags, and the bench scored it as a capable, developer-facing experimentation tool. Data and integrations is the strong suit at 6-7: a documented data warehouse API with provisioning, job statistics, monitoring metrics and scoped personal API keys, plus Segment as a destination. Sovereignty and pricing transparency both sit at 3: the contracting entity is US-incorporated PostHog Inc., Frankfurt hosting is opt-in at signup rather than the default, and even EU-hosted customers have account information processed in the United States, while the public pricing shows 'Starts at: $0 FREE' and '97% of users pay us $0' and we found no public information on paying-tier prices or usage limits. The remaining criteria cluster at 4 — experimentation scope, statistical rigour, consent and tracking, performance impact — covering flag-based experiments behind both Bayesian and frequentist engines, cookieless tracking modes, and a published flag-load delay of about 100-500ms by default with bootstrapping and local evaluation documented as the fix. Judges agreed closely; the only spread anywhere is single-point, 4-5 on consent and tracking and on performance impact, and 6-7 on data and integrations.
Speaks for it
- Data and integrations scored 6-7, the highest of the bench, on a documented data warehouse API with provisioning, job statistics, monitoring metrics, scoped personal API keys, and Segment as a destination.
- Both Bayesian and frequentist analysis engines are documented by name, covering funnel, mean and ratio metrics.
- Cookieless tracking is documented with 'always' and 'on reject' modes, on a single first-party cookie with no cross-site tracking.
- The flag-load delay of about 100-500ms by default is published, with bootstrapping and local evaluation documented as the flicker fix.
- A free tier is public — 'Starts at: $0 FREE' — with the vendor stating '97% of users pay us $0'.
Held against it
- Sovereignty scored 3, with a US-incorporated contracting entity, EU hosting opt-in rather than default, and account information of even EU-hosted customers processed in the United States.
- Pricing transparency scored 3, and we found no public information on paying-tier prices, usage-metric limits or overage rates.
- Statistical rigour sits at 4, and we found no public information on sample-size or duration guidance, peeking protection, multiple-metric correction or sample ratio mismatch detection.
- Experimentation scope sits at 4, with experiments delivered flag-based in code, and we found no public information on a visual editor, multivariate or multi-page tests, personalisation or holdouts.
- The terms state that fees exclude all taxes, prepaid credits are non-refundable and expire twelve months from purchase, and late balances accrue a finance charge of 1.5% per month.
Best for
- You are an engineering-led team shipping experiments through feature flags in your own code, including running them with a different feature flag library while tracking results in PostHog.
- You want a managed data warehouse with a documented API and Segment as a destination as the analysis backbone behind your tests.
- You want to start experimenting at $0 with usage-based billing before committing budget.
Avoid if
- Your procurement requires an EU contracting entity and EU hosting as the default — the counterparty is US-incorporated PostHog Inc., the UK and German companies are subsidiaries, and the EU region is opt-in at signup.
- Your marketing team needs to build and read tests without engineering help — experiments are documented as flag-based, code-level delivery.
- You must present a computable annual invoice before signing — the captured pages show the $0 entry point and usage-based terms with taxes excluded, and the judges could not compute a paying invoice from them.
The scores
Experiment types & delivery
Show reasoningHide reasoning
How this is scored
What can be tested and where: client-side changes through an editor, server-side and feature experiments through SDKs, multivariate and multi-page tests, and personalisation — judged on what the documentation shows rather than on the feature grid.
0 — Simple A/B split of one page element through a visual editor; no server-side option, no targeting beyond URL.
3 — Client-side A/B and split-URL tests with basic audience targeting, and no SDK or server-side delivery.
5 — Client-side and server-side experiments through documented SDKs for common languages, multivariate and multi-page tests, audience targeting on behaviour and attributes, and rule-based personalisation.
8 — Feature-flag-based experiments sharing one audience and metric model with web tests, mutually exclusive experiment groups, holdouts, edge or CDN delivery, and personalisation that can itself be tested against a control.
10 — One experimentation programme across every surface: web, app, server and edge from the same platform, experiment interactions managed, a documented experiment lifecycle from hypothesis to archived result, and a library of past results a team can search.
The Growth Lead
Flag-based experiments are documented — the control variant name is fixed, other variants are custom, and experiments can even run against an external feature flag library with local evaluation as a path — but this is developer territory: we found no public information on a visual editor my marketing team could use without engineering, and nothing captured documents multivariate or multi-page tests, audience targeting beyond flags, or personalisation. 5 6 12
The E-Commerce Manager
Variant experiments run through feature flags are documented, with a fixed control variant, custom-named others, and a documented path to track experiments through a different feature flag library; the bootstrapping and local evaluation guide shows a server-side path for flags. But we found no public information on a visual editor, split-URL tests, multivariate or multi-page tests, or personalisation that can be tested against a control — the last being exactly what I run tests for. 5 6 12
The Product Engineer
Experiments are flag-based and real, runnable against any feature flag library with results tracked in PostHog, behind both Bayesian and frequentist engines, with variants beyond control freely named. The captured pages stop there: we found no public information on multivariate or multi-page tests, personalisation, holdouts, mutually exclusive groups, or server-side SDKs for a given stack. 5 6 7 8
The CRO Consultant
Experiments are documented as flag-based with a fixed control variant and free naming of the others, and results can still be tracked in PostHog when a client uses a different feature flag library — code-level delivery rather than a visual editor. We found no public information on multivariate or multi-page tests, personalisation, holdouts or mutually exclusive experiments, so this sits below the fully documented client-plus-server scope I need for a multi-project programme. 5 6
The Data Protection Officer
The captured documentation shows experiments built on feature flags — they can even be run with a third-party flag library — alongside a multivariate questions page and a bootstrapping and local-evaluation guide offered as the flicker fix. We found no public information on a visual editor, split-URL testing, personalisation, holdouts, or mutually exclusive experiment groups. 5 6 12
The Skeptic
Experiments are documented as feature-flag workloads with a fixed control variant, freely named others, and funnel, mean and ratio metrics, and results can even be tracked in PostHog while a different feature flag library serves the variants — so delivery is not confined to a client-side snippet. We found no public information on a visual editor, multivariate or multi-page tests, personalisation, holdouts or mutually exclusive experiment groups, which is what separates a full programme from a capable one. 5 6 8
Statistical method & guardrails
Show reasoningHide reasoning
How this is scored
Which statistics decide the winner and what protects the customer from misreading them. Scored on what the vendor documents: the method by name, how peeking and multiple comparisons are handled, and whether sample ratio mismatch is detected.
0 — A "winner" or "probability to beat" figure with no documented method, no stated sample-size guidance and no warning against stopping early.
3 — The method is named (frequentist or Bayesian) but its assumptions are not documented, and nothing prevents a test from being called while it is still underpowered.
5 — Documented method with confidence or credible intervals, a sample-size or test-duration calculator, and stated guidance on when a result may be read.
8 — Sequential testing or an equivalent documented protection against peeking, correction for multiple metrics or variants, sample ratio mismatch detection, variance reduction such as CUPED, and guardrail metrics that can stop a harmful test.
10 — The statistics are auditable: methodology published in enough detail to reproduce a result, the choice of method explained per use case, raw per-visitor data available for independent re-analysis, and the interface refuses to present an underpowered result as a conclusion.
The Growth Lead
Both engines are named with their statistics — Bayesian calculating the probability one variant beats another, frequentist using t-tests and confidence intervals across funnel, mean and ratio metrics — which is more than a bare winner figure. But we found no public information on a sample-size or duration calculator, guidance on when a result may be read, or any handling of peeking, multiple comparisons and sample ratio mismatch, so I could not defend a called winner to finance on this documentation alone. 7 8
The E-Commerce Manager
Both engines are documented by name: a Bayesian engine that reports the probability one variant beats another, and a frequentist engine using t-tests and confidence intervals across funnel, mean and ratio metrics. We found no public information on a sample-size or duration calculator, protection against peeking, correction for multiple variants, or sample ratio mismatch detection, so nothing in the captured pages stops an underpowered test being called a winner mid-campaign. 7 8
The Product Engineer
Both engines are documented by name — a Bayesian engine reporting the probability one variant beats another, and a frequentist engine using t-tests and confidence intervals across funnel, mean and ratio metrics. We found no public information on sample-size guidance, peeking protection, multiple-metric correction, or sample ratio mismatch detection in the captured pages. 7 8
The CRO Consultant
Both methods are named and documented — a Bayesian engine reporting the probability one variant beats another, and a frequentist engine using t-tests and confidence intervals across funnel, mean and ratio metrics. We found no public information on a sample-size or duration calculator, guidance on when a result may be read, or protections against peeking, multiple comparisons and sample ratio mismatch, so I could not safely coach a client on when to call a test. 7 8
The Data Protection Officer
Two engines are documented by name — a Bayesian one that reports the probability one variant is better than another, and a frequentist one using t-tests and confidence intervals across funnel, mean and ratio metrics. We found no public information on sample-size guidance, protection against peeking, correction for multiple variants or metrics, or sample ratio mismatch detection. 7 8
The Skeptic
Both schools are documented by name — a Bayesian engine that reports the probability one variant beats another, and a frequentist engine of t-tests and confidence intervals over funnel, mean and ratio metrics — but we found no public information on the assumptions, priors or significance level behind either. I also found no public information on sample-size or duration guidance, protection against peeking, correction for multiple metrics or variants, or sample ratio mismatch detection; a probability-to-beat figure with undocumented assumptions is marketing, not method. 7 8
Consent & visitor tracking
Show reasoningHide reasoning
How this is scored
Whether the test script respects §25 TDDDG and the ePrivacy rules as evidenced on the vendor's own pages: when the script runs relative to consent, what it stores on the device, whether a cookieless or consent-free mode exists, and how visitor identifiers are handled.
0 — Nothing on the vendor's pages says what the script stores on the device or whether it runs before consent; consent is described as the customer's problem.
3 — Cookies or local storage are listed, and a consent integration is mentioned, but the documentation does not say what the script does before consent is given.
5 — Documented behaviour before and after consent, integration with common consent management platforms, a published list of cookies and storage keys with their lifetime, and IP anonymisation described.
8 — A documented consent-pending mode that holds tracking until consent while variants can still be served, a cookieless or first-party-only option, retention of visitor data stated, and guidance on the legal basis for testing in the EU.
10 — Built for §25 TDDDG: the default configuration stores nothing on the device without consent, a server-side or cookieless mode documented end to end, per-visitor data deletable on request, and the vendor states in writing how each mode maps to consent requirements.
The Growth Lead
The Web SDK offers a cookieless mode with 'always' and 'on reject' settings backed by a cookieless server hash mode, and cookies are first-party with no cross-site tracking — real substance for hooking into our consent tooling. What I still need for a German deployment is missing: we found no public information on what the script does before consent is given, and no published list of storage keys with lifetimes or IP anonymisation. 9 10
The E-Commerce Manager
Cookieless tracking is documented for the JavaScript Web SDK with 'always' and 'on reject' modes after enabling cookieless server hash mode in project settings, cookies are first-party with no cross-site tracking, and the GDPR page points European customers to the Frankfurt cloud. We found no public information on what the script stores or does before consent is given, no published cookie list with lifetimes, and no consent-management-platform integrations. 5 9 10
The Product Engineer
Cookieless tracking is documented with both an always mode and an on-consent-reject mode, on a first-party-only cookie with no cross-site tracking — genuinely consent-aware design. The captured pages do not say what the script does before consent, and we found no public information on consent-management-platform integrations, a cookie list with lifetimes, or IP anonymisation. 9 10 12
The CRO Consultant
The JavaScript SDK documents a cookieless mode with 'always' and 'on reject' settings behind a cookieless server hash option, first-party cookies only with no tracking across sites, and a GDPR page recommending the Frankfurt-hosted cloud. We found no public information on what the script does before consent, consent-management-platform integrations, cookie lifetimes or per-visitor deletion — the first questions a client's data protection officer will ask. 9 10
The Data Protection Officer
A tutorial documents cookieless audience measurement with an always-mode and an on-rejection mode, and the vendor describes a single first-party cookie with no cross-site tracking. What I still cannot answer is whether the test script may run before the consent banner is answered — the on-rejection mode reacts to a refusal and says nothing about the pending state — and we found no public information on a published list of storage keys with their lifetimes, consent management platform integrations, or IP anonymisation. 3 9 10
The Skeptic
The web SDK documents a single first-party cookie, no cross-site tracking, and a cookieless mode with 'always' and 'on reject' settings — real, documented behaviour once consent is refused, which is more than a checkbox integration. We found no public information on what the script stores or transmits while consent is still pending, on consent management platform integrations, on cookie lifetimes, or on IP anonymisation, so the pre-consent question a German buyer must answer stays open. 3 9 10
Snippet performance & flicker
Show reasoningHide reasoning
How this is scored
The cost the client-side snippet imposes on the page it tests: blocking load, flicker of original content, script weight and the effect on Core Web Vitals — scored on what the vendor measures and publishes, not on "lightning fast".
0 — A synchronous snippet with no stated size, no flicker handling and no mention of performance.
3 — An anti-flicker snippet that hides the page until the test loads, with a timeout, and no published figures for script size or load cost.
5 — Script size and loading behaviour documented, asynchronous loading option, flicker handling explained with its trade-off, and CDN delivery of the snippet.
8 — Published performance figures including impact on Core Web Vitals, a self-hosting or first-party-domain option for the script, per-project bundles containing only active experiments, and a server-side or edge alternative for flicker-sensitive tests.
10 — Performance is a stated commitment: measured overhead published and maintained, flicker eliminated by edge or server-side rendering as a documented path, and tooling that shows the customer what their own configuration costs the page.
The Growth Lead
Flag loading latency is actually published — about 100-500ms by default, during which the flag is disabled — and flicker is addressed honestly through bootstrapping flag values during initialisation plus a local evaluation guide. We found no public information on script size, impact on Core Web Vitals, or a self-hosting option for the script itself, so I cannot state what the snippet costs our pages. 12
The E-Commerce Manager
They publish a real figure: by default flags load from their servers taking about 100-500ms, during which the flag is disabled — on a product page that is a visible flicker and a conversion cost. The documented remedy is bootstrapping flag values with the user ID at initialisation plus local evaluation, and separate terms exist for self-hosting the open source edition, which is the first-party path I would want. We found no published script size, no Core Web Vitals impact figures, and no per-project bundles of active experiments. 4 12
The Product Engineer
Publishing that flags load from PostHog servers in about 100–500ms, during which the flag is disabled, with bootstrapping and local evaluation as the documented flicker fix, is honest trade-off documentation of exactly the kind a buyer needs. We found no public information on script size, async loading, Core Web Vitals impact, or self-hosting the snippet. 12
The CRO Consultant
They publish an actual figure — flags load from their servers in about 100 to 500 milliseconds, during which the flag is disabled — and document bootstrapping with local evaluation as the fix for flicker, with a self-hosted open-source edition available under separate terms. We found no public information on script weight, asynchronous loading, Core Web Vitals impact or per-project bundles, so I cannot estimate what a running test would cost a client's page. 4 12
The Data Protection Officer
The vendor publishes an honest figure — flags load from their servers in about 100-500ms, during which the flag is disabled — and documents bootstrapping and local evaluation as the flicker fix, with self-hosted open-source editions available under separate terms. We found no public information on script size, asynchronous loading, or any measured effect on Core Web Vitals. 4 12
The Skeptic
Credit where due: the vendor publishes an honest number — flags load from their servers taking about 100-500ms by default, during which the flag is disabled — and documents bootstrapping and local evaluation as the fix for the flicker that delay causes. We found no public information on script weight, impact on Core Web Vitals, or a first-party or self-hosted delivery path for the snippet itself. 11 12
Analytics, data export & integrations
Show reasoningHide reasoning
How this is scored
Getting results and raw data out: integration with analytics and tag management, export of visitor-level results, warehouse-native analysis, and an API — because an experiment result that cannot be checked in the customer's own data is a claim, not a finding.
0 — Results visible in the vendor's dashboard only; no export, no analytics integration, no API.
3 — CSV export of aggregated results and one analytics integration, with no visitor-level data and no documented API.
5 — Integrations with common analytics and tag managers, export of results, and a documented API for managing experiments and reading results.
8 — Visitor-level raw data export or streaming to a data warehouse, warehouse-native analysis on the customer's own metrics, CDP integration for audiences, and an API with stated limits.
10 — The platform treats the customer's warehouse as the source of truth: metrics defined once and computed there, full historical experiment data exportable in open formats, and a versioned API a team can build its own programme tooling on.
The Growth Lead
The data warehouse API is documented in real depth — provisioning, job statistics, monitoring metrics, scoped keys covering batch export and query access — and the vendor positions itself as the single place to ingest, store and query product data, with a Segment destination available. This approaches warehouse-native analysis, though we found no public information on stated API limits or on exporting raw visitor-level experiment results into our own warehouse for independent re-analysis. 1 13 14
The E-Commerce Manager
The data warehouse API is broad and documented — provisioning and deprovisioning, per-source schemas, job statistics, monitoring metrics including duration p50 and p95, authenticated with personal API keys carrying scopes for warehouse access, batch export and query — and Segment is supported as a destination. We found no public information on stated API rate limits, documented endpoints for reading experiment results, or visitor-level raw data export to my own systems. 1 13 14
The Product Engineer
This is the part I actually care about: a fully documented data warehouse API — provisioning, job statistics, monitoring metrics, batch-export and query scopes, and row counts per billing period — plus a Segment destination and a warehouse pitched as the single place to ingest and query data. It stops short of warehouse-as-source-of-truth: we found no public information on stated API limits or visitor-level export of experiment results. 1 13 14
The CRO Consultant
This is the strong suit: a documented API with bearer-token scopes covers a managed data warehouse — provisioning, job statistics, quality gates, events and persons — and Segment is a supported destination needing only a project API key and instance address. Visitor-level events and persons land in the warehouse and a batch-export scope exists, but we found no public information on stated API limits or documented endpoints for reading experiment results back out, which caps it below the warehouse-native level I would bank on. 1 13 14
The Data Protection Officer
A data warehouse API is documented in unusual detail — provisioning, job statistics, monitoring metrics, and total rows processed within the current billing period — authenticated with personal API keys carrying named scopes, and PostHog is a documented Segment destination with events and persons queryable in the managed warehouse. We found no public information on endpoints for managing experiments themselves, stated API rate limits, or streaming raw visitor-level data to the customer's own warehouse. 1 13 14
The Skeptic
The API documentation is unusually concrete: personal-key bearer auth, granular scopes for queries, batch exports and warehouse views, operational endpoints for a managed warehouse holding events and persons, and even billing-period row counts, with Segment shipping PostHog as a destination. We found no public information on visitor-level export into the customer's own warehouse, analytics-platform integrations beyond Segment, or stated API rate limits, which is what keeps an experiment result independently checkable. 1 13 14
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where visitor data is processed and stored and who the contracting entity is. Independently sourced by the sovereignty pipeline; weighted higher here than in categories that hold only the customer's own data, because the script runs on every visitor to the customer's site and their behaviour is what the platform records.
0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and visitor data leaving the EU without a stated safeguard.
3 — EU data residency offered as an option or an enterprise add-on while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU processing of visitor data as standard and an EU contracting entity, but parts of the chain — CDN, support access, analytics — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure including the delivery of the snippet, EU contracting entity, subprocessor list published, and a DPA covering the visitor data the script collects.
10 — Sovereign end to end and evidenced: vendor, entity, hosting, snippet delivery and every subprocessor European, certification published, and no visitor data reaching a non-EU party at any point.
The Growth Lead
Frankfurt hosting exists and is recommended for GDPR, but it is opt-in at signup with the US region as default, the contracting entity is the US-incorporated PostHog Inc., and even EU-hosted customers have account information processed in the United States. AWS and Google Cloud Platform are the named subprocessors with Data Privacy Framework and SCC claims as the stated safeguards — for our DPO that makes EU residency an option to negotiate, not a default, and the German subsidiary is not the counterparty. 3 10
The E-Commerce Manager
The contracting entity is PostHog Inc., a US company, with the UK and German entities as subsidiaries; hosting is US by default, the Frankfurt cloud is opt-in at signup, and even EU-hosted customers have account information processed in the United States. AWS and Google Cloud Platform are named as hosting subprocessors with EU-US Data Privacy Framework certification and Standard Contractual Clauses stated as safeguards, but the script records every visitor to my shop on a US-anchored chain. 3 10
The Product Engineer
Frankfurt hosting exists but is opt-in at signup rather than the default, the contracting entity is the US-incorporated PostHog Inc. with UK and German entities as subsidiaries, and even EU-hosted customers have account information processed in the United States. AWS and Google Cloud Platform are named for hosting with the Data Privacy Framework and standard contractual clauses as safeguards — residency as an option under a non-EU entity. 3 9 10
The CRO Consultant
The contracting entity is US-incorporated PostHog Inc. with the UK and German companies as subsidiaries, the EU region is an opt-in choice at signup rather than the default, and account information of even EU-hosted customers is processed in the United States. The safeguards on paper are Data Privacy Framework certification, standard contractual clauses, and named subprocessors AWS and Google Cloud with Frankfurt hosting available — but no EU entity contracts for the visitor data as standard, which is the piece my clients' data protection officers cannot sign off. 3 10
The Data Protection Officer
The contracting entity is the US-incorporated PostHog Inc. with UK and German subsidiaries, US hosting is the default, and even EU-cloud customers have account information processed in the United States. Frankfurt hosting exists as an opt-in region and AWS and Google Cloud are named as hosting subprocessors in the privacy policy, but we found no public information on a published subprocessor list covering delivery of the snippet, and the terms acknowledge a third party — AWS — hosts the data collected under the agreement. 3 4 10
The Skeptic
The contracting entity is PostHog Inc. of San Francisco — the UK and German entities are subsidiaries of the US parent — and Frankfurt hosting is an opt-in at signup rather than the default, with even EU-hosted customers' account information processed in the United States. The named subprocessors, Amazon Web Services and Google Cloud Platform, are US providers, with SCCs and the Data Privacy Framework as the stated safeguards; that is EU residency offered as an option under a non-EU entity. 3 10
Pricing transparency
Show reasoningHide reasoning
How this is scored
A category priced by traffic — monthly tracked users, visitors or impressions — where the tier a site lands in depends on numbers the buyer has to estimate. Whether a buyer can compute the real annual cost including traffic limits, overage, server-side or personalisation modules and seats — from public pages alone.
0 — No public prices at all; every tier is a sales conversation.
3 — A starting price or a free tier exists, but the traffic metric, the limits and what happens above them are unstated — the invoice is unknowable.
5 — Tier prices public with the traffic metric and its limits defined, but at least one commonly needed piece (server-side SDKs, personalisation, overage) is unpriced or "contact sales".
8 — Every tier priced publicly with the traffic metric defined, limits, overage rates, module prices, minimum term and VAT treatment stated.
10 — Complete price computability: annual invoice derivable for a given traffic volume, set of modules and team size, with overage and every add-on published.
The Growth Lead
A free tier exists — the vendor states it starts at $0 and that 97% of users pay $0 — and billing is usage-based, with taxes explicitly excluded and prepaid credits non-refundable and expiring after twelve months. But we found no public information on the traffic metric, tier limits, overage rates or module prices, so the annual invoice for a known traffic volume is not computable from what was captured. 1 4
The E-Commerce Manager
The published figures are the entry point: 'Starts at: $0 FREE' and '97% of users pay us $0', with the terms confirming fees based on actual usage, taxes excluded, and fee increases on thirty days' notice. We found no public information on tier prices, the usage metric's definition, traffic limits or overage rates, so what my December peak invoices is not computable from the captured pages. 1 4
The Product Engineer
A $0 free tier that the vendor says 97% of users occupy, usage-based fees, and warehouse row counts tracked per billing period are all public. We found no public information on paid tier prices, traffic metric limits, or overage rates, so a real annual invoice is not computable from the captured pages. 1 4 13
The CRO Consultant
A public free tier exists — the homepage states it starts at $0 with 97% of users paying nothing — and the terms confirm usage-based billing with tax treatment spelled out and even an API that reports warehouse rows per billing period. We found no public information on tier prices, the traffic metric and its limits, or overage rates, so I cannot compute a client's annual invoice before the contract — the number I have to defend to a finance team. 1 4 13
The Data Protection Officer
The homepage shows 'Starts at: $0 FREE' and states '97% of users pay us $0', and the terms add that fees are usage-based, exclude all taxes, and that prepaid credits are non-refundable and expire twelve months from purchase. We found no public information on prices for paying tiers, the usage metric's limits, or what happens above them — a buyer cannot compute the annual cost from the captured pages. 1 4
The Skeptic
A free tier is public — the vendor states "Starts at: $0 FREE" and that "97% of users pay us $0" — and fees are based on actual usage, but we found no public information on tier prices, the traffic or event metric a buyer must estimate, limits, or what happens above them. The terms add friction a buyer should know — prices exclude taxes, prepaid credits are non-refundable and expire after twelve months, and late balances accrue a finance charge of 1.5% per month — none of which makes an annual invoice computable. 1 4
European sovereignty — proven facts
3 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Incorporated in US ⚠ unverified | 0/3 pts | 3 Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | US by default ⚠ unverified | 0/3 pts | 3 Report an error |
| Subprocessors | US CLOUD Act reach ⚠ unverified | 0/2 pts | 3 Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 22 Sep 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Legal entity. The contracting entity is the US-incorporated PostHog Inc. (formerly Hiberly Inc.); the UK (Hiberly Ltd) and German (PostHog GmbH) entities are subsidiaries of the US parent.
- Weak sourcing — Data residency. Even EU-hosted customers have account information processed in the United States ("Information about our customers is processed in the United States by us"), and the EU region is opt-in at signup rather than the default.
- Weak sourcing — Subprocessors. The privacy policy labels this list as covering customers' personal data rather than users' product data, but the terms (§3.4) acknowledge a third party — AWS — hosts the data collected under the agreement, and a dedicated Subprocessors page linked in the navigation was not among the excerpts.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 64 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 7 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 5 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 data fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 hosting fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 subprocessors fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 support fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
Sources (14)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage posthog.com Checked 22 Sep 2026 Details →
- 2 Pricing page posthog.com Checked 22 Sep 2026 Details →
- 3 Privacy policy posthog.com Checked 22 Sep 2026 Details →
- 4 Terms of service posthog.com Checked 22 Sep 2026 Details →
- 5 Experiment types & delivery — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 6 Experiment types & delivery — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 7 Statistical method & guardrails — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 8 Statistical method & guardrails — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 9 Consent & visitor tracking — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 10 Consent & visitor tracking — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 11 Snippet performance & flicker — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 12 Snippet performance & flicker — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 13 Analytics, data export & integrations — found from sitemap posthog.com Checked 1 Oct 2026 Details →
- 14 Analytics, data export & integrations — found from sitemap posthog.com Checked 1 Oct 2026 Details →