- Sources
- File & storage
Files - GCP
Overview
Section titled “Overview”Files - GCP collects files from a Google Cloud Storage bucket you control, so exports already landing in GCS can be sent to an advertising destination without being copied elsewhere.
It authenticates with a service account key rather than a key pair, which is the one substantial difference from the other bucket-based connectors.
Signals reads files from a location you control, on a schedule, and sends the rows to the destinations you have connected. Nothing is written back into your storage.
Supported destinations
Section titled “Supported destinations”Destinations supported by Files - GCP
| Category | Supported |
|---|---|
| Offline Conversions | |
| Lead Conversions | |
| Custom Audience |
Prerequisites
Section titled “Prerequisites”- A Google Cloud Storage bucket.
- The bucket name.
- A Google Cloud service account with read access to that bucket, and a JSON key generated for it.
- The relative path to the folder inside the bucket where the files are.
Authentication
Section titled “Authentication”In Studio, open Sources, find the Files category, and click the Files GCP tile.
Enter the bucket name and the service account key, then validate them. There are three fields here rather than the four the key-pair connectors use.
| Field | What it is | Where to find it |
|---|---|---|
| Authentication Name | Your own label for this set of credentials. | You choose it. Name it for the account or bucket it belongs to. |
| GCP Bucket Name | The name of the bucket, as it appears in the Google Cloud Storage console. | Google Cloud console, Cloud Storage, Buckets. |
| GCP Bucket JSON Key | The service account key that authorizes Datahash to read the bucket. It is generated in Google Cloud against a service account, and it is the whole credential. | Google Cloud console, IAM and Admin, Service Accounts, then Keys, Add key, Create new key, JSON. |
Grant the service account read access to that one bucket rather than a project-wide role. The key carries whatever the service account can do, so a narrow grant is the difference between a read-only credential and a broad one.
Configuration
Section titled “Configuration”Instance Setup
Section titled “Instance Setup”Select the Integration Type, which is the kind of data your files hold, and give the instance a name. Ten integration types are available: Offline Events, Audience, Meta CAPI CRM, Google Leads, TikTok Leads, Snapchat Leads, LinkedIn Leads, Store Sales, Local Product Inventory and Product Catalog. Offline Events is selected by default. For an audience you also choose the audience type.
Enter the File Name Format and the Relative Path to Data Folder, which is the prefix inside the bucket where the files are. Download the sample file for the integration type you selected, since it defines the exact column structure Signals expects, then click Finish.
Manage instance
Section titled “Manage instance”One instance reads one location for one integration type. To read another location, or to feed a different integration type, 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
Section titled “File format and schema”Start from the sample file you downloaded during setup rather than from an existing export. The column headers in it are what Signals matches on, so a header that has been renamed, reordered into a different case, or padded with a stray space will not be recognized, and the row it belongs to is dropped rather than reported.
The schema differs by integration type, not by storage provider. An offline events file and an audience file have different columns, and a file built for one will not work for the other. Within a schema, contact identifiers are typically accepted in more than one column, for example up to three email addresses and three phone numbers per person, with one value per cell rather than several separated by commas.
Data & identifiers
Section titled “Data & identifiers”Personal identifiers in your files are normalized and hashed before they are sent to a destination.
Best practices
Section titled “Best practices”- Use a dedicated folder for Datahash rather than pointing at one your team already writes to for other purposes.
- Keep a stable naming convention for the files you drop, so a failed run can be identified and replaced rather than guessed at.
- Clean the data at source: lowercase email, phone in E.164, no stray whitespace. Hashing a badly formatted value produces a hash that will never match.
- Grant the service account read access to the single bucket rather than a project-level role.
- Create the service account for Datahash alone, so its key can be rotated independently.
- Rotate credentials periodically and update the connection afterwards.
Troubleshooting & FAQ
Section titled “Troubleshooting & FAQ”Validate Credentials fails. Check the JSON key is complete and unmodified, and that its service account has read access to the named bucket. A truncated key or a stray line break will fail.
The bucket cannot be found. The bucket belongs to a different project than the service account, or the name is wrong.
The connection is set up but nothing arrives. Check the relative path points at the folder the files are actually in, and that a destination is connected in the same project.
The file is picked up but rows are rejected. The column headers do not match the sample file, or required values are missing. Compare your header row against the sample character for character.
Some rows land and others do not. The ones failing are missing a field the destination requires. That requirement comes from the destination, not from this connector.
It was working and stopped. Credentials were most likely rotated or revoked at the provider. Supply the new ones and revalidate.

