Product analytics platform

1. Where we are today

Our platform runs 12 customer-facing SSPs across 13 brands in 4 countries (UK, US, Canada, Australia/NZ), powered by a single shared API. We've already invested in tracking — PostHog is deployed widely across our front-end properties — but the deeper layers (server-side events, warehouse, unified experimentation) are where the gaps remain.

Current tracking landscape

What's working

• Broad front-end coverage — PostHog is running across all brochureware sites, giving us visitor analytics and session replay for every brand.
• On the SSPs where it's deployed (including ETA, Sundays UK, and others), the user experience for reviewing session replays and event streams has been noticeably better than what GTM alone offers.
• Having PostHog and GTM running side by side has given us a natural comparison. PostHog's first-party, cookieless approach gives it advantages that are increasingly relevant as browser privacy restrictions tighten.
• The team is already familiar with the PostHog interface and data model.

What's not working

• SSP quote flow tracking lacks standardisation — PostHog is on all brochureware sites and the majority of SSPs, but the instrumentation isn't consistent across brands. Event naming, property structure, and depth of tracking vary from site to site, making cross-brand funnel comparison unreliable.
• No server-side tracking in the analytics layer — the CSP already captures business logic events server-side (policy lifecycle, partner referrals, and other operational data), but none of this flows into PostHog or any product analytics tool. Client-side and server-side data live in separate worlds, so there's no way to connect a user's browsing session to their downstream policy outcomes in a single view.
• A/B testing is siloed — Mida.so runs independently with no connection to PostHog analytics or revenue data. Experiment results can't be correlated with downstream outcomes like policy binds or LTV.
• No data warehouse — Stripe, GoCardless, HubSpot, and policy data all live in separate systems. There's no way to join them for cross-source analysis.
• No cross-brand funnel comparison — each site has its own PostHog project. There's no unified view to compare quote-to-bind conversion across brands.

2. The gap we're closing

This isn't a greenfield deployment — we already have the foundations. The goal is to consolidate what works, extend it consistently across all brands, and add the missing layers (server-side events, warehouse, unified experimentation).

3. Market options

Tier 1 — All-in-one platforms

Analytics + experimentation + session replay + warehouse/data layer in a single product.

PostHog is the generalist. Statsig is stronger if experimentation is the primary focus (used by OpenAI, Notion, Figma). Amplitude is the enterprise incumbent — powerful but expensive, designed for product managers rather than engineers.

Tier 2 — Product analytics only

Strong analytics, but you'd still need separate solutions for experimentation and warehousing.

Tier 3 — Privacy-first / web analytics

These are page-view counters, not product analytics. They would leave every gap still open.

Tier 4 — Build your own (warehouse + BI)

4. Why not build our own?

Our team has the technical depth to do it. The shared API is a single instrumentation point. We already run MySQL, Redis, queues. We could conceivably add an analytics_events table, emit events from the API, add a JS tracker to SSPs, and build dashboards in Metabase.

1. The instrumentation is the easy part. The analysis layer is the hard part.

Writing AnalyticsEvent::create([...]) at key points is straightforward. Building funnel analysis with arbitrary step ordering, time windows, property breakdowns, statistical significance, retention curves, user path visualisation, and cohort comparison — that's years of product development. PostHog has ~200 engineers working on this full-time.

2. Experimentation requires statistical rigour.

A/B testing isn't "show version A to half the users." It requires sequential testing, sample size calculations, confidence intervals, guardrail metrics, mutual exclusion between experiments, and proper randomisation. Getting this wrong gives false positives that lead to bad product decisions. Building it correctly in-house is a multi-month project that then needs ongoing maintenance.

3. Session replay is a massive engineering effort.

Recording, compressing, storing, and playing back DOM snapshots with console logs and network requests is an entire product category. The storage, indexing, and playback infrastructure alone is substantial.

4. The warehouse join layer is where value compounds.

The real power isn't "we can see events" — it's joining Stripe subscription data with quote flow behaviour with Hubspot lead source with policy data in a single query. Building sync jobs, schema mappings, and a query engine across disparate sources is exactly the problem these tools exist to solve.

5. Opportunity cost.

Engineering time is better spent on the insurance product — quote flows, underwriting logic, new brands, new markets. Every week spent building analytics infrastructure is a week not spent on what differentiates TTB. Analytics tooling is a solved problem. Our multi-brand insurance platform is not.

5. Recommendation: consolidate on PostHog

Why PostHog over GTM for analytics

Having run both side by side, several advantages have become clear:

• First-party data collection — PostHog sends data to its own endpoint rather than routing through Google's infrastructure. This means analytics data isn't subject to ad blockers or ITP restrictions that increasingly degrade GTM-based tracking.
• Cookieless tracking options — PostHog can operate without third-party cookies, using its own first-party cookie or cookieless mode. As browsers phase out third-party cookies, this becomes increasingly important for accurate measurement.
• Server-side tracking — PostHog's PHP SDK makes it straightforward to emit events directly from our API. Server-side events are immune to ad blockers, browser restrictions, and network issues. GTM's server-side container (sGTM) exists but is significantly more complex to configure and maintain.
• Better user experience — the PostHog interface for session replays, event exploration, and funnel analysis is purpose-built. GTM was designed as a tag deployment tool, not an analytics interface.
• Unified data model — events, replays, experiments, and warehouse queries all share the same user identity and property schema. With GTM, data flows to multiple disconnected destinations.

Ranking for TTB

6. What it enables for TTB

6.1 — Cross-brand conversion funnels

Each SSP sends events to PostHog with a brand property. We can then:

• Compare quote-to-bind conversion rates across all 13 brands side by side
• Identify which quote steps cause drop-off, per brand and per product
• Track which cover options and add-ons are selected most frequently
• Segment all of the above by country/region

6.2 — Revenue attribution

PostHog has a pre-built Stripe connector that syncs charges, customers, invoices, subscriptions, and balance transactions. Once connected, it auto-generates a revenue analytics dashboard with MRR, churn, LTV, ARPU, and growth rate.

By joining Stripe data with behavioural events on customer email/ID, we get the full picture: user visited SSP → started quote → selected covers → bound policy → pays monthly — in a single queryable view.

6.3 — A/B testing quote flows (consolidating Mida.so)

6.4 — Session replay for quote issues

Sentry tells us what errored. Session replay shows us what the user was doing when it happened. Useful for debugging quote flow UX issues that don't throw errors — confused users, rage clicks, form abandonment.

6.5 — HubSpot + policy data joins

PostHog has pre-built connectors for both Hubspot and MySQL. We can join CRM lead data with policy data and behavioural events in a single SQL query — e.g., identifying which marketing campaigns drive the highest LTV customers, or which Hubspot lifecycle stages correlate with actual policy binds.

7. Integration approach

Client-side — what's already done

PostHog JS is already running across all 14 brochureware sites and the majority of SSP quote flow apps (including ETA, Sundays UK, Sundays AU, and others) with session replay enabled. Each brand has its own PostHog project. This gives us broad front-end coverage. The gap isn't deployment — it's consistency of instrumentation.

Client-side — what's new

PostHog is already deployed on most SSPs, but the instrumentation needs standardising. Key additions:

• Add a consistent brand property across all sites for cross-brand analysis
• Standardise the event taxonomy (quote step names, cover option events, form interactions) so funnel analysis works across brands
• Enable feature flags for PostHog-managed A/B tests (replacing/complementing Mida.so)
• Ensure all SSP quote flows have the same depth of instrumentation — consistent event names, properties, and funnel step tracking

Server-side — new

Use the PostHog PHP SDK from the shared api-v3 Lumen service. Since all brands funnel through a single API, this is one integration point for server-side events. These are immune to ad blockers and browser privacy restrictions:

• Policy lifecycle events (inception, endorsement, cancellation, lapse, renewal)
• Payment events (Stripe charges, GoCardless mandates)
• Quote progression (server-side validation, pricing calculations)
• Claims events
• Underwriter interactions (TokioMarine API calls)

Data warehouse sources

Connect via PostHog's managed source connectors (UI configuration, no code):

• Stripe — charges, subscriptions, customers, invoices
• HubSpot — contacts, deals, lifecycle stages
• MySQL — policy data, brand instances, insurable details

What stays

• GTM — remains for marketing tags, third-party pixels, and conversion tracking that lives outside PostHog's scope. No need to remove it.
• Mida.so — can run in parallel during migration. As PostHog experiments are adopted for quote flow testing, Mida.so usage would naturally decrease.
• HubSpot embed — continues for chat/forms. HubSpot data also syncs into PostHog warehouse for cross-source joins.

8. Architecture scenarios

Two views of how PostHog fits into the TTB stack: what we'd build now, and where it could evolve if the data needs grow. These are meant to make the setup tangible — what talks to what, and where the data ends up.

8.1 — Scenario A: the recommended setup

This is the architecture we'd build in the rollout described in section 14. PostHog becomes the central analytics layer, pulling data from our existing systems and connecting it with user behaviour.

8.2 — Scenario B: the evolution path

If TTB's data needs grow — data science, ML, regulatory reporting, multi-department BI — the setup can evolve without replacing PostHog. PostHog stays as the product analytics layer; a dedicated warehouse handles the heavier workloads.

8.3 — The event model (example)

The architecture only works if the right events are flowing. Below is an example event model for TTB, based on patterns already present in the codebase — the tracking parameters the SSPs capture, the PolicyEvent lifecycle in api-v3, the policy_movement fact table, the reward/referral system, and the Activity audit log. The event names below are illustrative — the exact naming convention should be agreed by the team before implementation.

9. Multi-project architecture

We currently have 14 separate PostHog projects (one per brand). As we extend into SSP quote flows, server-side events, and the warehouse layer, it's worth deciding on the right project structure. There are several models, each with trade-offs.

Visibility & access control

A single-project approach doesn't mean everyone sees everything. PostHog supports:

• Role-based access — admin, member, and viewer roles control who can modify settings, create experiments, or view data
• Dashboard permissions — dashboards can be restricted to specific team members or teams
• Property-based filtering — saved views and default filters can scope a user's experience to a specific brand or region

This means a brand manager for Sundays UK could have a dashboard scoped to their brand without seeing ETA or BikeInsure data, while leadership has a cross-brand overview — all within the same project.

Moving data between projects (if needed)

If the architecture ever needs to split (e.g., a regulatory requirement forces data isolation for a specific region), data can be ported between projects:

• Data Pipelines (CDP) — PostHog's built-in CDP can export events from one project to a destination (S3, BigQuery, or another PostHog instance)
• Warehouse joins — the Data Warehouse can pull from multiple PostHog projects as sources and join them in SQL
• API export — PostHog's events API allows programmatic extraction for custom pipelines

10. Things to watch out for

11. The data warehouse reality check

This document recommends PostHog — and that recommendation stands. But it's important to be honest about what PostHog's data warehouse is and isn't, because the framing matters. The pitch isn't "use PostHog as your data warehouse." The pitch is: PostHog gives you one place to see your product data, your revenue data, and your customer data together — without building a separate warehouse stack.

11.1 — What PostHog's warehouse actually is

Under the hood, PostHog's data warehouse is a single-tenant DuckDB instance per customer, backed by Delta Lake for storage and Arrow Flight SQL for data transfer. It's built for analytical queries against synced business data — not for general-purpose warehousing at scale.

This isn't a criticism — it's the correct framing. PostHog is building a product analytics platform with warehouse capabilities, not a warehouse that happens to do analytics. The value for TTB is the unified view, not raw warehouse power.

11.2 — Performance at scale: what customers report

PostHog's analytics engine runs on ClickHouse, which is fast for typical product analytics queries. But at higher volumes, there are documented pain points worth knowing about:

• Dashboard lag at scale — multiple G2 reviewers report that "performance can occasionally lag when handling very large datasets." Teams running high event volumes notice dashboards becoming slower, particularly for complex funnels with property breakdowns.
• Cold query performance — PostHog themselves document that first-run queries can be significantly slower than subsequent runs due to Linux page cache behaviour. This is a known ClickHouse characteristic, not a bug, but it means the first person to open a dashboard in the morning may wait noticeably longer.
• JOIN limitations — ClickHouse is not designed for large-scale joins. PostHog has been refactoring their data model to remove the need for JOINs, but warehouse-style queries that join multiple synced sources may hit this ceiling. Hash joins previously required up to 80GB of memory for their largest customers and still failed in some cases.
• Client-side SDK impact — some users on GitHub have reported significant app performance degradation caused by the PostHog JS SDK, with one noting they spent "days searching for root causes" before identifying PostHog as the culprit. PostHog has acknowledged and worked on these issues, but it's worth monitoring during rollout.
• Custom query performance is your problem — PostHog optimises the queries they own (funnels, trends, retention). But warehouse SQL queries are user-written, and PostHog explicitly states they "can't optimise custom queries for you." Large dataset joins require careful query design.

11.3 — Experimentation maturity

PostHog's experimentation feature works, and it's significantly better than having Mida.so disconnected from analytics. But feedback from users who've run at scale suggests some limitations:

• Limited metrics per experiment — users report being limited to viewing approximately four metrics per experiment, which forces analysis outside PostHog's experimentation UI.
• "Good zero-to-one tool" — PostHog's experimentation is described as solid for getting started, but lacking advanced features (sequential testing, mutual exclusion layers, multi-armed bandits) that platforms like Statsig offer. For TTB's current needs (testing quote flow variations), this is likely sufficient. If experimentation becomes a core competency, Statsig may warrant a second look.
• "Black box" concerns — some users report limited transparency into the deeper statistical data behind experiments, making it harder to validate results independently.

11.4 — Learning curve and team readiness

PostHog is built for engineers, and that's both its strength and a potential friction point:

• Steep learning curve — this is the single most cited concern in G2 reviews (99+ mentions). Users find it "challenging to navigate and understand features," particularly non-technical team members.
• Technical expertise required — product managers without engineering backgrounds, designers, and marketers may struggle to use PostHog independently. The SQL-first approach to warehouse queries amplifies this.
• PostHog AI (Max) helps — the natural language query assistant mitigates this, but it's still a newer feature. The team should budget for onboarding time, particularly for non-engineering staff who need to self-serve dashboards.

11.5 — Cost predictability

PostHog's pricing is transparent and usage-based — that's genuinely better than Amplitude's opaque enterprise quotes. But usage-based pricing has its own risk:

• Unpredictable spikes — if a marketing campaign drives unexpected traffic, or a misconfigured event fires repeatedly, costs can spike. PostHog stops ingesting data when free tier limits are hit, which means you lose data until you upgrade — there's no grace period.
• Warehouse sync costs compound — full-table syncs (required for HubSpot) re-sync the entire dataset every cycle, driving up row costs. Sources continue syncing even when unused. PostHog recommends regular audits, but this requires discipline.
• The hidden cost is engineering time — as one reviewer put it: "what you save with PostHog's affordable prices, you end up spending on engineering time." The instrumentation, taxonomy design, and warehouse query writing still require skilled developer effort.

11.6 — The real argument: one view of your data

12. Insurance compliance & reporting

TTB operates across four regulatory environments (UK FCA, Australian APRA, US state regulators, Canadian provincial regulators). Any analytics platform we adopt needs to be assessed against what those regulators actually require — and what they don't. This section is a realistic look at where PostHog fits and where it doesn't.

12.1 — What regulators actually care about

Insurance regulators don't prescribe which analytics tools you use. They care about outcomes: can you demonstrate that you're treating customers fairly, retaining data appropriately, protecting personal information, and producing accurate reports when asked? The specific requirements vary by jurisdiction:

12.2 — Where PostHog is good enough

• Customer outcome monitoring (Consumer Duty) — this is PostHog's strongest compliance contribution. The FCA's Consumer Duty requires firms to monitor outcomes across the product lifecycle. PostHog funnels, session replays, and experiments provide direct evidence that quote flows are working as intended, that customers aren't being confused by pricing presentation, and that product changes improve outcomes. This is hard to produce from any other tool in the stack.
• Product governance evidence — showing that a product change (e.g., reordering cover options, changing pricing display) actually improved customer behaviour is exactly what PostHog experiments measure. This supports both FCA and ASIC product governance requirements.
• Marketing attribution compliance — by joining HubSpot lead source with policy bind data, PostHog can demonstrate which marketing channels produce good outcomes vs. poor ones — relevant to FCA's fair value assessments.
• Incident investigation — session replays provide evidence of what a customer experienced during a disputed transaction, supporting complaints handling and potentially FOS/AFCA investigations.
• Data retention — 7-year retention on paid plans aligns with typical regulatory minimums, though this should be validated per jurisdiction.

12.3 — Where PostHog is not sufficient

• Regulatory returns — APRA GRS forms, FCA product sales data, claims returns, and reinsurance reports all require certified financial data with specific schemas. These must come from the policy admin database, not an analytics tool. The CSP's existing 30+ reports and policy_movement table serve this purpose today.
• Actuarial and reserving data — loss ratios, IBNR reserves, and premium adequacy calculations require auditable financial data with full precision. PostHog's warehouse can visualise this data if synced from MySQL, but it shouldn't be the authoritative source.
• Formal audit trail — while PostHog event logs provide useful supplementary evidence, the regulatory audit trail for policy transactions (endorsements, cancellations, premium changes) should remain in the API's activity table where it has full JSON detail, timestamps, and is under our direct control.
• Data sovereignty for APRA — APRA CPS 234 requires that third-party vendors processing data meet the entity's information security requirements. PostHog Cloud is hosted in the US or EU — not Australia. For AU/NZ brand data, a formal assessment is needed. Self-hosting PostHog in an Australian AWS region is technically possible but adds operational overhead. Alternatively, AU data could flow to a separate PostHog instance or be excluded from session replay.
• Sensitive data in session replays — quote flows collect names, addresses, dates of birth, and payment details. PostHog's autocapture masking needs to be configured to redact sensitive fields before recording. This isn't a limitation of PostHog specifically — any session replay tool has this concern — but it requires deliberate setup.

13. Setup, maintenance & team

A common concern with adopting any analytics platform: does this require a dedicated hire? The short answer is no — not initially. But it's worth mapping out who does what.

What PostHog Cloud takes off your plate

By using PostHog Cloud (not self-hosting), the entire infrastructure layer is managed:

• No servers to provision, scale, or patch
• No database maintenance, backups, or migrations
• No version upgrades — always on the latest release
• No CDN or replay storage to manage
• 99.95% uptime SLA on paid plans

This eliminates the most common reason teams hire a dedicated analytics engineer — keeping the infrastructure alive.

What requires engineering work

PostHog's AI & self-serve capabilities

PostHog has invested heavily in lowering the bar for non-technical users:

• Max AI assistant — natural language querying across events, funnels, and warehouse data. Ask "what's the conversion rate for ETA bicycle quotes this month?" and it generates the query.
• Dashboard templates — pre-built templates for web analytics, product metrics, and revenue (auto-populated from Stripe connector).
• Guided experiment setup — wizards for A/B test creation with sample size calculations, significance thresholds, and guardrail metrics.
• SQL IDE with autocomplete — for warehouse queries, with schema browser and AI-assisted query generation.
• Session replay filters — find replays by event, error, rage click, or user property without writing queries.

Do we need an analytics hire?

Onboarding the team

PostHog offers:

• Free onboarding sessions for paid plans — a PostHog engineer walks through setup and best practices
• PostHog Academy — self-paced courses on product analytics, experimentation, and data warehousing
• Slack community — active support channel with PostHog engineers
• Extensive docs — framework-specific guides for Laravel, PHP, JavaScript

For our stack specifically (Laravel/Livewire + Lumen API), the integration patterns are well-documented and straightforward.

14. Recommended rollout

We're not starting from zero. PostHog is already live across all brochureware sites and the majority of SSPs. The rollout builds on this foundation by standardising what exists and adding the missing layers.

15. Cost projections

Adjust the sliders to model different traffic scenarios across our 13 brands. Costs are estimated from published pricing as of March 2026.

16. References

• PostHog Data Warehouse Documentation
• PostHog Supported Data Sources
• PostHog Stripe Source Connector
• PostHog Hubspot Source Connector
• PostHog Joining Data Across Sources
• PostHog Pricing
• Amplitude Pricing
• Statsig Pricing
• PostHog Alternatives Comparison (Userpilot)
• Amplitude vs Mixpanel vs PostHog (Brainforge)
• Best Product Analytics Tools 2026 (CleverX)
• Amplitude Contract Data (Vendr)
• How We Use PostHog's Built-in Data Warehouse (PostHog Blog)
• PostHog Customer Testimonials (PostHog Handbook)
• PostHog Managed DuckDB Warehouse
• The Secrets of PostHog Query Performance (PostHog Blog)
• PostHog Reviews (G2)
• Why a Company Switched from PostHog to Statsig (Statsig)
• PostHog Review: Pros, Cons, Features (The CX Lead)
• PostHog Leverages dlt for Data Warehouse (dlt Hub Case Study)
• PostHog JS SDK Performance Issue (GitHub)
• Cutting Data Warehouse Costs (PostHog Docs)
• APRA Reporting Requirements for General Insurance
• FCA Annual Compliance Report Requirements (Sedric)
• APRA CPS 234 Compliance Guide (UpGuard)
• Data Compliance Management in Insurance (Atlan)
• ICO Data Protection Audit Framework