Overview
Data Warehouse Exports write your raw Cometly data as Parquet files to an S3 bucket you own. Point your warehouse or lake tooling — Snowflake, BigQuery, Databricks, Athena, DuckDB, and others — at the bucket to load the data on your own schedule. You keep the raw, unaggregated data and model it however you like on your side.This is different from the API exports in the API Reference
(Create Event Export,
Create Contact Export,
Create Company Export). Those return gzipped NDJSON
for ad-hoc download through the API. Data Warehouse Exports deliver columnar Parquet files to your
own object storage for bulk, recurring loads. See
Exports vs Pagination for the API-side options.
How it works
Add a destination
Configure the S3 bucket and credentials Cometly writes to. See Set up an S3 destination.
Create an export
Choose a destination, a dataset, a cadence, and a window. See Create an export.
Datasets
Each export unloads exactly one dataset. To export several datasets, create several exports — each with its own cadence, window, destination, and columns.| Dataset | Description |
|---|---|
| Raw touchpoints | Every tracked touchpoint as recorded, over the window. |
| Raw conversions | Every conversion as recorded — the unattributed counterpart to touchpoints. |
| Raw hits | Every tracked pixel hit as recorded, unfiltered across all event types. |
| Attributed conversions | Conversions joined to their attributed touchpoints, at the attributed-touchpoint grain. |
| Contacts | Every contact created in the window, with its identity and custom fields. |
| Companies | Every company created in the window. |
| Ad analytics | Daily ad-performance rows per channel (Facebook, Google, LinkedIn, TikTok, Microsoft, Reddit, Taboola, AdRoll, Whop, X). |
Cadence and windows
An export runs on a cadence and covers a window of data. The two are independent: cadence is how often a run fires; the window is how much each run pulls.| Cadence | Runs | Window |
|---|---|---|
| One-time | Once, then stops | An absolute start/end date range you pick. |
| Daily | Once a day, at an hour you choose | A trailing window (e.g. last 7 days), capped at 90 days. |
| Hourly | Every hour | A trailing window, capped at 14 days (7 days for ad-analytics datasets). |
A run only re-exports rows that are still inside the window. To refresh data older than the
window (for example, after a backfill or a late restatement), create a one-time export over the
date range you want. The common pattern is a one-time backfill plus a recurring incremental export.
Column conventions
These conventions hold across every dataset, so the same column name means the same thing in every export.-
Timestamps are UTC. Every
*_utccolumn (andcreated_at/updated_at) is a UTC timestamp. The one exception is the ad-analytics metric date, which is a local calendar date — see that dataset’s page. - Locked vs optional columns. Some columns are locked (always exported — the ones that keep the data coherent, such as row identity and join keys); the rest are optional and you pick them at creation. Each dataset page marks which is which.
-
Cometly ID vs platform ID. Ad entities (account, campaign, ad set/ad group, ad) are carried as IDs only — never names. Each level exposes two columns:
cometly_<level>_id— Cometly’s own internal ID for the entity. Stable, and the reliable key for joining one export to another (e.g. touchpoints to ad analytics).platform_<level>_id— the advertising platform’s own ID for the same entity (the Facebook/Google/etc. ID). The key you join to your platform-side data; may be null.
- JSON-array columns. A few columns (the contacts identity-graph columns) are exported as JSON-encoded arrays. They’re optional and default to off.