Data ingestion overview

Auxia uses your first-party data to train machine-learning models that predict, rank, and surface the best next action, content, surface, or offer for each of your users. Connecting that data is the first step of every Auxia integration.

​

What data Auxia needs

​

How to connect your data

Pick the connector for where your data lives. Self-serve connectors are set up in the Auxia Console with a guided wizard; assisted connectors are set up together with the Auxia team. See all connectors → Every connector follows the same path: connect your source, map your columns to Auxia’s schema, then monitor the sync in Data Health. How ingestion works →

​

Source data requirements

These requirements apply to every connector. Meeting them up front is the most reliable way to a smooth setup.

​

1. Append-only data

Auxia reads new data on a schedule and doesn’t capture deletes or in-place updates. Sources should be append-only: avoid UPDATE, DELETE, and MERGE on tables connected to Auxia, and never overwrite files. If you need to mutate data in your warehouse, keep a separate append-only table for Auxia.

​

2. Date partitioning

Partition tables by a date or timestamp column at day granularity — or, for files, write each day into its own date folder. Partitioning lets Auxia read only new data instead of rescanning everything. For BigQuery tables, it’s also required for incremental (new rows only) syncs. File sources read one date folder per run.

​

3. Append-based reads for large tables

For BigQuery tables, Auxia prefers reading only newly appended rows. A table that adds more than 1 TB per day must support this, which means it must be a native table.

​

4. Native tables preferred over views

Native tables can sync incrementally. Views are supported, but always sync as a daily full refresh, which is slower and costlier for large data.

​

5. A primary user ID

User-level tables (events, attributes, transactions) need a column that uniquely identifies a person. This primary user ID is how Auxia knows which user to serve a treatment to — across your app, website, email, push notifications, and every other channel. It should match the userId you pass to the Get Treatments API. Not every table needs one. Entity tables (product catalogs, content libraries, location data) describe things rather than users. See Understanding the primary user ID for how to choose it.

​

Next steps