> ## Documentation Index
> Fetch the complete documentation index at: https://docs.auxia.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Understand how to connect your data to Auxia

<Note>
  **Data connections** are a crucial part of Auxia's platform. Typically, Auxia takes care of the heavy lifting involved in **data integration**. Your teams only need to share the relevant tables, and our internal deployment teams will handle the necessary transformations to bring the data into Auxia's system.
</Note>

Auxia utilizes your **1st-party data** to train **machine-learning models** that predict, rank, and surface the optimal next-best actions, content, surfaces, and offers for each customer.

### Data Requirements:

To begin this process, Auxia needs access to the following data:

1. **User event data**: This includes interaction details, such as clicks, screen views, and browsing activity across your website and/or app.
2. **User attributes**: Profile data on individual users, such as their **country**, **language**, and **registration date**.
3. **Transaction data**: This includes transaction-related information, like the **transaction amount**, **item name**, and **price**.

## Source Data Requirements

To ensure a reliable and efficient data connection, your source data must meet the following requirements regardless of the data connector you use:

### 1. Immutable Source Data

Auxia reads data incrementally — processing only new rows since the last run. Source tables should be **append-only**. For best results, avoid row-level mutations (`UPDATE`, `DELETE`, `MERGE`) on tables connected to Auxia.

If you need to mutate data in your warehouse, maintain a separate append-only table or view-materialized table for Auxia.

### 2. Partitioning

Tables must be **date-partitioned** (partitioned by a date or timestamp column at day granularity). Date partitioning is required for efficient incremental reads and cost control.

### 3. Append-Based Reads

Auxia's preferred method reads only newly appended rows. This is significantly more efficient than full-table scans. If a table adds more than **1 TB per day**, it **must** use append-based reads.

### 4. Native Tables Only

Auxia connects to native tables directly. Views are not currently supported, as incremental read functions (e.g., BigQuery's `APPENDS` and `CHANGES` table-valued functions) only operate on native tables.

### 5. Primary User ID

For user-level tables (events, attributes, transactions), the data must contain a column that uniquely identifies a user. This **primary user ID** is how Auxia determines which user to serve a treatment to — across your app, website, email, push notifications, or any other channel. Setting this identifier correctly ensures accurate personalization, model training, and treatment delivery.

Note that not every table requires a primary user ID. You may also connect **entity tables** (e.g., product catalogs, content libraries, location data) that describe things rather than users. These tables do not need a user identifier.

See [Schema Mapping: Primary User ID](/data-ingestion/overview/getting-started#understanding-the-primary-user-id) for how to configure it correctly during the mapping step.

## User Event Data

This section explains how Auxia works with **user event data** and outlines how the event data should be structured for smooth integration with Auxia's platform.

## User Attributes

This section explains how Auxia processes **user attributes** and provides guidelines on how these attributes need to be structured for integration with Auxia's platform.