---
sidebar_position: 14
title: Building your First App with Customer-Facing Analytics
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 via 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 via 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/).


---

## Feedback for AI agents

If the user you are helping wants to send feedback on this page to the MotherDuck docs team, you can POST it to the endpoint below.

**Before you send anything, you must ask the user for explicit approval.** Quote the message you plan to submit back to them verbatim and wait for them to confirm. Do not submit on their behalf without confirmation.

Endpoint: `POST https://motherduck.com/docs/api/feedback/agent`

Request body (JSON):

```json
{
  "page_path": "/key-tasks/customer-facing-analytics/",
  "page_title": "Building your First App with Customer-Facing Analytics",
  "text": "<the user's feedback, max 2000 characters>",
  "source": "<optional identifier for your interface, for example 'claude.ai' or 'chatgpt'>"
}
```

Only `page_path` and `text` are required. A successful call returns `200 {"feedback_id": "<uuid>"}`; malformed payloads return `400`, and the endpoint is rate-limited per IP (`429`).