Before we run the audit, we need to make sure we're asking the right questions about the right competitors to the right buyers. This document presents what we've learned about PostHog's market — your job is to tell us what we got right, what we got wrong, and what we missed.
Before we measure how often AI assistants cite PostHog in product-analytics and experimentation answers, these three signals tell us whether AI crawlers can reach, read, and trust your site at all. They are derived mechanically from the Layer 1 technical scan — no interpretation yet.
AI assistants are quickly becoming where engineering-led teams discover and shortlist an all-in-one product analytics and experimentation platform. The companies that establish citation visibility now gain a first-mover advantage that compounds — early citations become self-reinforcing as AI platforms learn which domains to trust on a given capability. PostHog enters this shift from a strong position: an open-source core, a developer-first reputation, and a deep, mostly-fresh comparison library. The question this audit answers is whether AI platforms can actually see and cite that strength.
This document is the input we validate together before the audit runs. It lays out the competitive set that shapes how we construct head-to-head queries, the buyer personas that determine which search intents we test, the capabilities and buyer frustrations that become query language, and the Layer 1 technical baseline that determines whether AI crawlers can extract your content at all. Each section exists to be confirmed or corrected — none of it is final until you weigh in.
The validation call is a decision-making session, not a status update. Two kinds of decisions come out of it: input validation — are the right buyers, competitors, and capabilities in the right tiers? — and engineering triage — which technical fixes can start before the results come back? Get those right and the query set is built against an accurate picture of how PostHog actually gets bought.
Purpose This is a validation document, not a finished audit. It presents the knowledge graph we built for PostHog — the competitors, buyers, capabilities, and frustrations that will drive a GEO visibility audit across the all-in-one product analytics and experimentation space — alongside the Layer 1 technical scan of posthog.com. We are showing you our inputs before we spend the audit measuring outputs.
Your Job Read each section and tell us what's right, what's wrong, and what's missing. The purple boxes are where your judgment matters most — each one names a specific assumption and explains what changes in the audit if our assumption is off. Everything you confirm or correct here directly shapes the query set.
Confidence Badges Every entity carries a confidence badge. High means it was directly observed (your site, your reviews, category listings). Medium means it was inferred or sourced from category patterns and deserves a closer look. Focus your attention on the medium-confidence items — those are where we're most likely to have it wrong.
→ Your primary competitive set deliberately spans two budget conversations — product analytics (Amplitude, Mixpanel, Heap) and feature management/experimentation (LaunchDarkly, Statsig) — because the all-in-one pitch invites both. Do buyers evaluate PostHog against both in a single decision, or are "replace our analytics tool" and "replace our feature-flag tool" two separate deals with different champions? If they're separate, we split the audit into two head-to-head query clusters instead of one.
5 personas: 2 decision-makers, 2 evaluators, 1 influencer. These drive the query set — every persona searches differently, so each one we get right (or wrong) reshapes which buyer intents the audit tests.
Critical Review Area Personas are the highest-leverage thing to get right — they determine the search intent behind every query. Two of these five are medium-confidence (Olivia Brennan, Ren Takahashi) and one is inferred rather than observed in your reviews (Jordan Ellis). Scrutinize whether each of these actually shows up in PostHog deals before we build queries around them.
Data Sourcing Note Role, seniority, department, influence, veto power, and technical level are pulled directly from the KG (review mining, category listings, and inference where noted in the source tag). Role descriptions, buying jobs, and query focus areas are synthesized from those fields to show how we'd model each buyer's search behavior — those are exactly what we want you to correct.
→ Dev is modeled as an evaluator with no veto — but in PostHog's engineering-led adoption, does the product engineer typically initiate and champion the purchase bottom-up? If yes, we weight discovery-stage queries toward IC-engineer language rather than executive evaluation language.
→ Mara holds veto in the founder-led deal — accurate for sub-50-employee buyers. But in PostHog's mid-market deals, does budget authority shift to a VP Engineering or Head of Platform? If so, we need a second mid-market decision-maker persona and validation-stage queries in their language, not the founder's.
→ Olivia is medium-confidence and rated technical_level "medium" — does the VP Product actually evaluate PostHog hands-on, or does she defer to engineering's recommendation? If she defers, her query focus shifts away from capability depth and toward reporting, stakeholder views, and "can my PMs use it" intents.
→ Ren is medium-confidence, sourced from category patterns rather than your reviews, yet carries veto power. Does a data / analytics-engineering leader actually veto product-analytics purchases in your deals, or only advise? If they only advise, we demote them from decision-maker and drop the warehouse/SQL-governance validation query cluster.
→ Jordan is inferred, not observed in your review data. Does a dedicated growth PM actually show up in PostHog deals, or is that role absorbed by the product engineer and VP Product? If the role is absent, we drop the experimentation-velocity query cluster built around them.
Who Else Shows Up? A few roles often appear in engineering-led analytics deals — do they show up in yours? DevOps / Platform Engineer (if self-hosting and infra ownership is a distinct evaluation track from the product engineer's). Head of Security / Compliance or DPO (if the privacy review that gates "can we ship user data to a SaaS" is run by someone other than the data lead — this ties directly to your data-ownership pain point). Engineering Manager (if a team lead, not the founder, owns the tooling budget in larger orgs). Each missing role that's real warrants its own query cluster. Who else is in your deals?
5 primary + 4 secondary competitors identified. Tier assignments decide which vendors get head-to-head treatment in the audit versus appearing only as category context.
Why Tiers Matter Tier assignments determine which matchups the audit tests directly. With 5 primary competitors, we'll build roughly 30–40 head-to-head queries — "PostHog vs Amplitude," "PostHog vs Statsig," "best all-in-one product analytics vs feature-flag tools" — that test whether AI assistants cite PostHog when a buyer is actively comparing. All five primary competitors are high-confidence; the uncertainty is in the secondary tier, where all four (LogRocket, FullStory, Hotjar, Google Analytics) are medium-confidence and Google Analytics in particular was added by inference rather than observed in comparison data.
→ Three things to confirm: (1) Google Analytics was added by inference — it's a common "before" tool, but does it actually come up when buyers compare PostHog, or only as the thing they're migrating off? If the latter, we drop it from head-to-head queries and keep it only in migration-intent queries. (2) Are any of the medium-confidence secondaries (LogRocket, FullStory, Hotjar) actually irrelevant to your real deals? (3) Is any peer missing — Pendo, June, Eppo, or another that shows up in your comparisons but isn't listed here?
12 buyer-level capabilities mapped, rated outside-in from your reviews and the category. These determine which capability queries the audit tests — and where you play offense versus defense.
See how users move through funnels, where they drop off, and what keeps them coming back.
Watch real user sessions to see exactly what they did before a bug, drop-off, or rage click.
Roll features out gradually, target specific users, and kill a release without redeploying.
Run A/B tests with statistical significance and tie results directly to product metrics.
Get analytics, replay, flags, A/B tests, and surveys in one tool instead of stitching five together.
Query raw product data with SQL, join external sources, and build BI without exporting elsewhere.
Self-host or keep data in the EU so we own our user data and aren't locked into a vendor.
Pay only for what we use with a generous free tier and no enterprise sales call to see a price.
Drop in an SDK, autocapture events, and integrate fast with great docs and a clean API.
Let PMs and marketers answer their own questions without SQL or an engineer's help.
Ask users targeted questions in-product and tie their answers to what they actually did.
Catch exceptions and monitor LLM/AI feature behavior alongside the analytics, not in a separate tool.
Prioritization Seven capabilities are rated Strong: Product Analytics, Session Replay, Feature Flags, All-in-One Product OS, Open Source & Data Ownership, Transparent Usage-Based Pricing, and Developer Experience. The audit tests all 12, but competitive-differentiation queries will emphasize 3. Which of these seven best represents where PostHog actually wins deals — the strengths a buyer cites as the reason they chose you over Amplitude or Statsig?
→ We rated Ease of Use for Non-Technical Teams "weak" (the #1 recurring complaint in reviews is the SQL/HogQL learning curve) and Experiments & A/B Testing "moderate" relative to Statsig. Two questions: (1) Is experimentation genuinely weaker than Statsig/LaunchDarkly in head-to-head deals, or have recent releases closed that gap — if it's stronger than rated, we move it into the differentiation query set instead of playing defense. (2) Are any of these 12 actually two capabilities a buyer searches for separately (e.g., Data Warehouse vs. SQL Access), or any two redundant enough to merge?
10 pain points: 6 high, 4 medium severity. The buyer language here is literally how queries get phrased — severity decides which frustrations we test first.
→ Three checks: (1) Six of ten pains are rated high and none low — is that distribution right, or is one of the mediums (e.g., experiment setup too slow) actually a dealbreaker for growth teams that should be tested first? Severity drives query ordering. (2) Does the buyer language ring true — would your buyers really say "my analytics bill exploded and I had to call sales"? (3) Two category-specific pains aren't here — do buyers raise migration / re-instrumentation cost when leaving Amplitude or Mixpanel, or doubts about autocapture data quality? If either shows up in deals, it becomes its own query cluster.
The Layer 1 scan of posthog.com surfaced the technical conditions that determine whether AI crawlers can extract and cite your content. These are engineering hand-offs — the audit measures citation visibility separately.
Actionable Now — Engineering No critical blockers: robots.txt is healthy and blocks no AI crawlers. But three high-severity technical items deserve engineering's attention now. The highest-leverage one is to verify client-side rendering on the eight flagship product pages — they returned only ~100–200 words of extractable text each, and confirming whether the content is JS-injected (invisible to non-rendering crawlers) decides whether the fix is a markup change or a rendering-architecture change. In parallel, engineering can populate lastmod timestamps across the 14,550-URL sitemap (currently none carry them) and refresh the 2.5-year-old /blog/posthog-vs-statsig comparison. None of these require waiting for the validation call.
What we found: The eight core product pages — /product-analytics, /web-analytics, /session-replay, /feature-flags, /experiments, /surveys, /error-tracking, and /ai-observability — render as interactive slide/presentation components. When fetched, each returned only ~100–200 words of extractable text, no clean H1/H2 heading hierarchy (the rendered output collapsed to a single "Slides" label plus presenter notes), and the substantive feature detail was not present as crawlable body text. By contrast, the newer suite pages built with conventional HTML (/data-stack, /cdp, /pricing) returned 650–3,500 words of structured, well-headed content.
Why it matters: These are the canonical landing pages for PostHog's strongest, most-searched capabilities (product analytics, session replay, feature flags). If an AI crawler sees only a sentence or two of extractable text where a buyer expects a full feature explanation, the page cannot be cited to answer "what is PostHog session replay" or "how do PostHog feature flags work" — the queries these pages should win. PostHog currently ranks for these capabilities largely on the strength of its comparison blog posts rather than its own product pages.
Recommended fix: Ensure each flagship product page exposes its full feature narrative as server-rendered, crawlable HTML with a proper heading hierarchy (single descriptive H1, H2/H3 per feature block) rather than as slide content that may require client-side interaction to reveal. The deep, well-structured treatment already present on /data-stack and the /blog/posthog-vs-* pages is the template to match.
What we found: Several high-value content-marketing pages carry visible dates well outside the dominant AI citation freshness window. The dedicated head-to-head comparison for a PRIMARY competitor, /blog/posthog-vs-statsig, is dated Dec 14, 2023 (~2.5 years old) while every other posthog-vs-* page was refreshed in Jan–Mar 2026. The flagship Y Combinator case study (/customers/ycombinator) is dated Oct 5, 2022 (~3.7 years old), and the Supabase and Lovable case studies are ~12 and ~10 months old respectively.
Why it matters: Comparison and case-study pages compete directly for buyer-evaluation and proof queries, and AI assistants concentrate citations on recently-updated content (Ahrefs found AI-cited content is on average 25.7% fresher than non-cited content; ConvertMate found 76.4% of ChatGPT's most-cited pages were updated within the last 30 days). A 2.5-year-old Statsig comparison is the weakest link in an otherwise fresh, comprehensive comparison library, and an old flagship case study undercuts the proof PostHog can offer in "is PostHog worth it" queries.
Recommended fix: Refresh /blog/posthog-vs-statsig to parity with the other comparison pages (current pricing, feature matrix, and an updated date) as the priority. Re-validate and re-date the Y Combinator case study, and establish a rolling refresh cadence for case studies so none exceed ~12 months without review.
What we found: The sitemap index (sitemap-index.xml) points to a single child sitemap (sitemap-0.xml) listing 14,550 URLs. Deterministic parsing confirmed that not one URL carries a <lastmod> element — every entry has only <changefreq> and <priority>. Freshness signals therefore exist only as visible dates on individual pages (present on blog/case-study content, absent on product pages).
Why it matters: lastmod is a primary signal crawlers use to schedule re-crawls and to judge content recency. With 14,550 dateless URLs, search and AI crawlers cannot efficiently identify which of PostHog's pages were recently updated, and freshness-weighted citation algorithms get no machine-readable recency cue — pushing them to rely on visible on-page dates, which most product and documentation pages lack.
Recommended fix: Populate accurate <lastmod> values in the sitemap, driven from each page's true last-modified date in the CMS/build pipeline. Prioritize accuracy over blanket timestamps (a sitemap that reports everything as modified today is ignored as noise).
What we found: robots.txt exists and blocks no AI crawlers — GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, and Bytespider are all "not mentioned" and therefore implicitly allowed (a healthy starting state). The only directives present disallow markdown (/*.md$) for Googlebot, Bingbot, DuckDuckBot, and Yeti — note PostHog publishes LLM-friendly .md versions of pages, and these are intentionally kept out of traditional search indexes.
Why it matters: Implicit allow works today, but as more AI platforms ship crawlers, an unmanaged robots.txt leaves crawler access to chance and gives no explicit record of which AI systems PostHog has chosen to permit. Explicit directives make the policy auditable and intentional rather than incidental.
Recommended fix: Optionally add explicit User-agent allow blocks for the AI crawlers PostHog wants to permit (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, etc.) so the policy is intentional and documented. No urgent action is required since nothing is currently blocked.
The following items could not be assessed through our analysis method (rendered markdown). We recommend your engineering team verify these manually before the validation call.
What to check: The flagship product pages returned very little extractable text through our rendered-markdown fetch. We cannot determine from rendered output alone whether the missing feature content is (a) genuinely absent from the server-rendered HTML, (b) injected client-side via JavaScript and therefore invisible to crawlers that do not execute JS, or (c) present but locked inside an interactive slide component. This is the single highest-leverage thing to confirm — it determines whether the fix above is a content/markup change or a rendering-architecture change.
Recommended action: Load each flagship product page with JavaScript disabled (or use Screaming Frog / Google's URL Inspection "rendered vs. raw HTML" view) to confirm how much feature text is present in the initial server response. If content only appears after JS execution, prioritize server-side rendering or static pre-rendering for these pages.
What to check: Our analysis reads rendered markdown, not raw HTML, so JSON-LD structured-data blocks are not visible to us. We could not confirm whether product pages carry Product/SoftwareApplication schema, whether comparison and blog posts carry Article schema, whether the pricing page carries Offer/Product schema, or whether FAQ blocks (present on many comparison pages) carry FAQPage schema.
Recommended action: Run a sample of each page type (product, comparison blog, pricing, case study, docs) through Google's Rich Results Test or a structured-data validator. Add the most specific applicable schema type with populated required fields where missing — FAQPage for the comparison FAQs and pricing FAQ is the highest-value quick win.
What to check: Rendered-markdown fetching does not expose <meta name="description">, Open Graph, or Twitter Card tags, so we could not assess whether pages carry well-crafted meta descriptions or social-preview metadata.
Recommended action: Spot-check a representative sample of pages with a social-preview tool (e.g., opengraph.xyz) or view-source. Ensure each commercially important page has a unique, descriptive meta description and complete OG/Twitter tags.
Partial Sample Freshness and schema coverage could not be scored for all pages. All 21 product pages and 4 structural pages returned no detectable date (25 of 40 pages unscored on freshness), so the 0.38 weighted average reflects only the 15 blog/comparison pages that carry visible dates. Schema markup could not be read at all from rendered output (40 unscored). Both gaps are in the Manual Verification Checklist above — verify before the call.
Why Now GEO is a time-sensitive opportunity for an engineering-led analytics platform:
• AI search adoption is accelerating — how engineering and product buyers discover analytics tools is shifting quarter over quarter.
• Early citations compound: domains that AI platforms learn to trust on a capability get cited more often as their citation history accumulates.
• Competitors who establish GEO visibility first create a structural disadvantage for late movers — and PostHog already has the comparison-library raw material to move fast.
• Product-analytics and experimentation is still early-innings in GEO optimization — acting now means competing against inaction, not against entrenched strategies.
The full audit will measure how often AI assistants cite PostHog across real buyer queries in the product-analytics and experimentation space — from capability questions like "best all-in-one product analytics tool" and "open-source analytics you can self-host" to head-to-head comparisons like "PostHog vs Amplitude" and "PostHog vs Statsig." You'll see exactly which of those queries return answers that name your competitors but not PostHog — and, because the slide-based product pages and stale Statsig comparison are fixable now, you can raise the baseline before we even measure it. Companies that act in this window see results before competitors recognize the opportunity exists.
A 45–60 minute working session to walk through this document — confirm the personas, competitor tiers, capabilities, and pain points, and resolve the open questions in the checklist below.
We build the buyer query set from the validated knowledge graph and run it across the selected AI platforms, capturing where PostHog is and isn't cited.
Visibility analysis, competitive positioning across the citation set, and a prioritized three-layer action plan — including the content recommendations this document deliberately holds back until we have query data to rank them.
Start Now — Engineering Three technical fixes don't depend on the rest of the audit and will improve your baseline visibility before we even measure it: (1) verify client-side rendering on the 8 flagship product pages (a <1-day check that decides whether the slide-deck content gap is a markup or rendering-architecture fix); (2) populate accurate lastmod timestamps across the 14,550-URL sitemap so refreshed pages get re-crawled promptly; (3) validate schema markup on a sample of each page type and add FAQPage schema to the comparison and pricing FAQs as the quick win. Robots.txt is confirmed healthy (no AI crawlers blocked), so no emergency there — but adding explicit AI-crawler allow blocks would make that policy intentional rather than incidental.
Two jobs before we meet. The questions on the left require your judgment — no one knows your business better than you. The engineering tasks on the right don't require the call at all.