Embedded Analytics: An Honest Build vs Buy Guide

At some point, every SaaS product gets the request: "can I see my usage inside the app?" Embedded analytics - charts and metrics shown to your customers inside your product, not internal dashboards for your team - is one of those features that sounds like a weekend project and isn't. Here's an honest breakdown of the three paths, with the costs people actually hit.

Option 1: Build it yourself#

The naive version is easy: pick a charting library, write a query, render a line chart. The production version is where the time goes:

• Queries get slow. Time-series aggregations over a growing events table will eventually fight with your production traffic. Now you're adding read replicas, rollups, or a separate analytics store - infrastructure you didn't plan to own.
• Per-tenant filtering is on you. Every query must be scoped to the requesting user, correctly, forever. A missing filter is a data leak.
• It never ends. Every new graph request lands on your roadmap, and each one is a new query plus new UI.

Realistic cost: weeks of upfront work and a permanent maintenance tax. Worth it only if analytics is your product or your visualization needs are genuinely unique.

Option 2: Buy a classic embedded BI tool#

The established embedded-BI vendors are powerful - full exploration UIs, white-labeling, SSO. The trade-offs: enterprise pricing that often scales per viewer (your customers' eyeballs become a line item), heavyweight integrations that take weeks, and feature sets designed for data teams rather than product engineers.

Worth it if you're a larger company with a data team and complex internal BI needs that also extend outward.

Option 3: The middle path - event logging + embeddable graphs#

The approach we built GraphJSON for: log your events as JSON once, build graphs with a point-and-click visualizer, and embed them with iframes. The dynamic Embed API lets your backend swap filters per request, so each user sees only their own data - the per-tenant problem reduces to passing a user id.

Two properties make this cheap to run: embeds are cached with a 15 minute TTL by default, so millions of dashboard views don't mean millions of queries, and there's no analytics infrastructure in your stack at all - the events live in ClickHouse on our side.

This is how Flurly powers their seller analytics and how One Simple API powers their user dashboards. We wrote a full walkthrough in How to Build Personalized User Dashboards, and the API details are in the embedding guide.

How to decide#

• Build if analytics is your core product or your charts are genuinely custom.
• Classic embedded BI if you have a data team, enterprise requirements, and the budget to match.
• The middle path if you're a product team that wants customer-facing metrics live this week, at a price that doesn't scale with your customers' eyeballs.