Snowflake

Overview

Signals reads conversion, customer and audience data straight from your Snowflake warehouse on a schedule and sends the columns you nominate to your ad platforms.

Because the data already lives in Snowflake, there is no export job to maintain and nothing to go stale between runs. Signals reads only; nothing is written back.

You can point it at a table, or at a SQL query. The query path is what you want when the shape Signals needs does not match a table you already have.

Supported destinations

Destinations supported by Snowflake

Category	Supported
Offline Conversions	Google Offline Conversions API Google Store Sales LinkedIn Offline Conversions API Meta Offline Conversions API OpenAI Offline Conversions API Snapchat Offline Conversions API TikTok Offline Events API
Lead Conversions	Google Enhanced Conversions for Leads LinkedIn Leads Conversions API Meta Conversions API for CRM Snapchat Leads Conversions API TikTok CRM Integrations
Custom Audience	Google Customer Match Meta Custom Audience Snapchat Custom Audience TikTok Custom Audience

Authentication

In Studio, open Sources, find the Warehouse category, and click the Snowflake tile. This connector uses a username and password rather than a sign-in.

Field	Where to find it
User Account	Your Snowflake account identifier. It appears in the search bar in the Snowflake interface.
Warehouse Name	Admin, then Warehouses.
Database Name	Data, then Databases.
Schema Name	Expand the database in that list to see its schemas.
Username	Your profile menu, then My Profile.
Password	The password for that user.
Table Name	Expand the schema to see its tables. Asked on the table path only; on the query path the query names the table.

Six of these seven fields have to agree with each other. The warehouse, database and schema all have to be ones the user can actually reach, so it is worth confirming the user can query the table in Snowflake before entering anything here.

Caution

Create a dedicated user with read access to the one schema rather than reusing a person’s login. It keeps the connection working when someone changes their password and stops it seeing more than it needs. Enter the password on the Datahash connection screen only.

Configuration

Instance Setup

Select the Integration Type, which is the kind of data your records hold. Offline Events is the common choice. Give the instance a name, then choose the table path or the query path.

The Integration Type decides the columns Signals expects and which destinations the connection can feed, so it is worth settling before anyone models the table.

Table path

1. Download the File Format to see the column structure expected for the Integration Type you chose.
2. Enter the seven fields above.
3. Click Validate Credentials, then Finish.

Query path

1. Enter the connection details. The table name is not needed here, because the query names the table.
2. Click Validate Credentials, then Next.
3. Enter your SQL query.
4. Click Preview Results to check what the query returns, then Finish.

Preview Results is worth using properly rather than clicking past. It is the only point in the setup where you see the actual output, and a query that runs but returns the wrong column names will otherwise fail silently once the connection is live.

Snowflake folds unquoted identifiers to upper case, so a query written with lower case aliases may return column names that do not look like the ones you typed. Quote the aliases if the preview shows them in the wrong case.

Manage instance

One instance reads one table or query for one integration type. To read another, add another instance from the Manage existing instance table. To change an existing one, open it from there, click the edit option in the menu to the top right, update the fields and click Finish.

File format and schema

On the table path, download the file format during setup and shape the table to it. The column names are what Signals matches on, so a column that has been renamed or cased differently is not recognized and the row it belongs to is dropped rather than reported.

On the query path the same rule applies to the column aliases your query returns. Aliasing to the expected names in the SELECT is the usual way to reconcile a table you cannot or should not change.

Data & identifiers

Personal identifiers are normalized and hashed before they are sent to a destination.

Best practices

• Create a dedicated read-only user for Datahash with access to the single schema, rather than reusing an individual’s login.
• Prefer a view or a query with explicit column aliases over pointing at a raw table, so the warehouse team can change the model without breaking the connection.
• Quote the column aliases in your query if the preview shows them upper-cased. Snowflake folds unquoted identifiers.
• Confirm the user can query the table in Snowflake before entering the seven fields. Most validation failures here are permissions, not typos.
• Give the user permission to resume the warehouse, or keep it running, so a suspended warehouse does not stall the connection.
• Clean the data in the query: lowercase email, phone in E.164, no stray whitespace. Hashing a badly formatted value produces a hash that will never match.

Troubleshooting & FAQ

Validate Credentials fails. Work through the fields in order. The account identifier and the warehouse name are the two most often wrong, and a user without access to the named schema will fail even when every value is spelled correctly.

The credentials validate but nothing is read. The warehouse may be suspended and the user may not be allowed to resume it.

The table name is rejected. It is typed rather than selected, so it has to match Snowflake exactly. Remember that unquoted names are stored upper case.

The query previews correctly but nothing is delivered. The column names the query returns do not match the expected schema, often because Snowflake upper-cased the aliases. Quote them and preview again.

It was working and stopped. The password may have been changed or the user disabled. A dedicated service user avoids this.