Why customer analytics shouldn't be priced per viewer
Per-viewer pricing — pay per active user who logs in to look at a dashboard — is the default for most BI tools. It works fine when the viewers are your own employees. It collapses the moment those viewers are your customers' employees, because every success metric you have makes the bill bigger. Here's the math we ran when we picked our model, and the failure modes we kept seeing in customers we were trying to help migrate off of incumbents.
The math
Take a B2B SaaS with 200 paying customers. Each customer has on average 30 employees who occasionally check the analytics dashboard you embed in your product. That's 6,000 monthly active viewers. Even at $20/MAU — a stand-in for the kind of per-viewer quote you'll see in embedded-analytics conversations, not a market-wide rate card — that's $120,000/year just for read access. You haven't ingested an event yet.
The viewer count is the wrong dimension to grow on. It is almost perfectly correlated with your customer's success: bigger customers have more seats, more seats means more dashboard viewers, more viewers means a bigger bill for you. The product function "more customer engagement → bigger BI bill" is not what anyone wants.
Worse, the per-viewer model creates an incentive to limit access to your own product. Several of the migrations we saw had explicit "we hide the dashboard from non-admin seats because it would double our analytics bill" lines in the discovery call. That is a product compromise being made to serve a vendor's pricing model.
Why per-viewer made sense for internal BI
For Looker or Tableau in their original use cases — internal BI for your own employees — per-viewer is reasonable. The viewer population is bounded (you have N employees). A heavy viewer runs heavy queries; metering on viewers is a rough proxy for compute. The vendor benefits from your headcount growth in a way that's roughly aligned with their cost.
None of that holds for embedded analytics:
- The viewer population is unbounded — it scales with your customer count, which can grow 10× in a year.
- Embedded viewers run a fixed set of queries (the widgets on the dashboards you designed). Metering on viewers stops being a proxy for compute the moment the queries are cached and bounded.
- Vendor cost scales with events ingested and queries executed, not viewer count. The pricing model is decoupled from the actual cost driver.
What we picked
Emban prices on tenants and events ingested. A "tenant" is one of your customers — the unit your customer pays you for. If Acme Corp uses your product, that's one tenant; whether 5 or 500 of Acme's employees view the dashboard inside your product is irrelevant to our bill.
The pricing aligns with two things you already know:
- Tenant count — how many of your customers you're shipping analytics to. You already track this number. It is the number that grows with your business.
- Event volume — how much data you're sending us to query. This is the actual cost driver: storage and compute scale with events, not with how many people open the dashboard.
Concretely, the Starter plan at $149/month covers 10 tenants and 1M events; Growth at $399/month covers 50 tenants and 10M events; Scale is custom because at that point we're talking about your specific event volume and infra preferences anyway.
Why it's safe to ignore viewer count
Two reasons it's actually fine for us to charge nothing for viewers:
- Cached query reads are cheap. A dashboard viewer reloading the page hits the cache for ~95% of widgets. The marginal cost of one more viewer is a few cache lookups and an iframe render. It's not worth metering.
- The expensive surface is data ingestion and the first miss, not the read. Once an aggregation is materialized into a daily rollup, querying it is cheap regardless of how many people look at it.
What this changes about how you build
When viewer count is free, you stop hiding the dashboard. You roll it out to every seat. You add a "share this dashboard" button. You let internal stakeholders at your customer's company browse it without admin gymnastics. Each of those is a small product win that per-viewer pricing actively discourages.
It also changes how you design the dashboards themselves. With per-viewer billing, you tend to build one heavyweight dashboard so the viewer activates and unlocks everything in a single login. With tenant-based billing you can ship many small dashboards in different parts of your product — contextual analytics next to the feature they describe, instead of one big "Analytics" page nobody clicks.
What to ask any vendor
- Do you charge per viewer, per dashboard load, per user, or per "monthly active user"? Any of those scales with your customers' success.
- What happens to my bill if I roll the dashboard out from 10% of my seats to 100%? If the answer involves an upgrade conversation, the model is wrong for embedded.
- Is there a hard cap or throttle on viewer count? If yes, you have a feature ceiling baked into your pricing.
- What's the marginal cost of one more viewer at the vendor's actual infrastructure? If they can't articulate it, the per-viewer fee is rent, not cost recovery.
The honest caveat
Tenant-based pricing works for embedded analytics. If you're picking a tool for your own internal BI team — five analysts who write ad-hoc SQL all day — Looker's per-viewer model is probably reasonable for that use case. We're not pretending Emban replaces a heavyweight internal BI workbench. We're saying: don't pay for an internal-BI pricing model when the workload is "render the same 12 widgets to your customer thousands of times a day."