Google BigQuery

Overview

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

Because the data is already modelled in BigQuery, 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 Google BigQuery

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
Product Catalog	Google Local Product Inventory Google Product Catalog

Prerequisites

• A Google Cloud project with BigQuery enabled.
• A Google Cloud service account holding the BigQuery Job User and BigQuery Data Viewer roles. Signals reads only, so it does not need write access.
• A service account key as a JSON file.
• The project ID and the dataset ID, and the table name if you are using the table path.

Authentication

In Studio, open Sources, find the Warehouse category, and click the Google Big Query tile. This connector uses a service account key rather than a sign-in.

Field	Where to find it
JSON Key	In Google Cloud, open IAM and Admin, then Service Accounts. Open the service account, go to Keys, click Add Key, then Create New Key, and choose JSON.
Project ID	The project selector at the top of the Google Cloud console shows it.
Dataset ID	In BigQuery Studio, expand the project and select the dataset.
Table Name	Inside that dataset. Asked on the table path only; on the query path the query names the table.

The project is taken from the service account key, so the project ID you enter has to be the same project the key belongs to. A key from a different project will validate as a credential and then find no dataset.

Caution

Keep the JSON key secure. It is a credential rather than a configuration value, and Google will not show it again after it is created.

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 JSON Key, Project ID, Dataset ID and Table Name.
3. Click Validate Credentials, then Finish.

The table name is typed rather than picked from a list, so it has to match BigQuery exactly.

Query path

1. Enter the JSON Key, Project ID and Dataset ID. No table name is asked for 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.

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

• Give the service account only the roles it needs and grant them on the dataset rather than the whole project.
• Prefer a view or a query with explicit column aliases over pointing at a raw table. It lets the warehouse team change the underlying model without breaking the connection.
• Use Preview Results and read the column names in the output, not just the row count.
• Check the project ID matches the project the service account key belongs to.
• 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.
• Rotate the service account key periodically and revalidate the connection afterwards.

Troubleshooting & FAQ

Validate Credentials fails. Check the service account holds both roles, that BigQuery is enabled on the project, and that the JSON key is complete and unmodified. A stray line break in the key will fail.

The credentials validate but the dataset cannot be found. The project ID belongs to a different project than the key, or the dataset ID is wrong.

The table name is rejected. It is typed rather than selected, so it has to match BigQuery exactly, including case.

The query previews correctly but nothing is delivered. The column names the query returns do not match the expected schema. Alias them in the SELECT to the names in the downloaded file format.

It was working and stopped. The key may have been rotated or revoked, or the service account may have lost access to the dataset.