---
title: "Customer-Facing Analytics for SaaS | Embedded Analytics Guide"
description: "Build customer-facing analytics into your SaaS product with MotherDuck. Learn about multi-tenant architecture, fast query performance, and when to use 3-tier vs browser-based execution."
canonical: "https://motherduck.com/learn/customer-facing-analytics-embedded-analytics-guide/"
related:
  - title: "Customer-Facing Analytics Overview | MotherDuck Docs"
    url: "https://motherduck.com/docs/getting-started/customer-facing-analytics/"
  - title: "Introducing Embedded Dives"
    url: "https://motherduck.com/blog/introducing-embedded-dives/"
  - title: "Beyond BI: Building Data Apps and Customer-Facing Analytics"
    url: "https://motherduck.com/webinar/building-data-apps-and-customer-facing-analytics/"
gated_asset:
  title: "Dives: Interactive Dashboards & Embedded Analytics"
  url: "https://motherduck.com/product/dives/"
---

# Customer-Facing Analytics for SaaS | Embedded Analytics Guide

> Build customer-facing analytics into your SaaS product with MotherDuck. Learn about multi-tenant architecture, fast query performance, and when to use 3-tier vs browser-based execution.

## What Is Customer-Facing Analytics?

Customer-facing analytics means embedding dashboards, reports, and data exploration directly into your product so your customers can access their own data. Instead of emailing CSV exports or building one-off reports, users get self-service analytics inside your application.

Also called **embedded analytics** or **user-facing analytics**, this approach turns data into a product feature—or the entire product itself.

**Examples:**
- A marketing platform showing campaign performance dashboards
- A fintech app displaying spending trends and transaction history
- A logistics SaaS with shipment tracking and delivery metrics
- An HR platform showing headcount, retention, and compensation analytics

---

## Embedded Analytics vs Data Apps

| | Embedded Analytics | Data Apps |
|---|-------------------|-----------|
| **What it is** | Adding analytics to an existing product | An application where data is the core value |
| **Example** | Shopify adding a "Reports" tab | A standalone dashboard or BI product |
| **Scope** | Feature within a larger product | The entire product |

Many SaaS companies start with embedded analytics and evolve into data apps as analytics becomes central to their value proposition. MotherDuck supports both.

---

## The Customer-Facing Analytics Challenge

Building analytics for your customers is harder than internal BI. Three challenges make traditional data warehouses a poor fit:

### Challenge 1: Technology Stack Mismatch

Most SaaS applications are built with JavaScript/TypeScript. Traditional analytical databases weren't designed for this ecosystem—they require complex drivers, connection pooling, and infrastructure that doesn't fit modern web development patterns.

### Challenge 2: Latency Requirements

Internal analysts tolerate slow dashboards. Customers don't. Every extra second of load time increases bounce rates and support tickets. You need **fast query response times**, not the multi-second latencies typical of distributed warehouses.

### Challenge 3: Multi-Tenancy at Scale

Each customer must only see their own data. But shared infrastructure creates "noisy neighbor" problems—one customer's heavy query slows down everyone else. Traditional solutions require overprovisioning or complex query management.

---

## How MotherDuck Solves This

MotherDuck is a serverless cloud data warehouse built on [DuckDB](https://motherduck.com/blog/duckdb-tutorial-for-beginners/). Its architecture is purpose-built for customer-facing analytics.

### Per-Customer Isolation with Ducklings

Each customer gets their own dedicated DuckDB instance called a **Duckling**. This provides:

- **Full compute isolation** — No noisy neighbor problems
- **Independent scaling** — Heavy users get more resources without affecting others
- **Data separation** — Each customer has their own database(s)

Ducklings have a cold start time of approximately one second. See [pricing](https://motherduck.com/pricing/) for billing details.

### Two Architecture Patterns

MotherDuck supports two approaches depending on your latency and data size requirements:

| | 3-Tier Architecture | 1.5-Tier Architecture |
|---|--------------------|-----------------------|
| **How it works** | Browser → App Server → MotherDuck | Browser runs DuckDB-Wasm locally |
| **Query latency** | ~50-100ms | ~5-20ms |
| **Best for** | Server-side logic, authentication, larger datasets | Read-heavy dashboards, smaller datasets (<1GB per user) |
| **Server cost** | Higher (compute) | Lower (data transfer only) |

**3-Tier** is the standard pattern: your app server authenticates users, queries MotherDuck, and returns results. Query latency is approximately 50-100ms.

**1.5-Tier** uses [DuckDB-Wasm](https://duckdb.org/docs/api/wasm/overview)—a WebAssembly build of DuckDB that runs directly in the browser. After initial data load, queries execute locally at 5-20ms. Users can even explore data offline.

You can combine both: use 3-tier for complex queries and authentication, 1.5-tier for fast interactive exploration.

### Read Scaling for High Concurrency

When you need to serve many concurrent users, MotherDuck's **read scaling** provisions additional Ducklings to distribute query volume. You don't manage load balancers or connection pools—MotherDuck handles it.

---

## Implementation Patterns

### Pattern 1: Per-Customer Service Accounts

Each customer company gets:
- Their own MotherDuck service account
- Dedicated database(s) for their analytics data
- [Isolated compute](https://motherduck.com/product/hypertenancy/) (Ducklings) for queries and data loading

This is the recommended pattern for strong isolation. Your app server authenticates users, looks up their read token, and executes queries against their specific database.

### Pattern 2: Shared Database with Row-Level Filtering

For simpler setups or smaller tenants:
```
motherduck://analytics_db
├── events (tenant_id, event_type, timestamp, ...)
├── metrics (tenant_id, metric_name, value, ...)
```

Filter every query by `tenant_id` and use **single attach mode** to restrict users to their designated database.

### Pattern 3: Hybrid with Data Lake

Use MotherDuck to query data directly from S3 or GCS while keeping frequently-accessed data in managed storage for faster performance.

---

## Build vs Buy: Choosing Your Stack

| Approach | Pros | Cons | Best For |
|----------|------|------|----------|
| **MotherDuck + custom frontend** | Full control, no per-seat fees, fast latency | More frontend work | Teams with frontend resources, unique UX needs |
| **MotherDuck + visualization tool** | Faster to deploy, pre-built charts | Less customization | Standard dashboard needs |
| **Traditional warehouse + BI** | Enterprise features | High cost, slow latency, per-seat licensing | Internal BI (not recommended for customer-facing) |

MotherDuck works with visualization tools like [Evidence](https://evidence.dev), [Streamlit](https://streamlit.io), [Rill](https://rilldata.com), and [Metabase](https://www.metabase.com)—or you can build custom dashboards with any frontend framework.

---

## Getting Started

1. **[Sign up for MotherDuck](https://motherduck.com/pricing/)** — Free tier includes 10GB storage
2. **Create a service account** — Via UI or REST API for automation
3. **Load customer data** — Sync from your application database, S3, or other sources
4. **Integrate with your app** — Use read tokens to execute queries from your backend
5. **Add visualization** — Build custom dashboards or connect a BI tool

See the [Customer-Facing Analytics Builder's Guide](https://motherduck.com/docs/key-tasks/customer-facing-analytics/3-tier-cfa-guide/) for detailed implementation steps.