PostHog vs Plausible Analytics

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to PostHog
   PostHog✓fullprobed9/10

   PostHog serves a working llms.txt (probe confirms HTTP 200 with structured content describing the platform) and extensive agent-oriented docs like the MCP integration page (posthog-docs-12, 19, 24, 31) explicitly designed for AI agents/editors to consume. Individual docs pages also expose `.md` variants as seen in citations (e.g., product-analytics.md, session-replay.md), showing a broader agent-readable docs pattern. Missing for 10: a root docs.md aggregate returned 404, so machine-readable coverage isn't perfectly uniform across all docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://posthog.com/llms.txt # PostHog > PostHog is the platform for self-driving products. It pairs the full c…”
   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”
   • [probe] “PROBE docs-md: HTTP 404 at https://posthog.com/docs.md”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Probes explicitly show llms.txt, docs.md, and OpenAPI endpoints all return 404, indicating no agent-oriented documentation is exposed at expected locations, and no other evidence mentions llms.txt or agent-readable docs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to PostHog
   PostHog✓fullprobed7/10

   PostHog's CLI is explicitly documented for use in 'local scripts, and CI/CD pipelines' alongside terminal and coding agent use, plus REST/HTTP APIs and OpenAPI spec enable headless automation of data capture, queries, and flag management. missing for 10: independent/hands-on confirmation of CI/CD usage, and no explicit CI example/config shown (e.g., GitHub Actions snippet).

   • [claimed-docs] “The PostHog CLI lets you use PostHog from your terminal, your coding agents, local scripts, and CI/CD pipelines.”
   • [probe] “official CLI documented at https://posthog.com/docs/cli”
   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Inject and upload source maps for PostHog error tracking”

   proof ↗⚑ flag

   Plausible Analytics~partialprobed6/10

   Plausible offers a documented Events API for server-side/programmatic tracking and a Stats API (including a JSON query endpoint with scoped API keys) that can be scripted or called from CI/automation pipelines without a UI. However, there is no explicit CLI, official CI/CD integration guide, or documented automation examples, and probes show no llms.txt/OpenAPI spec for programmatic discovery. Missing for 10: dedicated CLI/CI documentation, OpenAPI/machine-readable spec, and concrete automation/CI examples.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “This is useful when tracking Android or iOS mobile apps, or for server side tracking.”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to PostHog
   PostHog✓fullprobed8/10

   PostHog documents an official MCP server (docs/model-context-protocol) enabling agents to run trends, funnels, HogQL queries, ship feature flags, and pull stack traces directly from MCP clients like Claude, corroborated by the GitHub README describing steering via MCP and a dedicated probe confirming the docs page exists. Missing for 10: independent third-party hands-on validation of the MCP server (only vendor docs/GitHub and one unrelated community complaint about a different AI assistant feature).

   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor”
   • [github] “You can steer it all from Slack, web, desktop (PostHog Desktop), or your own editor via the MCP.”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible is a SaaS analytics product, so an official MCP server is a plausible ecosystem offering, but no evidence pack item mentions MCP, an agent integration, or any AI-agent connector; probes confirm no llms.txt/openapi discoverability either.

   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to PostHog
   PostHog✓fullprobed8/10

   PostHog documents an official CLI usable from terminal, coding agents, local scripts, and CI/CD pipelines, with concrete features like source-map injection/upload for error tracking, and this is corroborated by a dedicated docs page and a probe confirming the CLI documentation is live. missing for 10: independent hands-on community review of the CLI itself (community evidence only covers MCP/LLM features, not the CLI specifically).

   • [claimed-docs] “The PostHog CLI lets you use PostHog from your terminal, your coding agents, local scripts, and CI/CD pipelines.”
   • [claimed-docs] “Inject and upload source maps for PostHog error tracking”
   • [probe] “official CLI documented at https://posthog.com/docs/cli”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   No evidence of an official CLI tool for Plausible; the product only offers REST APIs (Events/Stats) and dashboard/scripts, with no mention of a CLI in docs or GitHub, and probes for llms.txt/docs.md/openapi found nothing CLI-related either.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to PostHog
   PostHog✓fullprobed9/10

   PostHog has a documented public API (posthog.com/docs/api.md, HTTP capture from any language), a live OpenAPI spec confirmed by probe (openapi.json), an official CLI for terminal/CI/CD use, and a documented MCP server enabling AI agents to run queries, ship flags, and inspect stack traces via plain text — all first-party documented and probe-verified. Missing for 10: independent hands-on corroboration of the API/OpenAPI usage beyond vendor docs and probes.

   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”
   • [probe] “official CLI documented at https://posthog.com/docs/cli”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “The PostHog CLI lets you use PostHog from your terminal, your coding agents, local scripts, and CI/CD pipelines.”
   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”

   proof ↗⚑ flag

   Plausible Analytics✓fullprobed7/10

   Plausible documents both a Stats API (read-only query endpoint with API keys, JSON responses) and an Events API for recording pageviews/custom events server-side, giving programmatic access to core functionality. However missing for 10: no formal OpenAPI/Swagger spec (probes show 404s), no llms.txt/machine-readable docs for AI agents, and no evidence of official SDKs or independent hands-on API integration reports.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Plausible Analytics
   PostHog—none0/10

   No evidence describes scoped or least-privilege API key/credential issuance for agents — the API docs mention basic HTTP event capture and an OpenAPI spec exists, but nothing about permission scoping, token minting with restricted access, or credential management for AI agents specifically.

   ⚑ flag

   Plausible Analytics~partialclaimed5/10

   Plausible's Stats API keys are explicitly scoped to a single team (determining which sites can be queried) and the Stats API itself is read-only, giving some least-privilege boundary useful for an agent with read access; the Events API is separate for write-side tracking. However there's no evidence of finer-grained scopes (e.g., per-site, read/write toggles, expiring/revocable tokens, or agent-specific credential issuance) beyond team-level scoping. Missing for 10: granular per-site or per-scope permissions, credential expiry/rotation controls, and any agent-specific credential management docs.

   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to PostHog
   PostHog✓fullprobed7/10

   PostHog documents official SDKs/APIs (HTTP capture from any language, OpenAPI spec, CLI, MCP server) that let AI-native builders integrate programmatically, including AI-specific tooling like LLM observability SDKs and MCP-based agent workflows (posthog-docs-11, posthog-probe-3, posthog-docs-20/24, posthog-gh-6/9). A hands-on community comment corroborates smooth SDK integration for a Swift iOS app (posthog-comm-3), though another notes friction with LLM/AI query features (posthog-comm-8), suggesting some rough edges. Missing for 10: an explicit enumerated list of officially maintained language SDKs and stronger independent third-party validation of SDK completeness/versioning.

   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “The PostHog CLI lets you use PostHog from your terminal, your coding agents, local scripts, and CI/CD pipelines.”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”
   • [github] “Capture traces, generations, latency, and cost for your LLM-powered app.”
   • [github] “AI observability: Capture traces, generations, latency, and cost for your LLM-powered app.”
   • [community] “I've been using PostHog with my app for about a week now, and so far the results have been good. Pretty straightforward to integrate with a …”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible offers Events API and Stats API but there is no evidence of official client SDKs/libraries (e.g., for Python, JS, Node, etc.) for developers to build against beyond raw HTTP APIs; probes show no OpenAPI spec or llms.txt either. missing for 10: official SDK packages, language client libraries, OpenAPI/machine-readable spec, llms.txt.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to PostHog
   PostHog~partialclaimed4/10

   PostHog's CDP pipelines can send event data to Slack, PagerDuty, and other SaaS destinations, and can filter/reshape events and route them 'wherever it needs to go' in realtime, which implies webhook-style outbound delivery — but no evidence pack item explicitly names 'webhook' as a subscription mechanism or ties this to AI-agent consumption of the event stream. missing for 10: explicit webhook endpoint/subscription documentation, confirmation that arbitrary event streams can be pushed to a caller-defined webhook URL, and any AI-native usage example of subscribing via webhook.

   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “Slack: Send events to Slack channels SaaS tools: Send events to SaaS tools like Braze, Customer.io, and more”
   • [claimed-docs] “Send alerts to Slack, PagerDuty, or monitoring tools”
   • [github] “Create workflows that automate actions or send messages to your users.”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible offers an Events API (inbound, for recording events) and a Stats API (read-only query), but no evidence of outbound webhooks that let a subscriber be notified of events happening. No documentation mentions webhooks or push-based event subscriptions.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to PostHog
   PostHog!disputedcontradicted5/10

   PostHog markets in-product AI ('PostHog AI', 'self-driving products') that can suggest code fixes from stack traces, auto-write Hog functions, and turn product signals into researched reports/PRs (posthog-docs-12, posthog-docs-28, posthog-gh-1, posthog-probe-1). However a hands-on community report describes the in-app LLM feature failing a basic task (creating a SQL-based cohort) and severely degrading device performance, directly contradicting the polished 'insights on demand' claim (posthog-comm-8). missing for 10: independent corroboration that AI-generated insights/suggestions work reliably at scale, no rebuttal or fix documented for the reported failure.

   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”
   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”
   • [github] “Turn signals in your product data (errors, rage clicks, failed queries, and more) into researched reports and pull requests you review and m…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://posthog.com/llms.txt # PostHog > PostHog is the platform for self-driving products. It pairs the full c…”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   No evidence of AI-generated insights, natural-language querying, or automated suggestions within the Plausible dashboard. It offers AI-traffic tracking (which AI tools send traffic) but not AI-generated analysis of the data itself; funnels, comparisons, and filters are manual analysis tools, not AI-driven insights.

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to PostHog
   PostHog~partialcommunity6/10

   PostHog's CDP pipelines and workflows can run automatically in realtime or on a schedule (posthog-docs-18, posthog-gh-7), with Hog functions optionally written by PostHog AI (posthog-docs-28), and alerts/feature-flag automation exist (posthog-docs-3, posthog-docs-5). However, evidence centers on data-pipeline/workflow automation rather than an AI-native agent explicitly setting up and running autonomous background jobs end-to-end, and one community report notes friction with AI-driven query/cohort creation (posthog-comm-8). Missing for 10: first-party documentation of an AI agent configuring and monitoring a fully autonomous background automation, independent success reports of such automations running unattended.

   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [github] “Create workflows that automate actions or send messages to your users.”
   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”
   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   No evidence of any automation, scheduling, workflow, or agentic background-task capability beyond scheduled email/Slack reports, which is not autonomous automation setup; there's no workflow builder, webhook triggers, or agent framework. Missing for 10: any automation/workflow builder, trigger-based actions, agent/autonomous task execution, or scripting interface for background automations.

   • [claimed-docs] “Email reports: scheduled reports delivered to your inbox”
   • [claimed-docs] “Slack reports: send reports to a Slack channel”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to PostHog
   PostHog!disputedcontradicted4/10

   PostHog documents an in-product AI assistant/agent ("PostHog AI") that can write Hog functions, turn product signals into researched reports and PRs, and be steered from Slack/web/desktop/editor (posthog-docs-28, posthog-gh-1, posthog-gh-2), which matches the story of delegating tasks to a built-in assistant. However, a hands-on community report describes the LLM integration failing to perform a requested task (creating a cohort via SQL) and causing severe performance degradation, directly contradicting smooth delegation (posthog-comm-8). Missing for 10: first-party detail on the assistant's task scope/reliability, more independent corroboration of successful delegation, and resolution of the reported failure.

   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”
   • [github] “Turn signals in your product data (errors, rage clicks, failed queries, and more) into researched reports and pull requests you review and m…”
   • [github] “You can steer it all from Slack, web, desktop (PostHog Desktop), or your own editor via the MCP.”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   No evidence of any built-in AI assistant feature in Plausible; it only tracks AI referral traffic (docs-20/58), which is unrelated to delegating tasks to an assistant within the product. Missing for 10: any built-in AI assistant, agentic chat interface, or task-delegation feature.

   ⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to PostHog
   PostHog!disputedcontradicted5/10

   PostHog documents natural-language operation via its MCP integration—shipping feature flags, running HogQL queries, and debugging stack traces 'from a prompt' or 'plain text questions' (posthog-docs-12, posthog-docs-19, posthog-docs-24, posthog-docs-31, posthog-probe-4). However, a hands-on community report directly contradicts this: a user tried the LLM integration to create a cohort via SQL and it failed with an incorrect response, plus caused severe performance degradation (posthog-comm-8). missing for 10: independent corroboration that the failure was fixed, broader hands-on validation of natural-language commands across other product areas (analytics, experiments, session replay) beyond MCP docs.

   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   No evidence of any natural-language command interface, chatbot, AI assistant, or agentic control layer for Plausible; only a Stats/Events API requiring structured requests, and probes for llms.txt/docs.md/openapi all 404. missing for 10: any NL command interface, AI assistant/chat feature, or agent-facing API discovery mechanism.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to PostHog
   PostHog~partialprobed3/10

   The evidence shows PostHog publishes a machine-readable OpenAPI spec (openapi.json) and API docs referencing HTTP-based event capture, which implies some API reference exists, but there is no direct evidence of an interactive reference page with runnable/try-it examples. missing for 10: confirmation of an interactive API console, runnable code snippets, or live 'try it' functionality in the docs.

   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “capture events from any language that can send HTTP requests”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   There is documentation for the Stats API and Events API, but no evidence of an interactive API reference with runnable examples (e.g., Swagger/OpenAPI explorer or embedded try-it console). Probes explicitly confirm no OpenAPI spec, llms.txt, or docs.md is available, indicating no interactive/agent-friendly API reference exists. Missing for 10: interactive API explorer, runnable code examples, OpenAPI/machine-readable spec.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to PostHog
   PostHog✓fullprobed9/10

   A probe confirms PostHog serves a machine-readable OpenAPI spec at https://posthog.com/openapi.json (HTTP 200, contains 'openapi' key), and the API docs reference programmatic access via HTTP. Missing for 10: no explicit first-party docs page describing the OpenAPI spec's usage/versioning or independent community confirmation of its completeness.

   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “capture events from any language that can send HTTP requests”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible documents its Stats API and Events API in prose, but explicit probes for an OpenAPI/Swagger spec (openapi.json, swagger.json, well-known paths) and llms.txt/docs.md all returned 404, with no other evidence of a machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   PostHog—none0/10

   The evidence pack covers self-hosting (Docker Compose/MIT license), MCP integration, feature flags, and experiments, but nothing describes a dedicated sandbox/staging environment or test-mode data isolation from production. Self-hosting is a deployment option, not a sandbox testing feature, so it does not satisfy this story.

   ⚑ flag

   Plausible Analytics—none0/10

   No evidence of any sandbox/test environment, staging API, or mock mode for Plausible; only production Events/Stats API docs and self-hosting options are documented, none of which describe an isolated sandbox for AI-native testing.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   PostHog—none0/10

   There is an OpenAPI spec probe (posthog-probe-3) confirming an API exists, but no evidence anywhere in the pack of API versioning scheme or a documented deprecation policy for that API.

   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   There's documentation for the Events API and Stats API (including a v2 query endpoint), but no evidence of API versioning scheme or a documented deprecation policy; probes for OpenAPI spec/docs.md all returned 404s. missing for 10: explicit API version numbers/labels, changelog of breaking changes, documented deprecation timeline or sunset policy.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to PostHog
   PostHog~partialcommunity4/10

   PostHog offers SQL for querying/modifying data at scale, a CDP pipeline that can reshape/filter events in bulk, and a CLI/API for scripting operations, which could underpin bulk actions, but there is no explicit documentation of a 'bulk update/delete/tag N items' feature, and a hands-on report shows the AI/SQL interface failing on a basic bulk task (creating a cohort via SQL). missing for 10: explicit bulk-operation API/UI (e.g., mass edit flags, batch delete events), documented bulk-scale limits, and independent confirmation that SQL/CLI bulk actions work reliably for AI-driven workflows.

   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “The PostHog CLI lets you use PostHog from your terminal, your coding agents, local scripts, and CI/CD pipelines.”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   The evidence shows only single-item APIs (Events API for recording one event/pageview, Stats API for querying stats) and CSV import/export/consolidated dashboards, none of which describe bulk create/update/delete operations across many items (e.g., batch site/goal/user management). No documentation or community evidence indicates a bulk-operations capability suited to AI-native automation.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “Import stats: bring in data via CSV”
   • [claimed-docs] “Export stats: download your data”
   • [claimed-docs] “Consolidated view: all your sites in one dashboard”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to PostHog
   PostHog✓fullclaimed7/10

   PostHog's CDP/Pipelines ('destinations') and alerting system let users define trigger conditions on events (errors, rage clicks, property changes, etc.) that automatically fire actions like Slack alerts, CRM syncs, PagerDuty notifications, or custom Hog functions, and workflows can automate actions/messages to users. missing for 10: no independent/hands-on verification of complex multi-condition automation rules, and no detail on latency/reliability of the automation engine at scale.

   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”
   • [claimed-docs] “Slack: Send events to Slack channels SaaS tools: Send events to SaaS tools like Braze, Customer.io, and more”
   • [claimed-docs] “Send alerts to Slack, PagerDuty, or monitoring tools”
   • [github] “Create workflows that automate actions or send messages to your users.”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible offers notifications (traffic spikes, email/Slack reports) and read/write APIs, but there is no evidence of a rules engine or automation feature that lets users define conditional triggers to take actions on events (e.g., webhooks, if-this-then-that logic). Missing for 10: rule definition UI/API, conditional trigger logic, automated action execution beyond static notifications.

   • [claimed-docs] “Traffic spike notifications: get alerted when traffic spikes”
   • [claimed-docs] “Email reports: scheduled reports delivered to your inbox”
   • [claimed-docs] “Slack reports: send reports to a Slack channel”
   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to PostHog
   PostHog~partialclaimed5/10

   PostHog's CDP/pipelines can run 'in realtime or on a schedule' (posthog-docs-18) and GitHub notes 'workflows that automate actions or send messages to your users' (posthog-gh-7), suggesting some recurring automation capability, but there's no documentation of a general-purpose recurring job/workflow scheduler accessible via API, CLI, or MCP for AI-native orchestration. Missing for 10: explicit docs on scheduling arbitrary jobs/workflows via API or agent tooling, cron-like configuration details, and independent confirmation that scheduled pipelines work reliably.

   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [github] “Create workflows that automate actions or send messages to your users.”
   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   No evidence of any scheduling, workflow automation, or recurring job capability for AI-native users; Plausible only offers scheduled email/Slack reports for humans, not programmable recurring jobs/workflows. Missing for 10: any scheduler API, cron-like job configuration, or workflow automation tooling for AI agents.

   ⚑ flag

Ai analytics ops

1. ai-native userHave an agent build a dashboard of my key metrics end-to-end via the API or MCP server

   weight 3 · round to PostHog
   PostHog~partialprobed6/10

   PostHog has a documented official MCP server and public API (openapi.json) that let an agent run trends, funnels, retention, and SQL queries, ship feature flags, and inspect stack traces from an editor/agent (posthog-docs-2, 12, 19, 24, 31, posthog-probe-4, posthog-probe-3). Dashboard assembly, sharing, and alerting are documented product capabilities (posthog-docs-3, 25), but the evidence never explicitly shows the MCP/API path being used to assemble and publish a full dashboard end-to-end, and a hands-on community report describes the AI/LLM integration failing on a related task (cohort creation) and causing severe UI slowdown (posthog-comm-8), raising doubts about reliability of agent-driven workflows. Missing for 10: explicit documentation/demo of an agent creating and saving a dashboard object (not just insights/queries) via MCP or API, and independent corroboration that this specific end-to-end flow works reliably.

   • [claimed-docs] “Run trends, funnels, retention, and SQL queries from any MCP client or AI editor.”
   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”
   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics~partialprobed4/10

   Plausible exposes a Stats API (/api/v2/query) that returns JSON metrics and could be used by an agent to assemble a custom dashboard, but there is no evidence of an MCP server, agent-oriented SDK, or documented workflow for programmatic dashboard creation end-to-end. Probes confirm no llms.txt, docs.md, or OpenAPI spec, suggesting the API isn't packaged for agent discovery/consumption. missing for 10: official MCP server, agent-facing API discovery (OpenAPI/llms.txt), end-to-end example of an agent building a dashboard via API.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

Dashboards

1. developerCreate and manage dashboards and saved insights programmatically via the API

   weight 2 · round to PostHog
   PostHog~partialprobed4/10

   The evidence confirms PostHog exposes a general REST API (openapi.json spec) and documents building/sharing dashboards and insights with alerts, implying programmatic access is plausible, but no citation explicitly documents dashboard/insight CRUD API endpoints or SDK examples for managing them programmatically. missing for 10: explicit API docs/endpoints for creating/updating dashboards and insights, code examples for programmatic dashboard management, independent confirmation of this specific API surface.

   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible's Stats API only provides read-only query access to stats and the Events API only records events; there is no evidence of an API for creating/managing dashboards or saved insights programmatically. Missing for 10: any API endpoint for creating/editing dashboards, saving insights, or managing report configurations.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”

   proof ↗⚑ flag

2. product-managerCompose saved insights into shareable dashboards for my team

   weight 2 · round to PostHog
   PostHog✓fullclaimed8/10

   Docs explicitly state users can build insights, save them to dashboards, share them, and set alerts (posthog-docs-3, posthog-docs-25), directly matching the story of composing saved insights into shareable dashboards. Missing for 10: no independent/hands-on corroboration of the dashboard-sharing workflow specifically, and no detail on team-level permissions or collaboration features around shared dashboards.

   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog”

   proof ↗⚑ flag

   Plausible Analytics~partialclaimed4/10

   Plausible offers dashboard sharing (shared links, embed dashboard, consolidated multi-site view) and team collaboration via SSO/roles, letting a PM share the existing analytics dashboard with a team. However there is no evidence of a 'saved insights' concept or a dashboard builder that lets a PM compose multiple saved reports/segments into a custom shareable dashboard — Plausible's dashboard is a fixed, single-page view per site (or consolidated across sites), not an assembled collection of saved insights. Missing for 10: saved/insight-level bookmarking, drag-and-drop or composable dashboard layout, ability to mix multiple custom reports into one shareable view.

   • [claimed-docs] “Consolidated view](/docs/consolidated-views): all your sites in one dashboard”
   • [claimed-docs] “Embed dashboard: embed your stats on any page”
   • [claimed-docs] “Shared links: share your dashboard publicly or with specific people”
   • [claimed-docs] “Single Sign-On (SSO): for teams on Google Workspaces, Microsoft Entra, or Okta”
   • [github] “Invite team members with role-based access, share dashboards publicly or with anyone using a simple link.”
   • [claimed-docs] “Consolidated view: all your sites in one dashboard”

   proof ↗⚑ flag

3. product-managerSubscribe to dashboards and get alerted when a key metric moves abnormally

   weight 1 · round to PostHog
   PostHog✓fullclaimed7/10

   PostHog docs explicitly state dashboards/insights can be saved, shared, and users can 'get alerted when they move' (posthog-docs-3, posthog-docs-25), and alerts can be routed to Slack/PagerDuty (posthog-intdir-2), directly matching the PM story of dashboard subscriptions with abnormal-metric alerts. Missing for 10: no independent/hands-on confirmation of the alerting UX, no detail on anomaly-detection thresholds, and no explicit mention of subscribing to an entire dashboard vs individual insights.

   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”
   • [claimed-docs] “Send alerts to Slack, PagerDuty, or monitoring tools”

   proof ↗⚑ flag

   Plausible Analytics~partialclaimed6/10

   Plausible offers scheduled email/Slack reports (subscribe to dashboard) and explicit 'traffic spike notifications' that alert when traffic moves abnormally, directly matching the core of this story. However, evidence only covers traffic volume anomalies, not configurable alerts on other key metrics like conversion rate, revenue, or goal completions, and there's no mention of custom thresholds or anomaly sensitivity settings. Missing for 10: alerting on arbitrary/custom key metrics beyond traffic, threshold configuration, and real-time push alerts (vs. periodic email/Slack digests).

   • [claimed-docs] “Traffic spike notifications: get alerted when traffic spikes”
   • [claimed-docs] “Email reports: scheduled reports delivered to your inbox”
   • [claimed-docs] “Slack reports: send reports to a Slack channel”
   • [github] “Get weekly or monthly reports via email or Slack, including traffic spike/drop notifications.”

   proof ↗⚑ flag

Identity

1. developerBulk-import historical events from another analytics tool or a data export into the platform

   weight 1 · round to Plausible Analytics
   PostHog~partialcommunity3/10

   There's no first-party documentation of a dedicated bulk-import tool for historical events from another analytics tool, but the data warehouse/CDP features allow syncing external data sources into PostHog for unified querying, and a community comment notes Mixpanel-library compatibility making switching 'really easy.' missing for 10: explicit import API/tool for historical event data, documented data-export ingestion pipeline, and first-party confirmation of the Mixpanel-compatibility claim.

   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [community] “Great idea to be compatible with Mixpanel libraries! Makes switching over really easy”

   proof ↗⚑ flag

   Plausible Analytics✓fullcommunity7/10

   Plausible has documented Google Analytics import (bring in historical data) and CSV import/export features, directly supporting bulk-import of historical events from another tool or data export. Community evidence corroborates users migrating from GA with import as a known feature, though one older comment requested the feature before it existed, suggesting it was a later addition. Missing for 10: independent hands-on verification of import fidelity/limits, and detail on supported source formats beyond GA/CSV.

   • [claimed-docs] “Import from Google Analytics](/docs/google-analytics-import): bring in your historical data”
   • [claimed-docs] “Import from Google Analytics: bring in your historical data”
   • [claimed-docs] “You can even import your Google Analytics stats.”
   • [github] “Familiar metrics, campaign tracking and Search Console integration. Import your historical Google Analytics stats and continue where you lef…”
   • [github] “Smooth transition from Google Analytics Familiar metrics, campaign tracking and Search Console integration. Import your historical Google An…”
   • [claimed-docs] “Import stats: bring in data via CSV”
   • [community] “That's why we actually migrated from Google Analytics to Plausible... By the way: Import of analytics data from Google would be a great feat…”

   proof ↗⚑ flag

2. developerIdentify users across devices and merge anonymous pre-signup activity into their identified profile

   weight 2 · round drawn
   PostHog—none0/10

   The evidence pack covers event capture, analytics, session replay, feature flags, experiments, and CDP integrations, but nowhere mentions identify()/alias() calls, distinct_id merging, or cross-device/anonymous-to-identified user reconciliation. This is a standard axis for an event-ingestion/analytics product, but no evidence supports it here. Missing for 10: any mention of identify/alias APIs, anonymous-to-known user merging, or cross-device identity resolution documentation.

   ⚑ flag

   Plausible Analytics—none0/10

   Plausible's core design explicitly avoids collecting personal data or building user profiles — it uses privacy-preserving daily-salted hashes for unique visitor counts rather than persistent identifiers, and docs/community evidence confirm it does not store IPs or build cross-session/cross-device profiles. There is no mechanism described for identifying users across devices or merging anonymous activity into an identified profile.

   • [claimed-docs] “Plausible collects no personal data and requires no consent banner. Every visit in your dashboard is a real visit.”
   • [claimed-docs] “Plausible collects no personal data and requires no consent banner.”
   • [community] “They don't store IP addresses. Information they gather are not stored in a way to build user profiles or do fingerprinting.”
   • [community] “I'm fairly certain that people behind VPNs will not be properly counted (everyone with the same user-agent will be counted as if they were t…”

   proof ↗⚑ flag

Instrumentation

1. product-managerCapture clicks, pageviews, and form interactions automatically without writing tracking code for each event

   weight 2 · round to Plausible Analytics
   PostHog—none0/10

   The evidence pack discusses capturing custom events via SDKs/HTTP requests and building insights, but nowhere states that PostHog automatically captures clicks, pageviews, or form interactions without instrumenting code (no mention of autocapture). Missing for 10: any documented autocapture feature, evidence of automatic click/pageview/form tracking, or an example of a PM enabling capture with zero code.

   • [claimed-docs] “Custom events you capture from any SDK, each with the properties you attach to them.”
   • [claimed-docs] “capture events from any language that can send HTTP requests”

   proof ↗⚑ flag

   Plausible Analytics~partialcommunity6/10

   Plausible auto-tracks pageviews and scroll depth with no code, and can automatically turn pages into goals for file downloads, form completions and outbound link clicks without custom event code (plausible-docs-40, plausible-docs-54, plausible-docs-21, plausible-docs-37). However, dedicated 'click tracking' beyond outbound links, and richer form-interaction capture, generally require custom events/Events API or tag manager setup rather than being fully automatic, and one community comment notes founders avoid deeper user-flow tracking for privacy reasons (plausible-comm-5). Missing for 10: comprehensive automatic click tracking (not just outbound links), evidence of fully automatic form field-level interaction capture, and independent hands-on confirmation of zero-code setup across all these event types.

   • [claimed-docs] “Turn any page into a goal. Automatically track file downloads, form completions and external link clicks. Set up custom events and revenue t…”
   • [claimed-docs] “Turn any page into a goal. Automatically track file downloads, form completions and external link clicks.”
   • [claimed-docs] “Scroll depth from 1 to 100 percent is tracked automatically on every page. No setup, no tag managers.”
   • [claimed-docs] “Scroll depth from 1 to 100 percent is tracked automatically on every page. No setup, no tag managers. Create scroll depth goals without code…”
   • [community] “The founders refuse to adopt tracking of user flows through a web site, allegedly for privacy reasons.”

   proof ↗⚑ flag

2. developerSend events from web, mobile, and backend apps through official SDKs for the major languages and platforms

   weight 3 · round to PostHog
   PostHog✓fullcommunity7/10

   Docs confirm event capture from "any SDK" and from any HTTP-capable language, and community evidence corroborates real-world use of the iOS SDK integrating smoothly, supporting broad SDK coverage across platforms. Missing for 10: an explicit enumerated list of official SDKs per language/platform (web, Android, Node, Python, etc.) and independent confirmation for backend/server SDKs beyond the HTTP API and iOS mention.

   • [claimed-docs] “Custom events you capture from any SDK, each with the properties you attach to them.”
   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [community] “I've been using PostHog with my app for about a week now, and so far the results have been good. Pretty straightforward to integrate with a …”
   • [community] “Great idea to be compatible with Mixpanel libraries! Makes switching over really easy”

   proof ↗⚑ flag

   Plausible Analytics~partialclaimed4/10

   Plausible offers a generic Events API for recording pageviews/custom events usable from mobile or server-side apps, plus a script tag for web, but there's no evidence of official SDKs/libraries for specific languages (e.g., Swift, Kotlin, Node, Python) beyond raw HTTP API and script snippet. missing for 10: official mobile SDKs (iOS/Android), official backend language SDKs, community/hands-on confirmation of SDK usage.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “This is useful when tracking Android or iOS mobile apps, or for server side tracking.”
   • [claimed-docs] “Add the script to your site”

   proof ↗⚑ flag

Experimentation

1. product-managerRun A/B experiments with goal metrics and statistical significance reported on the results

   weight 3 · round to PostHog
   PostHog✓fullclaimed8/10

   PostHog's Experiments docs explicitly describe defining variants, picking goal metrics, randomizing users, tracking exposures, and running statistics (Bayesian or frequentist) to determine significance, which directly matches the story. Missing for 10: independent/hands-on validation of the statistical reporting accuracy and no community corroboration specific to experiments (only analytics/session-replay community feedback exists).

   • [claimed-docs] “PostHog randomizes your users, tracks their exposures, and runs the statistics – Bayesian or frequentist – so you get a real answer instead …”
   • [claimed-docs] “You define variants, pick the metrics you care about, and PostHog randomizes your users, tracks their exposures, and runs the statistics – B…”
   • [claimed-docs] “You define variants, pick the metrics you care about, and PostHog randomizes your users, tracks their exposures, and runs the statistics – B…”
   • [claimed-docs] “PostHog randomizes your users, tracks their exposures, and runs the statistics – Bayesian or frequentist – so you get a real answer instead …”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible is a privacy-focused web analytics tool offering goals, funnels, and traffic stats, but there is no evidence of any A/B testing/experimentation feature, variant assignment, or statistical significance reporting on results.

   ⚑ flag

Behavioral analysis

1. product-managerBuild multi-step funnels with filters and breakdowns to find where users drop off

   weight 3 · round to Plausible Analytics
   PostHog✓fullclaimed7/10

   PostHog docs explicitly state funnels are a first-class insight type built on captured events ('Build trends, funnels, retention, paths, stickiness...') alongside dashboards, alerts, and saved insights, which covers the core funnel-building use case for a PM. However, the evidence pack doesn't explicitly detail funnel-specific filter/breakdown UI mechanics beyond the general mention. Missing for 10: explicit documentation or screenshots of step-level filters and breakdown-by-property configuration within funnels, and independent user validation of funnel usability.

   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”
   • [claimed-docs] “Custom events you capture from any SDK, each with the properties you attach to them.”
   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”

   proof ↗⚑ flag

   Plausible Analytics✓fullcommunity8/10

   Plausible's docs explicitly describe a funnel-analysis feature that lets users define a sequence of steps, choose sequential or strict-order funnels, and see drop-off at each step, complemented by filters/segments (docs-32, docs-44) and a 'user journeys' report showing paths visitors take (docs-55, docs-41, docs-42, docs-56). This directly matches the story's ask for multi-step funnels with filters and breakdowns to find drop-off points. Missing for 10: independent/hands-on validation of funnel usability in practice, and an old community comment (plausible-comm-5) noting the founders once resisted user-flow tracking, which slightly tempers confidence though it predates the now-documented feature.

   • [claimed-docs] “Define a sequence of steps and measure how many visitors complete each one. Use funnel analysis to find where people drop off and improve yo…”
   • [claimed-docs] “Measure drop-off across a fixed sequence of steps. Or explore the paths visitors actually take to discover flows you didn't predict.”
   • [claimed-docs] “Choose between two funnel types: sequential (visitors can take other actions between steps) or strict order (steps must happen in exact cons…”
   • [claimed-docs] “User journeys: explore the paths visitors take on your site”
   • [claimed-docs] “Define a sequence of steps and measure how many visitors complete each one. Use funnel analysis to find where people drop off”
   • [claimed-docs] “Filters and segments: drill into any slice of your traffic”
   • [claimed-docs] “You can go granular and click on any of the entries in any of the reports to filter your Plausible dashboard by it.”
   • [community] “The founders refuse to adopt tracking of user flows through a web site, allegedly for privacy reasons.”
   • [community] “Plausible is very nice, but it lacks much of the information from Matomo (like 'after viewing /foo, visitors tend to view…'). Matomo... lack…”

   proof ↗⚑ flag

2. product-managerAnalyze behavior at the account or company level, not just per user, for B2B products

   weight 2 · round to PostHog
   PostHog~partialclaimed4/10

   PostHog documents a group concept for targeting (person property, cohort, or group) used in feature flag rollouts, implying group-level segmentation exists, but the evidence pack never explicitly ties 'groups' to trends/funnels/retention insights or shows account-level rollups in analytics dashboards. missing for 10: explicit docs on group-level funnels/retention insights, account/company entity definition and configuration, examples of B2B account analytics dashboards.

   • [claimed-docs] “Roll out by person property, cohort, or group, then see the session replays, events, and exceptions from the people who got the flag”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible is designed around anonymous, privacy-first visitor-level metrics (no personal data, no user profiles/fingerprinting) and there is no evidence of any account-based or company-level grouping, CRM/CDP integration, or B2B account analytics feature in the docs, GitHub description, or community discussion.

   • [claimed-docs] “Plausible collects no personal data and requires no consent banner. Every visit in your dashboard is a real visit.”
   • [claimed-docs] “Plausible collects no personal data and requires no consent banner.”
   • [community] “They don't store IP addresses. Information they gather are not stored in a way to build user profiles or do fingerprinting.”
   • [community] “I'm fairly certain that people behind VPNs will not be properly counted (everyone with the same user-agent will be counted as if they were t…”

   proof ↗⚑ flag

3. product-managerMeasure retention over time and slice it by behavioral cohorts

   weight 3 · round to PostHog
   PostHog✓fullclaimed7/10

   PostHog explicitly ships retention as a core insight type (posthog-docs-15, posthog-docs-25) alongside cohort support elsewhere in the product (posthog-docs-6 references rolling out and analyzing by cohort, posthog-docs-8/17 SQL for custom cohort queries). This directly matches the PM story of measuring retention and slicing by behavioral cohorts, though the evidence doesn't show a dedicated doc excerpt showing retention insight breakdown-by-cohort UI directly. missing for 10: an explicit doc/screenshot showing retention insight with cohort breakdown control, and independent hands-on confirmation of this specific workflow.

   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”
   • [claimed-docs] “Roll out by person property, cohort, or group, then see the session replays, events, and exceptions from the people who got the flag”
   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [claimed-docs] “SQL insights enable you to directly query your data with SQL commands like SELECT, FROM, JOIN, WHERE, GROUP BY”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible's docs describe funnels, goals, and dashboard filters/segments, but there is no evidence of retention curves, cohort definitions, or cohort-based behavioral analysis over time. In fact, Plausible's privacy-first design (no persistent personal identifiers, daily-rotating hashed uniques, no user-flow tracking per plausible-comm-5) architecturally works against cross-session cohort/retention analysis.

   • [claimed-docs] “Define a sequence of steps and measure how many visitors complete each one. Use funnel analysis to find where people drop off and improve yo…”
   • [claimed-docs] “Measure drop-off across a fixed sequence of steps. Or explore the paths visitors actually take to discover flows you didn't predict.”
   • [community] “The founders refuse to adopt tracking of user flows through a web site, allegedly for privacy reasons.”
   • [community] “Plausible is very nice, but it lacks much of the information from Matomo (like 'after viewing /foo, visitors tend to view…'). Matomo... lack…”
   • [community] “I'm fairly certain that people behind VPNs will not be properly counted (everyone with the same user-agent will be counted as if they were t…”

   proof ↗⚑ flag

4. product-managerExplore the paths users actually take before or after a key event

   weight 2 · round to PostHog
   PostHog✓fullclaimed7/10

   PostHog explicitly documents 'paths' insights alongside trends, funnels, retention, stickiness, and lifecycle built on captured events (posthog-docs-15, posthog-docs-25), directly matching the path-analysis story. Missing for 10: no dedicated docs excerpt detailing path-specific configuration (e.g., start/end event anchoring, wildcard grouping) or independent/hands-on validation of the paths feature specifically.

   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”
   • [claimed-docs] “Custom events you capture from any SDK, each with the properties you attach to them.”

   proof ↗⚑ flag

   Plausible Analytics!disputedcontradicted5/10

   Plausible's marketing docs explicitly advertise a 'User journeys' feature to 'explore the paths visitors actually take to discover flows you didn't predict' (docs-41, docs-55), which matches the story closely. However, community hands-on reports directly contradict this: one HN commenter states 'The founders refuse to adopt tracking of user flows through a web site, allegedly for privacy reasons' and another notes Plausible 'lacks much of the information from Matomo (like after viewing /foo, visitors tend to view…)' — suggesting the feature is either new/limited or not as capable as claimed. Missing for 10: independent corroboration that the User Journeys feature actually surfaces pre/post-event path exploration as described, and resolution of the conflicting community reports of it being absent or weak.

   • [claimed-docs] “Measure drop-off across a fixed sequence of steps. Or explore the paths visitors actually take to discover flows you didn't predict.”
   • [claimed-docs] “User journeys: explore the paths visitors take on your site”
   • [community] “The founders refuse to adopt tracking of user flows through a web site, allegedly for privacy reasons.”
   • [community] “Plausible is very nice, but it lacks much of the information from Matomo (like 'after viewing /foo, visitors tend to view…'). Matomo... lack…”

   proof ↗⚑ flag

Self serve insights

1. founderAnswer "which activation step loses users?" myself with funnels and drop-off analysis, without an analyst

   weight 3 · round to PostHog
   PostHog✓fullclaimed8/10

   PostHog's product analytics explicitly builds funnels, retention, trends, paths, stickiness, and lifecycle insights on captured events, with dashboards and alerts, all self-serve without requiring an analyst (posthog-docs-15, posthog-docs-25, posthog-docs-1). This directly supports self-service drop-off/activation analysis via funnels. missing for 10: no independent/hands-on evidence of a founder successfully using funnels to diagnose activation drop-off, and no case study demonstrating non-analyst usability in practice.

   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog”
   • [claimed-docs] “Build trends, funnels, retention, paths, stickiness, and lifecycle insights on the events you already send to PostHog, then save them to das…”
   • [claimed-docs] “Custom events you capture from any SDK, each with the properties you attach to them.”
   • [claimed-docs] “Build insights, assemble dashboards, share them, and set alerts on the numbers that matter.”

   proof ↗⚑ flag

   Plausible Analytics~partialcommunity7/10

   Plausible has a dedicated, documented Funnel Analysis feature (sequential or strict-order steps, drop-off measurement) plus a User Journeys view showing paths visitors take, and the dashboard is explicitly designed for no-training self-serve use — directly matching the 'find where activation drops off myself' story. However, independent community feedback flags real limits: one HN commenter notes Plausible 'lacks much of the information from Matomo (like after viewing /foo, visitors tend to view...)', suggesting the flow/transition analysis is shallower than competitors, and another older comment claims the founders resisted user-flow tracking on privacy grounds. missing for 10: independent hands-on validation that funnel drop-off analysis works well in practice for real activation funnels, and resolution of the comparative gap noted vs Matomo's flow reports.

   • [claimed-docs] “Define a sequence of steps and measure how many visitors complete each one. Use funnel analysis to find where people drop off and improve yo…”
   • [claimed-docs] “Measure drop-off across a fixed sequence of steps. Or explore the paths visitors actually take to discover flows you didn't predict.”
   • [claimed-docs] “Choose between two funnel types: sequential (visitors can take other actions between steps) or strict order (steps must happen in exact cons…”
   • [claimed-docs] “Define a sequence of steps and measure how many visitors complete each one. Use funnel analysis to find where people drop off”
   • [claimed-docs] “User journeys: explore the paths visitors take on your site”
   • [claimed-docs] “You get one dashboard with the essential website stats, easy to use and understand with no training or prior experience.”
   • [community] “Plausible is very nice, but it lacks much of the information from Matomo (like 'after viewing /foo, visitors tend to view…'). Matomo... lack…”
   • [community] “The founders refuse to adopt tracking of user flows through a web site, allegedly for privacy reasons.”

   proof ↗⚑ flag

Destinations

1. developerStream events onward to third-party destinations (CRM, ad platforms, webhooks) from the analytics platform

   weight 2 · round to PostHog
   PostHog✓fullclaimed8/10

   PostHog's CDP explicitly supports streaming events to third-party destinations including CRMs (Salesforce, HubSpot), ad platforms, webhooks, and SaaS tools (Braze, Customer.io, Slack, PagerDuty), with real-time or scheduled delivery via configurable Hog functions. missing for 10: independent/hands-on confirmation of destination reliability or throughput, and a full list of supported destinations beyond the named examples.

   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”
   • [claimed-docs] “Sync user properties to CRM systems like Salesforce or HubSpot”
   • [claimed-docs] “Slack: Send events to Slack channels SaaS tools: Send events to SaaS tools like Braze, Customer.io, and more”
   • [claimed-docs] “Send alerts to Slack, PagerDuty, or monitoring tools”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Evidence only covers Plausible's Events API (ingest custom events into Plausible) and Stats API (read-only query of Plausible's own stats), plus GTM/webhook-free tracking setup — there is no mention of streaming events onward to CRMs, ad platforms, or external webhooks. No outbound integration/export-to-third-party pipeline is documented anywhere in the pack.

   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “This is useful when tracking Android or iOS mobile apps, or for server side tracking.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [claimed-docs] “Google Tag Manager](/gtm-template): deploy without touching your code”
   • [claimed-docs] “Google Tag Manager: deploy without touching your code”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to PostHog
   PostHog✓fullprobed7/10

   PostHog exposes a full OpenAPI-documented REST API (posthog-probe-3, posthog-docs-11), an MCP server enabling agents to run queries, ship flags, and inspect errors (posthog-docs-2, -12, -19, -24, probe-4), a CLI for terminal/CI use (posthog-docs-20, probe-5), and SQL access throughout the product (posthog-docs-8, -17), collectively covering analytics, flags, experiments, error tracking, and data warehouse operations programmatically. missing for 10: an explicit vendor statement guaranteeing 1:1 API/UI parity, and independent verification that every UI workflow (e.g. survey building, dashboard sharing) is fully replicable via API without gaps.

   • [claimed-docs] “Run trends, funnels, retention, and SQL queries from any MCP client or AI editor.”
   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [claimed-docs] “"Show me the full stack trace for the most recent crash, then propose a fix." – Pulls the stack trace, error message, and metadata so the ag…”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “The PostHog CLI lets you use PostHog from your terminal, your coding agents, local scripts, and CI/CD pipelines.”
   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”
   • [probe] “official CLI documented at https://posthog.com/docs/cli”

   proof ↗⚑ flag

   Plausible Analytics~partialprobed4/10

   Plausible ships a read-only Stats API for querying metrics and an Events API for recording pageviews/custom events, letting AI-native users pull dashboard-like data and send events programmatically, but there is no evidence of API coverage for configuration tasks that are core UI features — creating/managing funnels, goals, annotations, shared links, team/SSO settings, email/Slack reports, or site management. No OpenAPI spec is discoverable (probe results all 404), reinforcing that API surface is narrower than the UI. missing for 10: API endpoints for funnel/goal/annotation creation, team & site management, shared-link/report configuration, and a discoverable OpenAPI/spec confirming full parity.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [claimed-docs] “This is useful when tracking Android or iOS mobile apps, or for server side tracking.”
   • [claimed-docs] “Define a sequence of steps and measure how many visitors complete each one. Use funnel analysis to find where people drop off and improve yo…”
   • [claimed-docs] “You can also add annotations to the chart to mark important events like a deployment, a campaign launch or an outage.”
   • [claimed-docs] “Single Sign-On (SSO): for teams on Google Workspaces, Microsoft Entra, or Okta”
   • [claimed-docs] “Shared links: share your dashboard publicly or with specific people”
   • [claimed-docs] “Email reports: scheduled reports delivered to your inbox”
   • [claimed-docs] “Slack reports: send reports to a Slack channel”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Plausible Analytics
   PostHog~partialprobed6/10

   PostHog is open-source (MIT-licensed self-host Docker Compose) and exposes data via SQL, an HTTP API, and data-warehouse sync, which together give strong data portability and self-hosting options implying users can retain full control of their data. However, there is no explicit documented 'export all your data' feature or open-format bulk export tool, and no independent evidence of someone successfully exporting/migrating a full production dataset. Missing for 10: explicit bulk-export/download-all-data documentation, confirmation of open standard export formats (e.g., CSV/Parquet dumps), and independent hands-on evidence of a full data migration/exit.

   • [claimed-docs] “PostHog is open-source and freely available for anyone to host themselves. We offer a free Docker Compose deployment under an MIT license.”
   • [claimed-docs] “We offer a free Docker Compose deployment under an MIT license.”
   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [claimed-docs] “SQL insights enable you to directly query your data with SQL commands like SELECT, FROM, JOIN, WHERE, GROUP BY”
   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   Plausible Analytics✓fullcommunity7/10

   Plausible offers explicit data export (CSV export/import), a read-only Stats API for programmatic access, and is fully open-source/self-hostable (Community Edition), meaning users can export data and run their own instance to 'leave' the SaaS entirely without lock-in. Community evidence corroborates the FOSS/self-host value as a real selling point against vendor lock-in. Missing for 10: no evidence of a bulk 'export everything' guarantee covering raw event-level data, no independent hands-on test of export completeness, and no explicit documentation of data portability guarantees beyond CSV/API.

   • [claimed-docs] “Import stats: bring in data via CSV”
   • [claimed-docs] “Export stats: download your data”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “A getting started guide to self-hosting Plausible Community Edition”
   • [community] “One huge selling point of using Plausible is that you can self-host it and it's FOSS. If the company disappears, you can continue using what…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to PostHog
   PostHog✓fullclaimed9/10

   PostHog explicitly documents its open-source nature and MIT-licensed self-host deployment (Docker Compose), with the actual source hosted publicly on GitHub, satisfying the ability to read the product's source under an open license. Missing for 10: no explicit confirmation of the license covering the entire codebase (vs just the self-host component) or independent audit of license terms.

   • [claimed-docs] “We offer a free Docker Compose deployment under an MIT license.”
   • [claimed-docs] “PostHog is open-source and freely available for anyone to host themselves. We offer a free Docker Compose deployment under an MIT license.”

   proof ↗⚑ flag

   Plausible Analytics✓fullcommunity8/10

   Plausible Community Edition is open-source on GitHub, and community evidence corroborates that the FOSS/self-hosted nature is a genuine, trusted selling point (people can maintain the code themselves if the company disappears). Missing for 10: explicit license name/text, and no direct evidence of AI-native machine-readable license documentation.

   • [claimed-docs] “A getting started guide to self-hosting Plausible Community Edition”
   • [community] “One huge selling point of using Plausible is that you can self-host it and it's FOSS. If the company disappears, you can continue using what…”
   • [community] “I'm a very happy self-hosted Plausible user for years now. Solid, simple, and easy to maintain.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Plausible Analytics
   PostHog!disputedcontradicted5/10

   PostHog's docs explicitly state the core product is open-source and offers a free MIT-licensed Docker Compose self-host deployment (posthog-docs-14/21), which is a clear ai-native/openness claim. However, a hands-on community report describes the production Dockerfile/posthog:latest image as 'busted' and failing to create a database, requiring significant debugging effort — a concrete contradiction of the self-host claim working out of the box. Missing for 10: independent confirmation the current self-host path works reliably, resolution or acknowledgment of the reported Docker issue, and details on feature parity between self-hosted and cloud versions.

   • [claimed-docs] “We offer a free Docker Compose deployment under an MIT license.”
   • [claimed-docs] “PostHog is open-source and freely available for anyone to host themselves. We offer a free Docker Compose deployment under an MIT license.”
   • [community] “You should mention on the README that the production dockerfile (and posthog/posthog:latest) are busted, they do not create any database. Sp…”

   proof ↗⚑ flag

   Plausible Analytics✓fullcommunity8/10

   Plausible ships an official open-source Community Edition with self-hosting docs (GitHub repo), and community members confirm running it successfully in production for years, valuing that it's FOSS and can be maintained independently. Missing for 10: independent benchmarking of self-hosted performance/scale, and one community comment notes self-hosting complexity (ClickHouse dependency) as a real friction point.

   • [claimed-docs] “A getting started guide to self-hosting Plausible Community Edition”
   • [community] “I'm a very happy self-hosted Plausible user for years now. Solid, simple, and easy to maintain.”
   • [community] “One huge selling point of using Plausible is that you can self-host it and it's FOSS. If the company disappears, you can continue using what…”
   • [community] “I think Plausible's self-hosting is not simple, requiring unnecessarily heavy databases like ClickHouse, which can be overkill for the avera…”

   proof ↗⚑ flag

Privacy first analytics

1. founderTrack product usage without third-party cookies so I can minimize or avoid cookie consent banners

   weight 2 · round to Plausible Analytics
   PostHog—none0/10

   The evidence pack contains no mention of cookie-based vs cookieless tracking, consent banners, or privacy-compliant capture configuration—only general analytics, session replay, and SDK/API capture details. Without any documentation addressing cookieless tracking or consent-banner avoidance, this axis has no supporting evidence.

   ⚑ flag

   Plausible Analytics✓fullcommunity9/10

   Plausible's docs explicitly state it collects no personal data, uses no cookies, and requires no consent banner, which is corroborated by community reports of GDPR-compliant, cookie-free operation and no IP storage. missing for 10: independent legal/regulatory audit confirming zero consent-banner requirement across all jurisdictions.

   • [claimed-docs] “Plausible collects no personal data and requires no consent banner. Every visit in your dashboard is a real visit.”
   • [claimed-docs] “Plausible collects no personal data and requires no consent banner.”
   • [claimed-docs] “By using Plausible, you do not need cookie banners for analytics or to collect consent for tracking.”
   • [community] “Plausible Analytics is GDPR compliant - with one possible exception - the IP address which if they dropped the last 3 digits would probably …”
   • [community] “They don't store IP addresses. Information they gather are not stored in a way to build user profiles or do fingerprinting.”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Plausible Analytics
   PostHog—none0/10

   The evidence pack has self-hosting/open-source docs (posthog-docs-14, posthog-docs-21) which relate to deployment flexibility but no mention of data residency/region selection (e.g., EU vs US cloud region choice) for PostHog Cloud. Missing for 10: explicit region/residency selection options, data storage location controls, compliance documentation on where data resides.

   • [claimed-docs] “We offer a free Docker Compose deployment under an MIT license.”
   • [claimed-docs] “PostHog is open-source and freely available for anyone to host themselves. We offer a free Docker Compose deployment under an MIT license.”

   proof ↗⚑ flag

   Plausible Analytics~partialcommunity5/10

   Plausible enables data residency control primarily through self-hosting (Community Edition), letting users run and store data on their own infrastructure/region, corroborated by community reports of long-term self-hosted use. However there is no evidence of an official region-selection option within the hosted Cloud product (e.g., EU vs US data center choice) — missing for 10: explicit cloud region/residency selection docs, compliance certifications tied to specific regions, and independent verification of hosted-data location choices.

   • [claimed-docs] “A getting started guide to self-hosting Plausible Community Edition”
   • [community] “I'm a very happy self-hosted Plausible user for years now. Solid, simple, and easy to maintain.”
   • [community] “One huge selling point of using Plausible is that you can self-host it and it's FOSS. If the company disappears, you can continue using what…”
   • [community] “I think Plausible's self-hosting is not simple, requiring unnecessarily heavy databases like ClickHouse, which can be overkill for the avera…”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   PostHog—none0/10

   No evidence in the pack addresses AI-training data opt-out or any privacy control preventing customer data from being used to train AI models; nothing in the docs or community items mentions this capability.

   ⚑ flag

   Plausible Analytics—none0/10

   The evidence pack covers Plausible's privacy stance on cookies, consent banners, and personal data collection, but nowhere does it address whether collected data is used to train AI models or how a user could opt out of such use. No policy or documentation snippet specifically discusses AI-training data usage.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Plausible Analytics
   PostHog—none0/10

   The evidence pack contains no mention of data retention settings, deletion APIs, GDPR-style data deletion, or retention policy controls anywhere in the docs, CLI, API, or CDP descriptions. This is a fair and expected axis for an analytics/data platform handling user event data, so absence of evidence means the story is unmet rather than inapplicable.

   ⚑ flag

   Plausible Analytics~partialcommunity5/10

   Plausible collects no personal data/no cookies and offers CSV export, self-hosting, and data-policy docs implying minimal retention, but there's no explicit documented mechanism for AI-native users to programmatically control retention windows or trigger deletion of specific data via API. missing for 10: explicit retention policy/duration documentation, API or dashboard controls for data deletion/right-to-erasure, and independent confirmation of these controls working.

   • [claimed-docs] “Plausible collects no personal data and requires no consent banner. Every visit in your dashboard is a real visit.”
   • [claimed-docs] “Plausible collects no personal data and requires no consent banner.”
   • [claimed-docs] “By using Plausible, you do not need cookie banners for analytics or to collect consent for tracking.”
   • [claimed-docs] “Export stats: download your data”
   • [claimed-docs] “Import stats: bring in data via CSV”
   • [community] “They don't store IP addresses. Information they gather are not stored in a way to build user profiles or do fingerprinting.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   PostHog—none0/10

   The evidence pack covers PostHog's product analytics, session replay, feature flags, MCP/CLI integrations, and self-hosting, but contains no mention of an opt-out setting for PostHog's own telemetry/usage tracking (e.g., CLI or SDK phone-home data collection). No documentation or community evidence addresses this capability.

   ⚑ flag

   Plausible Analytics—none0/10

   The evidence describes Plausible's privacy-friendly approach to tracking *website visitors* (no cookies, no personal data collection, no consent banners) but contains no mention of any telemetry or usage-tracking mechanism in the Plausible product itself (e.g., self-hosted CE phoning home to Plausible Inc.) nor any documented opt-out setting for such telemetry.

   ⚑ flag

Ai analytics ops

1. ai-native userHave an agent answer growth questions from live product data by running queries through the API or MCP server

   weight 3 · round to Plausible Analytics
   PostHog!disputedcontradicted5/10

   PostHog documents a first-party MCP server and CLI that let agents run HogQL/SQL queries, ship flags, and answer product questions from live data (posthog-docs-2, posthog-docs-19, posthog-docs-24, posthog-probe-4, posthog-docs-8/17 for SQL, posthog-docs-9 for warehouse queries). However, a hands-on community report describes the LLM/query integration failing to create a cohort via a SQL query and causing severe UI slowdowns, directly contradicting the smooth 'agent answers growth questions via query' promise (posthog-comm-8). missing for 10: independent corroboration that MCP-driven SQL queries reliably work at scale, and resolution of the reported failure/performance bug.

   • [claimed-docs] “Run trends, funnels, retention, and SQL queries from any MCP client or AI editor.”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”
   • [probe] “official MCP server documented at https://posthog.com/docs/model-context-protocol”
   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “SQL insights enable you to directly query your data with SQL commands like SELECT, FROM, JOIN, WHERE, GROUP BY”
   • [community] “I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql q…”

   proof ↗⚑ flag

   Plausible Analytics~partialprobed4/10

   Plausible has a documented Stats API with a /api/v2/query endpoint supporting complex stats queries via API keys, which an agent could call to answer growth questions from live data. However, there is no evidence of an official MCP server, no OpenAPI/machine-readable spec (probes show 404s for llms.txt, docs.md, openapi.json), and no agent-specific tooling or SDK documented. Missing for 10: MCP server integration, machine-readable API schema/discovery, and any agent-oriented documentation or examples.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://plausible.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://plausible.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

Raw access

1. developerRun analytical queries and pull raw event data back through a documented query/export API

   weight 3 · round to PostHog
   PostHog✓fullprobed8/10

   PostHog documents a full HogQL SQL query interface, a data warehouse that lets you query events/persons alongside external sources, a public OpenAPI spec (confirmed live at /openapi.json), and API-based event capture/export, plus MCP support for running queries programmatically. This directly satisfies running analytical queries and pulling raw event data via a documented API. missing for 10: independent/hands-on confirmation of raw event export via REST API specifically (evidence is mostly first-party docs), and no third-party validation of API rate limits/completeness for large-scale export.

   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [claimed-docs] “SQL insights enable you to directly query your data with SQL commands like SELECT, FROM, JOIN, WHERE, GROUP BY”
   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “capture events from any language that can send HTTP requests”
   • [probe] “PROBE openapi: HTTP 200 at https://posthog.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”

   proof ↗⚑ flag

   Plausible Analytics~partialprobed6/10

   Plausible documents a Stats API (/api/v2/query) that accepts simple and complex stats queries and returns JSON, plus an Events API for recording events, and API keys scoped for querying sites — this covers programmatic querying of aggregated stats. However, this is not a SQL/warehouse-style raw event export API; there's no evidence of raw event-level data export or a documented OpenAPI spec (probes confirm openapi endpoints 404), and no independent hands-on corroboration of the query API's depth or limitations. Missing for 10: raw event-level data export/warehouse-SQL-style querying, OpenAPI/schema documentation, and independent developer corroboration of the query API's capabilities.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “API keys are scoped to one team. The team selected in the top-right menu when you create the key determines which sites it can query.”
   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://plausible.io/openapi.json, https://plausible.io/swagger.json, https://plausible.io/api/opena…”

   proof ↗⚑ flag

2. developerQuery my raw events with SQL (or an SQL-equivalent query language) inside the platform

   weight 3 · round to PostHog
   PostHog✓fullclaimed9/10

   PostHog documents HogQL, a SQL-like query language, that lets developers directly query raw events with SELECT/FROM/JOIN/WHERE/GROUP BY, and also join across data warehouse sources alongside events/persons/sessions in one SQL query, plus MCP/agent access to run HogQL queries. This is well-documented first-party capability with clear syntax examples. missing for 10: independent hands-on verification of SQL query correctness/performance at scale (one community comment notes LLM confusion with cohorts, not the SQL feature itself).

   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [claimed-docs] “SQL insights enable you to directly query your data with SQL commands like SELECT, FROM, JOIN, WHERE, GROUP BY”
   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “with just plain text questions your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a …”
   • [claimed-docs] “your agents can ship a feature flag from a prompt, dig into a stack trace without leaving your editor, run a HogQL query through Claude”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible offers a Stats API (JSON query endpoint) and Events API, but there is no evidence of SQL or SQL-equivalent query language access to raw events inside the platform — no warehouse-style query editor, no SQL interface. missing for 10: SQL/SQL-equivalent query language, raw event-level query access, in-platform query editor.

   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”

   proof ↗⚑ flag

Warehouse

1. developerSync events between the platform and my own data warehouse (query warehouse tables in-product or export events continuously to it)

   weight 2 · round to PostHog
   PostHog✓fullclaimed8/10

   PostHog's data warehouse feature lets developers sync external sources (Stripe, Postgres, Salesforce, HubSpot, etc.) and query them alongside native events/persons/sessions in one SQL query, and the CDP allows continuous export of events to external destinations in realtime or on a schedule, satisfying both directions of the sync story. Missing for 10: independent/hands-on verification of the warehouse sync reliability or performance at scale, and clearer documentation of specific export destinations (data warehouses) beyond CRM/Slack examples.

   • [claimed-docs] “Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one…”
   • [claimed-docs] “You can use SQL (Structured Query Language) throughout PostHog to manage, query, and modify data.”
   • [claimed-docs] “SQL insights enable you to directly query your data with SQL commands like SELECT, FROM, JOIN, WHERE, GROUP BY”
   • [claimed-docs] “It pulls data in from the tools you already use, lets you filter and reshape events as they're ingested, and sends the result wherever it ne…”
   • [claimed-docs] “Pipelines are built from Hog functions, which you can configure from a template, write yourself, or have PostHog AI write for you.”
   • [claimed-docs] “Combine everything in PostHog's context warehouse so that you, your agents, and your dashboard can query it directly.”

   proof ↗⚑ flag

   Plausible Analytics—none0/10

   Plausible offers a Stats API for querying its own data and an Events API for sending events in, plus CSV export/import, but there is no evidence of syncing or continuously exporting events to an external data warehouse, nor querying warehouse tables in-product. missing for 10: warehouse export/sync capability (e.g. BigQuery/Snowflake integration), continuous event streaming to external warehouse, in-product warehouse query support.

   • [claimed-docs] “Plausible Stats API is a read-only HTTP interface for viewing historical and real-time stats.”
   • [claimed-docs] “The /api/v2/query endpoint accepts simple and complex stats queries in the POST request body and returns the metrics as JSON.”
   • [claimed-docs] “Export stats: download your data”
   • [claimed-docs] “The Plausible Events API can be used to record pageviews and custom events. This is useful when tracking Android or iOS mobile apps, or for …”

   proof ↗⚑ flag