OpenPanel

Move beyond pageviews into funnels, cohorts, profiles, and replay

OpenPanel combines real-time dashboards with funnels, cohorts, user profiles, and session history so teams can investigate user behavior rather than stopping at traffic totals. Session Replay adds a concrete view of what happened inside individual sessions, allowing teams to move from an aggregate anomaly to the actual interaction sequence behind it. Keeping web analytics and product analytics on the same event model makes it possible to follow acquisition, feature usage, and drop-off without stitching together separate products.

Sources: [1]

Layer experiments, revenue, and notifications onto the event stream

Built-in A/B testing can break results down by variant, while revenue tracking places purchases, subscriptions, and lifetime value next to product events. Event- and funnel-based notifications can feed meaningful changes back into operations rather than requiring someone to inspect dashboards continuously. Custom dashboards and charts then let teams reshape the same analytics data around product, growth, or revenue KPIs.

Sources: [1]

Collect cross-platform events with cookieless tracking, SDKs, and APIs

The README positions OpenPanel as cookieless by default and privacy-first, with SDK and API access spanning web, Swift, Kotlin, React Native, and server-side use cases. It also advertises a hosted MCP Server for querying user and analytics data from clients such as Claude or Cursor, extending the platform beyond a human-facing dashboard. Because the current README describes that MCP Server as hosted and no-install, it should be evaluated separately from the self-hosted analytics core rather than assumed to be part of the local stack.

Sources: [1]

For product teams needing deeper behavior analytics than GA4

OpenPanel is a natural fit for SaaS products, web applications, and mobile apps that need to track signup, activation, feature usage, conversion, retention, and revenue in addition to page traffic. It is especially relevant when raw analytics data should stay on infrastructure the organization controls or when teams want one platform for both marketing-oriented traffic analysis and product-oriented event analysis. Because the product is SDK- and event-driven, it works best when engineering participates in tracking design rather than treating analytics as a marketer-only configuration task.

Sources: [1][2]

Self-hosting brings replay, WebSocket, AGPL, and trademark concerns

The official Docker Compose guide starts PostgreSQL, Redis, ClickHouse, the API, dashboard, and a background worker, with at least 2 GB RAM required and 4 GB or more recommended. As event volume grows, ClickHouse storage, retention, backups, worker scaling, and monitoring become operational concerns, and session replay naturally adds more data than event-only analytics. The Realtime view also depends on WebSocket connectivity, so custom reverse proxies must preserve the required upgrade path. The deployment guide explicitly recommends backing up before upgrades.

The repository's top-level LICENSE.md is GNU AGPLv3, so modified network-service deployments can trigger source-sharing obligations. Separately, OpenPanel publishes trademark guidelines that restrict use of the OpenPanel marks for managed services, resale, and public cloud offerings. In those cases the guidelines require removing OpenPanel logos and adopting independent branding, meaning commercial hosting scenarios should review software-license obligations and trademark rules as separate concerns.

Sources: [2][3][4]