How to Build a SaaS Usage Analytics Dashboard From Scratch

Most SaaS dashboards are built around billing data. MRR, churn rate, ARR growth. Those numbers matter, but they are lagging indicators. By the time churn shows up in your Stripe webhook, the user stopped getting value from your product weeks ago. Usage analytics gives you the leading indicators: which features people actually use, how often they come back, where they get stuck, and when engagement starts to decay.

Consider a real scenario. Your MRR looks healthy, growing 8% month over month. But your usage data tells a different story: 40% of paying customers have not logged in during the past 14 days. Feature adoption on your newest module is 12%. Power users are consolidating their workflows into fewer sessions, which could mean efficiency or could mean disengagement. Without usage analytics, you are flying blind on all of this.

The companies that build great usage dashboards share a common trait: they treat product events as first-class data, not an afterthought bolted onto a billing integration. This guide covers the full architecture, from event capture through visualization, with specific tools, cost estimates, and tradeoffs at each layer.

Everything starts with your event schema. A usage analytics dashboard is only as good as the events feeding it, and the most common failure mode is instrumenting too little, too late. You want a structured event taxonomy from day one.

Designing Your Event Schema

Every event should include a consistent set of properties: a unique event ID, the user ID, the tenant or organization ID (critical for multi-tenant SaaS), a timestamp in UTC, the event name, and a properties object for event-specific data. Keep event names verb-noun: created_report, invited_teammate, exported_csv, viewed_dashboard. Avoid vague names like "click" or "action" that require you to parse context from properties.

A practical taxonomy for a B2B SaaS product typically has 40 to 80 distinct event types. Group them into categories: authentication events (login, logout, password_reset), core workflow events (the actions that represent your product's value), collaboration events (invite, comment, share), and system events (error_encountered, integration_connected). Do not track everything. Track what maps to a question you need answered.

Client-Side vs. Server-Side Tracking

Client-side tracking (JavaScript SDK in the browser) captures UI interactions: button clicks, page views, feature discovery. Server-side tracking captures business logic events: subscription created, report generated, API call made. You need both. Client-side events tell you about user intent and navigation. Server-side events tell you about completed actions and system behavior.

For the client SDK, Segment's analytics.js or the open-source alternative RudderStack are solid choices. Both provide a unified API and can fan out to multiple destinations. For server-side, use a lightweight HTTP endpoint that accepts batched events. A simple Express or FastAPI service that validates the schema and pushes to a message queue (Kafka, Redpanda, or even SQS for lower volume) works well up to millions of events per day.

Event Volume Planning

Rough estimate: a typical B2B SaaS user generates 50 to 200 events per session, with 3 to 8 sessions per week. For 10,000 MAU, that is roughly 6M to 50M events per month. At 50,000 MAU, expect 30M to 250M events. A single event averaging 500 bytes means 50M events is about 25GB of raw data per month before compression. Plan for this from the start, even if current volume is a fraction of it.

Raw events are not useful for dashboards. You need a pipeline that ingests, validates, transforms, and stores events in a format optimized for analytical queries. Here is the architecture that scales from 1M to 1B events per month.

Ingestion Layer

Events arrive via your tracking SDK or server-side HTTP endpoint. The ingestion layer validates the schema (reject malformed events, log them for debugging), enriches with server-side context (GeoIP, user agent parsing), and writes to a message queue. Kafka is the standard for high-throughput ingestion, but Redpanda offers a Kafka-compatible API with lower operational overhead. For teams processing under 50M events/month, Amazon SQS or Google Pub/Sub is simpler and cheaper.

Storage: Why ClickHouse Wins for Usage Analytics

Traditional data warehouses like BigQuery and Snowflake work, but ClickHouse is purpose-built for the query patterns usage analytics demands. It handles aggregations over billions of rows in milliseconds, supports real-time inserts, and compresses columnar data aggressively (expect 10:1 to 20:1 compression ratios on event data).

ClickHouse Cloud starts at roughly $200/month for a production workload. Self-hosted on a single node with 16GB RAM and NVMe storage handles 100M+ events comfortably. For comparison, the same query volume on BigQuery would cost $300 to $800/month depending on scan frequency, and Snowflake's smallest warehouse runs about $400/month with moderate query load.

An alternative worth considering: Tinybird, which is a managed ClickHouse service with a REST API layer on top. You push events via HTTP, define transformations as SQL "pipes," and get API endpoints that your frontend can query directly. It eliminates the need to manage ClickHouse infrastructure and provides sub-second query responses out of the box. Pricing starts around $100/month for moderate event volumes.

Transformation Layer

Use dbt (or ClickHouse materialized views for real-time use cases) to transform raw events into analytics-ready tables. Core models you will need:

• fct_events: Cleaned, deduplicated event stream with standardized properties.
• fct_sessions: Events grouped into sessions using a 30-minute inactivity window.
• fct_daily_active_users: One row per user per day, with session count and event count.
• fct_feature_usage: Aggregated feature-level metrics by user, tenant, and time period.
• dim_users: User dimension table joining product data with billing status and plan tier.

Run dbt on a schedule: hourly for operational dashboards, daily for executive views. For real-time counters (concurrent users, live event streams), use ClickHouse materialized views that aggregate on insert, bypassing the batch transformation entirely.

With your pipeline in place, you can compute the metrics that actually drive product decisions. These go beyond the financial SaaS metrics that most founders already track.

DAU/MAU Ratio (Stickiness)

Daily active users divided by monthly active users. This ratio tells you what percentage of your monthly audience uses your product on any given day. A DAU/MAU of 50% means half your monthly users show up every day. Benchmarks: consumer social apps target 50%+, B2B SaaS products typically see 15% to 30%, and workflow tools used daily (Slack, Linear) hit 40% to 60%. If your ratio is below 10%, your product is not part of users' regular workflow.

Calculate it correctly: DAU is the count of unique users who performed at least one meaningful action (not just a page view or background sync) on a given day. MAU is unique users with at least one meaningful action in the trailing 28 days (use 28 days, not calendar month, to avoid month-length distortion).

Feature Adoption Rate

For each feature, track: (users who used the feature in the past 28 days) / (total active users in the past 28 days) x 100. Break this down further into discovery rate (how many users see the feature entry point), activation rate (how many try it once), and habitual usage rate (how many use it weekly).

This three-layer funnel is valuable for product decisions. If discovery is high but activation is low, your UI is surfacing the feature but users do not see the value. If activation is high but habitual usage is low, the feature solves a one-time need or users find it disappointing after the first try. Each diagnosis leads to a different intervention.

Retention Curves by Cohort

Group users by signup week. For each subsequent week, calculate the percentage still active. Plot these curves overlaid on each other. Three patterns matter: flattening curves (healthy retention, users who stick around long-term), continuously declining curves (you are leaking users at every stage), and smile curves (users leave, then some come back, which suggests a periodic use case).

Go one level deeper and segment retention by acquisition channel, plan tier, company size, and onboarding completion. You will almost always find that one segment retains dramatically better than others. That segment is your ideal customer profile, and your go-to-market should focus there. For a detailed comparison of tools that calculate these automatically, see our breakdown of PostHog vs. Amplitude vs. Mixpanel.

Time to Value and Activation Milestones

Track the median time from signup to each activation milestone. For a project management tool, the milestones might be: created first project (milestone 1), invited a teammate (milestone 2), completed first sprint (milestone 3). Plot the conversion rate and median time at each step. If 60% of users create a project but only 20% invite a teammate, that is where your onboarding friction lives.

The visualization layer is where data becomes actionable. You have two paths: embedded dashboards built with React charting libraries, or standalone BI tools. For a product-facing analytics feature, you need the former. For internal operational dashboards, the latter is faster.

React Charting Libraries for Embedded Analytics

Tremor: Built specifically for dashboards and data-heavy UIs. Ships with pre-built components for KPI cards, area charts, bar charts, and data tables. Tailwind-native styling. If you are already using Tailwind, Tremor gets you from zero to a polished dashboard in hours, not days. Best for: internal dashboards and customer-facing analytics pages.

Recharts: The most popular React charting library, with 22k+ GitHub stars. Declarative, composable, and handles most chart types well. Performance degrades with very large datasets (10,000+ data points per chart), so pair it with server-side aggregation. Best for: general-purpose charting with maximum customization.

Nivo: Beautiful defaults with D3 under the hood. Excellent for heatmaps, calendar charts, and chord diagrams that Recharts does not support. Best for: visually distinctive charts and uncommon chart types.

For most SaaS dashboards, Tremor for layout and KPI cards plus Recharts for custom charts is the combination that balances speed with flexibility.

Standalone BI Tools for Internal Use

Metabase is the default recommendation for internal dashboards. Open-source, self-hostable, and your non-technical team members can build their own charts with the visual query builder. Superset offers more power for SQL-fluent teams. Grafana excels at real-time operational metrics. All three connect natively to ClickHouse.

Dashboard Design Principles

Every dashboard should answer one question clearly. Do not build a single "analytics" page with 30 charts. Build focused views: an engagement overview (DAU/MAU, session frequency, active user trends), a feature adoption view (adoption rates, feature funnels, usage heatmaps), a retention view (cohort curves, churn risk scores), and a tenant health view (per-customer usage scores for your CS team).

Put the most important number in the largest font at the top left. Use sparklines for trend context. Use color intentionally: green for metrics trending favorably, red for metrics needing attention, gray for neutral. Avoid pie charts. Use horizontal bar charts for comparisons and line charts for trends over time.

Two architectural decisions will shape your system's complexity and cost more than anything else: how fresh your data needs to be, and how you isolate data between tenants.

Real-Time vs. Batch: Pick the Right Tradeoff

Batch processing (hourly or daily dbt runs) covers 80% of usage analytics needs. Retention curves do not change by the minute. Feature adoption rates are meaningful over weeks. DAU/MAU ratios update daily by definition. Batch is simpler, cheaper, and far easier to debug when something breaks.

Real-time processing matters for three specific use cases: live user counts (useful for demonstrating product traction or monitoring launches), event-triggered workflows (send an in-app message when a user hits a milestone), and usage-based billing (you need accurate counts before the billing cycle closes). For these, use ClickHouse materialized views or a stream processor like Apache Flink.

The hybrid approach works best for most teams. Batch dbt models run every 1 to 4 hours for dashboard metrics. ClickHouse materialized views handle the 2 to 3 real-time counters you actually need. Avoid building a full streaming pipeline (Kafka to Flink to ClickHouse) unless your event volume exceeds 100M per day or your billing model requires sub-minute accuracy. The operational burden of streaming infrastructure is significant: schema evolution, exactly-once processing, backpressure handling, and late-arriving events all add complexity.

Multi-Tenant Data Isolation

In a multi-tenant SaaS, every query must be scoped to a tenant. There are three isolation strategies, each with different security and performance characteristics.

Row-level isolation: All tenants share the same tables, with a tenant_id column on every row. Queries include a WHERE tenant_id = ? clause. In ClickHouse, make tenant_id part of your primary key (the first column in your ORDER BY clause) so the engine can skip irrelevant data blocks entirely. This is the right approach for 95% of SaaS products.

Schema-level isolation: Each tenant gets their own database schema. Provides stronger isolation and simplifies per-tenant backups, but increases operational complexity. Reserve this for enterprise customers with compliance requirements that mandate data separation.

Cluster-level isolation: Dedicated infrastructure per tenant. Only necessary for regulated industries (healthcare, finance) or government contracts. Cost-prohibitive for most SaaS companies.

Whichever model you choose, enforce tenant scoping at the application layer. Every API endpoint and every database query should include tenant context. Add automated tests that verify no query can return cross-tenant data.

The build vs. buy decision for usage analytics is more nuanced than most founders realize. Off-the-shelf tools like PostHog, Amplitude, and Mixpanel can get you running in a day. A custom pipeline gives you complete control. The right choice depends on your scale, your team, and what you plan to do with the data.

When to Buy

PostHog (open-source, self-hostable): The strongest option for engineering-led teams. Event tracking, session replay, feature flags, A/B testing, and a SQL query interface, all in one platform. Self-hosted on your infrastructure means your data never leaves your VPC. The free tier covers 1M events/month. Paid plans start at roughly $0.00031 per event beyond the free tier. At 50M events/month, expect to pay around $450 to $600/month. PostHog is the default recommendation for teams that want a product analytics pipeline without building from scratch.

Amplitude: Better for product managers who want self-serve analytics without writing SQL. Behavioral cohorting, predictive analytics, and a polished UI. The free tier is generous (up to 50M events/month for core analytics). Growth plans start around $49/month. The tradeoff: your data lives in Amplitude's cloud, and raw data export requires the enterprise tier ($50k+/year).

Mixpanel: Strong funnel and retention analysis. Similar pricing to Amplitude, with a free tier up to 20M events/month. Less flexible than PostHog for engineering teams, more intuitive than PostHog for product teams.

When to Build Custom

Build your own usage analytics pipeline when: you need to join usage data with billing, CRM, and support data in a single warehouse; your product includes customer-facing analytics as a feature (not just internal dashboards); you have strict data residency requirements that SaaS tools cannot satisfy; or your event volume exceeds 500M events/month, where vendor pricing becomes prohibitive and a self-managed ClickHouse cluster is cheaper.

The custom stack (ClickHouse or Tinybird + dbt + Tremor/Recharts) costs roughly $300 to $1,500/month in infrastructure, plus 4 to 8 weeks of engineering time to build. Compare that to $500 to $2,000/month for a vendor at the same scale, with zero engineering time but less flexibility.

The Hybrid Approach

Many teams start with PostHog for immediate analytics and build a custom pipeline in parallel for data warehouse integration and customer-facing analytics. PostHog's event data can be exported to your warehouse via their batch export feature or by self-hosting and querying the underlying ClickHouse instance directly. This gives you the best of both worlds: fast time-to-insight from PostHog and long-term flexibility from your own pipeline.

Here is what the full build looks like across three tiers, from scrappy startup to scaled platform.

Tier 1: Early Stage (under 10k MAU, under 20M events/month)

Use PostHog Cloud's free tier for event tracking and core analytics. Add Metabase (self-hosted, free) connected to your production database read replica for custom queries. Instrument 30 to 50 core events. Total cost: $0 to $100/month. Timeline: 1 to 2 weeks to instrument events and configure dashboards.

Tier 2: Growth Stage (10k to 100k MAU, 20M to 200M events/month)

Self-hosted PostHog or a custom pipeline with ClickHouse Cloud. dbt for transformations. Tremor + Recharts for a customer-facing analytics page. Tinybird as an alternative to managing ClickHouse yourself. Total infrastructure cost: $300 to $1,200/month. Engineering effort: 4 to 8 weeks for initial build, 10 to 15 hours/month for maintenance. This is the tier where the build vs. buy decision matters most.

Tier 3: Scale (100k+ MAU, 200M+ events/month)

Dedicated ClickHouse cluster (self-managed or ClickHouse Cloud). Kafka or Redpanda for ingestion. dbt + Airflow for orchestrated transformations. Custom embedded analytics for customers. Real-time materialized views for live metrics. Total infrastructure cost: $2,000 to $8,000/month. Engineering: dedicated data engineer, 1 to 2 months for initial build.

Common Pitfalls to Avoid

• Instrumenting too late. Add tracking from your first release. Backfilling event data is nearly impossible. Every week without instrumentation is a week of lost insight.
• Tracking everything. 200 event types with no taxonomy creates noise, not signal. Start with 40 to 60 well-defined events tied to specific product questions.
• Ignoring data quality. Duplicate events, missing tenant IDs, and inconsistent property names will poison your metrics. Validate schemas on ingest, deduplicate on write, and run automated data quality checks daily.
• Building real-time when batch is sufficient. Real-time pipelines are 3 to 5x more complex to build and operate. Unless you have a specific use case that demands sub-minute latency, batch processing every 1 to 4 hours is the right starting point.

Usage analytics is not a nice-to-have. It is the foundation for every product decision, retention initiative, and expansion play your team will make. The teams that build this infrastructure early compound their advantage, because every decision is informed by real behavior instead of intuition.

If you want help building a usage analytics dashboard, whether that is a custom ClickHouse pipeline, a PostHog deployment, or embedded customer-facing analytics, we have done this for SaaS companies at every stage. Book a free strategy call and we will scope out the right architecture for your product.