Snowflake tables, activated across every ad platform you run.

No. Signals connects through a dedicated role scoped to SELECT on the schema or views you choose, typically the tables holding purchases, lead stages, or segment definitions, and nothing else. Access is read-only, and the role can be revoked or re-scoped from Snowflake at any time without waiting on us.

Yes. Most Snowflake environments run transformation logic through dbt before data reaches an activation-ready shape, and Signals reads whatever view or model your pipeline outputs rather than forcing a raw table underneath it. You point the mapper at the model you already trust, and it stays the source even as the underlying dbt job changes.

Most teams run incremental syncs from every fifteen minutes to daily, picking up only the rows that changed since the last read. A warehouse task that reruns hourly can feed a near real time destination feed, while teams that prefer a lighter footprint on compute run once or twice a day instead, and the cadence is a setting you choose, not a rebuild.

Any query against a Snowflake table consumes credits on the warehouse size assigned to it, so Signals is built to keep reads delta-based wherever possible, scanning only the rows that changed since the last sync rather than the full table on every run. You control which warehouse size the read role uses, so sync cost stays predictable and separate from the compute your BI workloads already run.