InfoSum
Deliver audience and customer data to an InfoSum data bunker for privacy-preserving data collaboration and clean-room activation. Zeotap normalizes identifiers per InfoSum’s specification, serializes each batch as a UTF-8 CSV file, PGP-encrypts the CSV with the InfoSum-provided public key, and drops the .csv.pgp file into your GCS bucket — InfoSum’s bunker then pulls, decrypts, and ingests the file inside its secure environment. Raw customer data never leaves your control.
Prerequisites
Before creating an InfoSum destination in Zeotap, collect the following from your InfoSum and GCS administrators:
- A Google Cloud Storage bucket that the InfoSum bunker is configured to read from
- The bucket name and the folder (path prefix) that InfoSum watches
- A GCP service account JSON key with write access to that bucket
- The InfoSum PGP public key provided by your InfoSum representative (ASCII-armored)
- An InfoSum bunker already provisioned in your workspace
Authentication
Zeotap authenticates to the GCS bucket using a service account JSON key.
- In Google Cloud IAM, create or reuse a service account with Storage Object Creator permission on the bucket.
- Download the service account JSON key.
- Paste the full JSON into the Service Account JSON Key field when configuring the destination.
The service account only needs write access to the agreed folder; InfoSum will decrypt and read the files from inside its bunker using the matching PGP private key.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Bucket | text | Yes | Name of the GCS bucket the InfoSum bunker reads from |
| Folder | text | Yes | Folder path (prefix) inside the bucket where Zeotap drops CSV files, e.g. zeotap/audiences/ |
| InfoSum PGP Public Key | textarea (secret) | Yes | ASCII-armored PGP public key provided by InfoSum; every file is encrypted with this key before upload |
Target Settings
| Field | Type | Required | Description |
|---|---|---|---|
| File Format | select | Yes | InfoSum requires UTF-8 CSV with a header row and comma column delimiter. This is the only supported option. |
Supported Operations
Sync Modes
| Mode | Supported | Description |
|---|---|---|
| Insert | Yes | Write each batch as a new .csv.pgp file |
| Mirror | Yes | Write the full dataset snapshot as a single .csv.pgp file |
| Upsert | — | Not applicable — InfoSum ingests immutable files |
| Update | — | Not applicable — InfoSum has no row-level update API |
Audience Sync Modes
| Mode | Supported | Description |
|---|---|---|
| Add | Yes | Append the current audience snapshot as a new file |
| Mirror | Yes | Replace the audience with a full snapshot |
| Remove | — | Not applicable — InfoSum does not expose a membership-removal endpoint |
| Upsert | — | Not applicable for file-based delivery |
Features
| Feature | Supported |
|---|---|
| Field Mapping | No |
| Schema Introspection | No |
Data Format
Each sync batch is written as a UTF-8 CSV that conforms to InfoSum’s ingestion requirements:
- Header row — column names are taken from the first row of the batch and sorted alphabetically for deterministic output
- Column delimiter — comma (
,) - Multi-value delimiter — pipe (
|) inside a single cell (must be configured on the InfoSum side to match) - Identifier normalization — Zeotap lowercases and trims every value in recognized identifier columns:
email,email_address,hashed_email,email_sha256,phone,phone_number,mobile,mobile_number,home_phone,aaid,idfa,mobile_id,advertising_id,cookie_id,zip,zip_code,zip5,zip9,postal_code,ip,ip_address,ipv4,ipv6. Phone numbers additionally have all whitespace stripped so E.164 values stay contiguous. IP addresses are parsed and re-emitted in their canonical lowercase form. - Raw identifiers preferred — InfoSum recommends sending raw, unhashed identifiers; the bunker performs hashing and salting internally. Sending a
hashed_emailcolumn is also supported.
Supported Identifiers
| Identifier | Formats InfoSum accepts |
|---|---|
| Raw, SHA-256 | |
| Phone | E.164 (home and mobile) |
| Mobile ID | AAID (Android), IDFA (iOS) |
| Postal Code | ZIP5, ZIP9 |
| Cookie ID | String |
| IP Address | IPv4, IPv6 |
How It Works
- Normalize — Zeotap lowercases and trims values in recognized identifier columns per InfoSum’s specification.
- Serialize — Rows are written as a UTF-8 CSV with a header row.
- Encrypt — The CSV is encrypted with the configured InfoSum PGP public key, producing an ASCII-armored PGP message.
- Upload — The file is uploaded to the configured bucket at
<folder>/<YYYY-MM-DD>/infosum_<mode>_<timestamp>.csv.pgp. - Ingest — The InfoSum bunker picks up the file, decrypts it with its matching private key, and ingests the rows inside the bunker’s secure environment.
Each sync batch produces exactly one encrypted file. The sync mode (insert, mirror, or add) is embedded in the file name so that the bunker operator can distinguish incremental adds from full snapshots.
Rate Limits
Google Cloud Storage supports ~1,000 writes per second per object prefix, well above typical sync volumes. There is no InfoSum-side rate limit on file drops — the bunker ingests at its own cadence (typically every few minutes).
Individual objects are limited to 5 TiB by GCS, far above any realistic audience export.
Best Practices
- Send raw identifiers whenever possible — InfoSum performs hashing and salting internally, and raw data produces the highest match rate.
- Lowercase all key columns before the sync if you are pre-processing; Zeotap will also lowercase known identifier columns defensively.
- Use mirror mode for audience syncs so the bunker always has a complete, up-to-date view of membership.
- Coordinate the folder path with your InfoSum representative — the bunker is configured to watch a specific prefix, and files dropped elsewhere in the bucket will be ignored.
- Rotate the GCS service account key periodically; update the JSON in Zeotap when you rotate.
- Keep the PGP public key up to date — if InfoSum rotates the bunker’s key pair, update the InfoSum PGP Public Key field before the next sync or decryption will fail on their side.
Troubleshooting
Connection test fails with “cannot access bucket”
The service account either doesn’t exist in the target project or lacks permission on the bucket. Grant the service account at least the Storage Object Viewer role on the bucket (Storage Object Creator is required at sync time).
Connection test fails with “invalid pgp public key”
The value pasted into InfoSum PGP Public Key is not a valid ASCII-armored PGP key. Re-request the key from InfoSum and paste the full block including the -----BEGIN PGP PUBLIC KEY BLOCK----- / -----END PGP PUBLIC KEY BLOCK----- markers.
Connection test warns “pgp key has no encryption-capable subkey”
The provided PGP key has no subkey marked for encryption. Ask InfoSum to issue an encryption-capable key (most OpenPGP tools generate one by default).
Sync succeeds but InfoSum reports no data ingested
Verify the Folder path exactly matches the prefix the bunker is configured to watch. A common mistake is a missing or extra trailing slash — both audiences and audiences/ produce the same GCS path so either is fine on Zeotap’s side, but InfoSum may require the exact form.
Records rejected by InfoSum
InfoSum normalizes values on ingest and rejects rows with malformed identifiers. Check that phone numbers are in E.164 format, postal codes are 5 or 9 digits, and that no identifier column contains empty or whitespace-only values.
Upload fails with “permission denied”
The service account does not have Storage Object Creator on the bucket at the moment of upload. Either grant the role directly or add the service account to a group that holds it.