Skip to content

Cloudian

Signals collects files from Cloudian S3-compatible storage, so exports already landing in your Cloudian buckets can be sent to an advertising destination without being copied anywhere else.

Cloudian is usually deployed on your own infrastructure, which makes this connector different from the hosted bucket connectors in one important way: the endpoint is your infrastructure, and it has to be reachable from outside your network for Datahash to read it.

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.

  • A Cloudian deployment.
  • The endpoint URL for the bucket you are reading from.
  • The bucket name.
  • An access key and secret with read access to that bucket.
  • The storage endpoint reachable from the internet. Datahash connects inbound, so a server that only answers on your internal network will not work.

In Studio, open Sources, find the Files category, and click the Cloudian tile. The credentials go under Access Credentials.

FieldWhat it isWhere to find it
Authentication NameYour own label for this set of credentials.You choose it. Name it for the account or bucket it belongs to.
Endpoint URLThe S3-compatible API address for your storage. Required. For self-hosted storage this is your own server address.Shown against the bucket in your provider’s storage console. It is region specific.
Bucket NameThe name of the bucket holding your files. Required.Your provider’s storage console.
Bucket Access CredentialsThe access key Datahash reads as. Required.Created in your provider’s console when you generate a key pair.
Bucket SecretThe secret that pairs with that key. Required, and it is the secret half of the pair rather than a second copy of the key.Shown once alongside the access key. If it is lost, create a new pair.

The endpoint is the S3 address of your own Cloudian deployment, including the scheme and port. If it answers only on an internal network, the connection will fail regardless of the credentials.

Use a user with read access to the single bucket rather than an administrative account.

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 and the Relative Path to Data Folder, which is the folder 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.

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.

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.

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

  • Check the endpoint URL matches the address your storage actually answers on. A mismatched endpoint is the most common reason these connections fail, and the error it produces looks like a credential problem rather than an address problem.
  • 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.
  • Confirm the endpoint is reachable from the internet before troubleshooting the keys. On a self-hosted deployment this is the usual cause.
  • Use a read-only user scoped to the one bucket rather than an administrative account.
  • Rotate the key periodically and update the connection afterwards.

The credentials are rejected. Check the endpoint URL first, before the keys. Confirm the address is reachable from the internet and includes the right port and scheme.

The bucket cannot be found. The name is wrong, or the bucket sits behind a different endpoint than the one entered. Both have to point at the same place.

The connection times out rather than failing on credentials. That points at network reachability rather than authentication. Confirm the endpoint is exposed and the port is open.

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.

It was working and stopped. The key was most likely rotated or revoked at the provider. Supply the new one and reconnect.