# Overview

Composable Audience Studio (CAS) is a deployment mode of Treasure AI's CDP that enables you to build and manage audience segments **directly on your Google BigQuery data warehouse** without copying data into Treasure AI. Using Zero-Copy / Federated Query architecture, CAS queries your BigQuery 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 BigQuery, from GCP service account configuration to segment creation.

## What You Will Set Up

1. GCP service account and JSON key authentication for secure BigQuery access
2. BigQuery authentication configuration to connect Treasure AI to your BigQuery project
3. Zero-Copy catalog configuration for federated queries
4. Parent Segment configuration file defining your customer and behavior tables
5. API upload of the configuration to create the Parent Segment in CAS


## Prerequisites

Before you begin, ensure you have:

- A Treasure AI account with admin-level permissions
- A Google Cloud Platform account with:
  - A BigQuery project, dataset, and tables containing your customer and event data
  - Permission to create service accounts and manage IAM roles
- A Treasure AI API key (Master API key recommended)


## Architecture

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

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

  subgraph BQ["Your Google BigQuery"]
    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
  }
```

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