Analytics

Open source analytics tools track how people use websites, apps, and products, then turn that raw event data into dashboards, funnels, and reports. The category splits into a few distinct approaches. Web analytics platforms like Umami and Matomo record pageviews, referrers, and visitor counts as a privacy-respecting alternative to Google Analytics, often with no cookies and no data sent to a third party. Product analytics tools such as PostHog go further, capturing custom events, session recordings, feature flags, and A/B tests, so teams can see how users move through a specific flow rather than only which pages they visited. Business intelligence tools like Redash connect directly to a database or data warehouse and let teams write SQL queries, build charts, and share dashboards across a company. The analytics project (from the analytics.js ecosystem) is a different kind of tool: a lightweight, pluggable JavaScript library for sending events to multiple destinations from one API, useful when a team wants to own the tracking layer instead of committing to one vendor. Dub covers a narrower use case, short link creation and click tracking, useful for marketing campaigns and affiliate programs that need per-link analytics.

When choosing an analytics tool, the first question is what unit of data matters: pageviews and sessions (Umami, Matomo), individual user events and funnels (PostHog), or raw rows in a SQL database (Redash). The second is hosting and data ownership. All of these projects can be self-hosted, which matters for teams that need to keep visitor data in their own infrastructure for privacy law compliance (GDPR, CCPA) or contractual reasons. Self-hosting also removes per-event pricing, which becomes expensive on high-traffic sites once a SaaS analytics vendor is billing per pageview or per tracked user. The third is integration effort: a script tag (Umami, Matomo, PostHog) is a five-minute setup, while a full event-tracking library (analytics) or a BI tool wired to a warehouse (Redash) requires more implementation work up front but returns more precise, first-party data.

Most teams end up running more than one of these at once: a lightweight web analytics tool for traffic-level numbers, a product analytics tool for in-app behavior, and a BI layer over the underlying database for ad hoc queries that finance or product teams need answered.