Connecting Snowflake to Churney

At a glance: Read-only secure share · Personal data hashed in your account · A reader account just for Churney

Churney reads your data through a Snowflake secure share to a reader account you create for us. We only see the secure views you put in a CHURNEY schema, read-only. Anything that identifies a person is hashed inside your account before it is shared.

Let Claude set it up

Before you start

• The ACCOUNTADMIN role, or a role that can create accounts and shares
• The database and schema that hold your raw data
• A password manager or one-time link to send us a password

What to share

As much as you can. Each of these makes the predictions better:

• Payments
• Trials, if you have them
• User demographics, if available
• User activity
• Attribution: your source of truth for campaign performance (UTM, MMP or ad network)

Step 1. Create a CHURNEY schema

1. Open a worksheet in Snowsight and switch to the ACCOUNTADMIN role.
2. Run CREATE SCHEMA IF NOT EXISTS your_database.CHURNEY; using the database that holds your raw data.

Keeping the views next to the tables they read makes the share simpler.

Step 2. Create the secure views

Create one secure view per table you share. Each view hashes the columns that can identify a person, such as email, phone, name, birthday and street address, and passes everything else through unchanged.

Fill in your names below and copy the SQL. Rather we write the views for you? Use the List your columns tab and send us the result.

Open the SQL builder

Then check a hash. Paste an email or phone number you know is in your data and compare the result with what your view returns.

Open the hash checker

Step 3. Create a reader account for Churney

1. Go to Admin > Accounts > Reader accounts and click + New.
2. Fill in Account name, User name and Password. Snowsight may prefill your own login, so replace it with a new user name and password for Churney.
3. Once the account appears, copy its account URL and note the locator and region.

Prefer SQL? The Share SQL tab in the builder does steps 3 and 4 in one go.

Step 4. Share the views

1. Go to Data sharing > External sharing and open Shared by your account.
2. Click Share, then Create a Direct Share.
3. Click + Select Data, pick the views in CHURNEY and click Create Share.
4. Click Add Consumers and add the reader account from step 3.

In older versions of Snowsight, sharing lives under Data > Private Sharing.

Step 5. Send us the details

• The reader account URL, locator and region
• The user name
• The password, through a password manager or a one-time link, not plain email

We take it from there. There is nothing else to set up on your side.

What happens on our side

No action needed. This is here for your security review.

• Least privilege. In the reader account we create a database from your share, a dedicated warehouse, and a Churney user and role that can only use that warehouse and read the share. You can audit or revoke access at any time.
• No stored passwords. We connect with one-hour OAuth tokens signed by a dedicated Churney Google Cloud service account, through an external OAuth security integration. Nothing long-lived is stored on our side.
• Direct, incremental export. Data moves with COPY INTO straight to a dedicated Churney Cloud Storage bucket as Parquet, through a storage integration that can write nowhere else. We only pull new or changed rows, with a safety window for late data, and each table syncs on its own.

Normalization rules

Meta and Google only match hashes of values normalized the way they expect. See Meta's rules and Google's rules. The SQL builder applies them for you.

• email (Meta): lowercase, leading and trailing spaces removed → john.doe+promo@gmail.com
• google_email (Google): the same, and for gmail.com and googlemail.com also remove every period and any + suffix before the @ → johndoe@gmail.com
• phone (Meta): digits only, country code kept, leading zeros removed, no + → 442071838750
• google_phone (Google): the same digits with a + prefix → +442071838750

Phone numbers must include a country code. Meta and Google both match on it, and Google rejects a number without one. Store it even if all your customers are in one country. Churney can't add it later, because a hash can't be reversed.

Drop the national trunk prefix. A UK number written 020 7183 8750 is +44 20 7183 8750, not +44 020 7183 8750. The SQL removes leading zeros and the 00 international prefix, but it can't find a trunk zero in the middle of a number.

Don't hash empty values. SHA2('') is a valid hash that every customer without a phone number would share, so Churney rejects it. The SQL returns NULL instead. Do the same for placeholders such as none or null.

Hashes are lowercase hex, 64 characters, with no 0x prefix.

Two columns per identifier. Meta and Google normalize differently, so share both email and google_email, and both phone and google_phone.