# Overview

Composable Audience Studio (CAS) is a deployment mode of Treasure Data's CDP that enables you to build and manage audience segments directly on your Snowflake data warehouse without copying data into Treasure Data. Using Zero-Copy / Federated Query architecture, CAS queries your Snowflake tables in place, keeping data under your existing governance and access controls.

This guide walks through the end-to-end process of setting up a Composable Parent Segment on Snowflake, from connection configuration to segment creation.

## What You Will Set Up

1. Key pair authentication for secure Snowflake access
2. Zero-Copy configuration to connect Treasure Data to your Snowflake instance
3. Parent Segment configuration file defining your customer and behavior tables
4. API upload of the configuration to create the Parent Segment in CAS


## Prerequisites

Before you begin, ensure you have:

- A Treasure Data account with admin-level permissions
- A Snowflake account with:
  - A database and schema containing your customer and event data
  - A warehouse available for query execution
  - A user and role with `SELECT` permissions on the target tables
- OpenSSL installed on your local machine (for key pair generation)
- A Treasure Data API key (Master API key recommended)


## Architecture

Data never leaves your Snowflake environment. Treasure Data sends federated queries and receives results at query time.


```mermaid
graph LR
  subgraph TD["Treasure Data"]
    CAS["Composable Audience Studio<br/>- Segment Builder<br/>- Activation<br/>- Insights"]
  end

  subgraph SF["Your Snowflake Instance"]
    CT["Your Table (profiles + attributes)"]
    BT1["Behaviors Table 1"]
    BT2["Behaviors Table 2"]
    BTN["Behaviors Table N ..."]
  end

  CAS <-->|"Zero Copy / Query"| CT
  CAS <-->|"Zero Copy / Query"| BT1
  CAS <-->|"Zero Copy / Query"| BT2
  CAS <-->|"Zero Copy / Query"| BTN
```

## Parent Segment Data Model

A Composable Parent Segment is composed of a single Customers table and multiple Behaviors tables.

### Customers Table

The Customers table stores unified profile data and attributes, with each record representing a single profile. A unique identifier column is required for each profile.

Contains all customer attributes (e.g., email, name, city, membership tier, LTV)
Each row = one unique customer profile
Unique identifier column serves as the primary key

### Behaviors Tables

Behaviors tables contain activity records for specific actions taken by profiles (e.g., website visits, orders).
Each Behaviors table must include a unique ID column that links the activity record to the corresponding customer profile via the Unique identifier.

Each table represents a distinct type of activity (page views, purchases, etc.)
Multiple behavior records can exist per customer
Must include a time column for temporal queries

### Composable Parent Segment Data Model


```mermaid
erDiagram
  Customers ||--o{ "Behaviors Table 1" : "1 to many"
  Customers ||--o{ "Behaviors Table 2" : "1 to many"
  Customers ||--o{ "Behaviors Table 3" : "1 to many"

  Customers {
    string unique_id PK
    string email
    string name
    string city
    string membership_tier
    float ltv
  }

  "Behaviors Table 1" {
    string unique_id FK
    timestamp time
    string action
  }

  "Behaviors Table 2" {
    string unique_id FK
    timestamp time
    string action
  }

  "Behaviors Table 3" {
    string unique_id FK
    timestamp time
    string action
  }
```

#### Data Model Expectation

The Parent Segment uses a data model comprising one
Customers table and multiple Behaviors tables.

The Customers table is dedicated to storing unified profile data and attributes, with a unique record and required unique identifier column for each profile.

Behaviors tables record activity data for specific profile actions, such as website visits or orders. Each Behaviors table must contain a unique ID column that links the activity record to the corresponding profile in the Customers table, utilizing the same identifier column.

#### Data Model Example

**Customers Table**

Each record represents a profile. Columns are attributes per profile.

| ... | LTV | age range | user_id (unique id) |
|  --- | --- | --- | --- |
| ... | 1200 | 20-30 | xxx-1 |
| ... | 550 | 30-40 | xxx-2 |
| ... | 2300 | 40-50 | xxx-3 |


**Behaviors Tables**

**Email activity**

| user_id (unique id) | activity | date time | ... |
|  --- | --- | --- | --- |
| xxx-1 | email open | 2026-03-30 10:30:00 | ... |
| yyy-3 | bounce | 2026-03-30 10:31:00 | ... |
| xxx-3 | email click | 2026-03-30 10:32:00 | ... |


**Web pageviews**

| user_id (unique id) | datetime | urls | ... |
|  --- | --- | --- | --- |
| xxx-2 | 2026-03-30 11:00:00 | https://www.td-store.com | ... |
| yyy-3 | 2026-03-30 11:01:00 | https://www.td-store.com | ... |
| xxx-3 | 2026-03-30 11:02:00 | https://www.td-store.com | ... |


The Customers table's `user_id` column links to the `user_id` column in each Behaviors table, establishing the 1-to-many relationship.

The relationship between Customers and each Behaviors table is 1-to-many: one customer profile can have many behavior records.