Connecting BigQuery to Churney

At a glance: Read-only access · Personal data hashed in your project · Google authorized views

Churney reads your data through authorized views, the pattern Google recommends for sharing part of a BigQuery project. Your raw tables stay private. Anything that identifies a person is hashed inside your project before Churney can read it.

Let Claude set it up

Before you start

• Access to create datasets and manage IAM in the project that holds your raw data
• The Churney service account email. We send it to you.
• The region your data lives in, for example EU or US

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 dataset for Churney

1. In the BigQuery console, find the project that holds your raw data.
2. Click the three dots next to the project and choose Create dataset.
3. Name it churney and pick the same region as your raw data.

A view can only read tables in its own region, so the locations have to match.

Step 2. Create the hashed views

Create one 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.

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. Give Churney read access

1. Open IAM & Admin > IAM for the project and grant the Churney service account the BigQuery User role. It lets Churney run queries. It does not give access to any data.
2. Back in BigQuery, click the three dots next to the churney dataset and choose Share.
3. Click Add principal, paste the service account and give it BigQuery Data Viewer.

Step 4. Authorize the views

1. Open the dataset that holds your raw data. Click the dataset name itself, not the three dots.
2. Choose Sharing > Authorize views.
3. Add each view you created in step 2.

This lets each view read its raw table, so Churney can query the view without having access to the table.

Step 5. Tell us you're done

Send your Churney contact:

• The project ID
• The names of the views in churney
• The region

We run a test read and confirm the hashes look right.

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. SHA256('') 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.