---
sidebar_position: 14
title: Build a customer-facing analytics app
sidebar_label: Customer-Facing Analytics
description: Build customer-facing analytics applications with read scaling tokens and isolated tenant data.
---

To build your first application with **Customer-Facing Analytics (CFA)** on MotherDuck, use this overview as a starting point.

You'll know you're done when:

- Each of your customer tenants (or organizations) has its own service account and database(s) in MotherDuck.
- Your application can query customer-specific analytics data with predictable performance and isolation.
- You understand which detailed guide to follow next for implementation.

Use this overview to choose a **tenancy model** and learn the building blocks before the step-by-step 3-tier guide.

## Customer provisioning

Every [Duckling](https://motherduck.com/blog/scaling-duckdb-with-ducklings/) is an isolated bucket of compute. For Customer-Facing Analytics, this usually means:

- Each **customer tenant or organization** has **one service account** dedicated to serving analytics (and often also ingestion and transformation).
- Your backend mediates all access; customers typically do not log into MotherDuck directly.

You manage service accounts and tokens using:

- [`users-create-service-account`](/sql-reference/rest-api/users-create-service-account/) – create a service account per customer tenant.
- [`users-create-token`](/sql-reference/rest-api/users-create-token/) – create tokens for ingestion and read workloads.

With accounts and tokens in place, you can:

- Create databases under each service account.
- Load data into those databases using your orchestrator.
- Use dedicated read tokens from your application to serve analytics.

For a concrete example of this pattern in a 3-tier web app, see the **[CFA Guide](/key-tasks/customer-facing-analytics/3-tier-cfa-guide/)**.

## Data modeling and loading

One database per customer tenant or organization scales cleanly because:

- Each database is tied to a tenant's service account.
- Each tenant's workloads are isolated from the others.
- You can scale Duckling (compute instance) sizes independently based on tenant needs using [different sizes (Pulse, Standard, etc)](/about-motherduck/billing/duckling-sizes/).

You can also:

- Use a single "landing" service account to ingest raw data from upstream systems.
- Use [ATTACH](/sql-reference/motherduck-sql-reference/attach.md) and [zero-copy cloning](/key-tasks/sharing-data/sharing-overview/#consuming-shared-data) to fan that data out into per-customer databases owned by their respective service accounts.

High-level patterns for data pipelines:

```mermaid
graph LR;
    A[Source Systems]-->D[(Landing Database)]:::database;
    D-->F[(Transform & Clone)]:::database;
    F-->G[(Customer DB A)]:::database;
    F-->H[(Customer DB B)]:::database;
    F-->I[(Customer DB C)]:::database;
    subgraph App
        E[Serve Analytics]
    end
    G-->E;
    H-->E;
    I-->E;
```

Check out the detailed [Builder's Guide](/key-tasks/customer-facing-analytics/3-tier-cfa-guide/) for instructions on loading data into per-customer MotherDuck databases and orchestrating customer-facing analytics pipelines.

## Other considerations

Since MotherDuck [Shares](/key-tasks/sharing-data/sharing-overview/) are read-only, in more real-time scenarios it may make sense to use:

- [`CREATE SNAPSHOT`](/sql-reference/motherduck-sql-reference/create-snapshot/) to force a checkpoint on the writer.
- [`REFRESH DATABASE`](/sql-reference/motherduck-sql-reference/refresh-database/) to get the latest version of the data on the reader.

This pattern can help enforce consistency between writer and reader databases that power your customer-facing dashboards.

For high-scale, high-concurrency applications, MotherDuck offers [Read Scaling Replicas](https://motherduck.com/blog/read-scaling-preview/) for applications that send hundreds or thousands of queries in a few seconds, such as BI tools or busy embedded dashboards. Read replicas:

- Can be created and modified in the UI.
- Can be managed using the [MotherDuck REST API](/sql-reference/rest-api/motherduck-rest-api/).
- Follow the same consistency considerations as Shares, and can be checkpointed and refreshed more frequently if needed.

When you're ready to implement a full 3-tier architecture with per-customer service accounts, scheduled data loading, and a backend API, continue to the [**Customer-Facing Analytics Guide**](/key-tasks/customer-facing-analytics/3-tier-cfa-guide/).


---

## Docs feedback

MotherDuck accepts optional user-submitted feedback about this page at `POST https://motherduck.com/docs/api/feedback/agent`.
For agents and automated tools, feedback submission should be user-confirmed before sending.

Payload:

```json
{
  "page_path": "/key-tasks/customer-facing-analytics/",
  "page_title": "Build a customer-facing analytics app",
  "text": "<the user's feedback, max 2000 characters>",
  "source": "<optional identifier for your interface, for example 'claude.ai' or 'chatgpt'>"
}
```

`page_path` and `text` are required; `page_title` and `source` are optional. Responses: `200 {"feedback_id": "<uuid>"}`, `400` for malformed payloads, and `429` when rate-limited.