Skip to main content
Export your referral intelligence to a table in your own Google BigQuery. After every enrichment job, Clustr re-sends your workspace’s opportunities to the table (up to 50,000 rows) with an upsert, keeping your warehouse and BI tools current. It is a data export, not an OAuth app. You connect with a Google service-account key, and Clustr only ever writes to the one table it manages.
Connecting BigQuery is admin-only, under Integrations, Apps, BigQuery in the dashboard.

​
Connect BigQuery

Create a service account in Google Cloud, then run the three-step wizard.
1

Paste your service-account key

In Google Cloud, create a service account, grant it BigQuery Data Editor and BigQuery Job User, and download its JSON key (Service Accounts, Keys, Add key, JSON). Paste the whole JSON into Clustr and click Continue. Clustr reads the project from the key.
The JSON is a credential. Clustr stores it encrypted and uses it only to write the export table.
2

Pick a dataset

Use existing (pick a dataset Clustr found) or Create new. Click Continue.
3

Confirm and sync

Clustr checks <dataset>.clustr_referral_paths and either creates it or reuses it. Click Connect to save the connection and run the first full export.
After the initial sync, Clustr runs a sync at the end of every enrichment job. Each sync re-sends the opportunities (up to 50,000 rows) rather than only the ones that changed, and a sync already running is not started twice.

​
How It Works

Clustr writes a single table, <dataset>.clustr_referral_paths, one flat, denormalized row per opportunity. Rows are upserted on id with a MERGE, so re-syncing never duplicates, and a full sync also removes opportunities that no longer exist in Clustr. Because it is keyed and idempotent, the table is safe to query live, build views on, or point a BI dashboard at.

​
Settings

The BigQuery panel shows connection status and sync controls.

​
Table Schema

clustr_referral_paths is keyed on id (used for upserts); all other data fields are stored as STRING so the export never fails on type coercion. Full column reference:

​
Accounts and Connectors tables (optional)

Besides the warm intros, Clustr can export your Accounts and Connectors ledgers. Both are off by default. Turn them on in the connect form’s last step, or later under Integrations → BigQuery → Settings. Turning one on starts a sync straight away. They are written into the same dataset as the warm intros, by the same sync, with the same rules: every row is upserted on its key, and rows that left the ledger are removed after a complete sync. Turning a table off stops writing it; the table and its rows stay. All columns are text, like the warm-intros table.

​
Competitor monitoring tables (optional)

With competitor monitoring, Clustr can also export your competitors’ activity and the accounts they work. One switch writes both tables: Competitor monitoring, in the connect form’s last step or under Integrations → BigQuery → Settings. It is off by default, and turning it on starts a sync straight away. Both tables are written by every sync, including the one that follows each competitor scan, and each sync writes them whole: an interaction you ignore or a competitor you remove leaves them at the next sync. Turning the switch off stops writing them; the tables and their rows stay.
  • clustr_competitor_activity has one row per like or comment, as the Activity tab lists them. activity_id stays the same for the same interaction from one sync to the next. direction is outbound when their person engaged someone’s post, inbound when someone engaged their person’s post.
  • clustr_competitor_accounts has one row per account a competitor ever touched, and per company that buys from a competitor you watch (customer_only is true for those, with no interactions). standing is customer, crm or new, as the Account column reads.
  • has_open_deal, deal_stage and deal_name are the open deal in your CRM, the one the Accounts page shows.
  • Join either table to clustr_accounts on company_id, account_linkedin_id or clustr_account_id.

​
Renaming a table

Every table Clustr writes carries a marker in its clustr_table label (clustr:referral_paths, clustr:accounts, clustr:connectors, clustr:competitor_activity, clustr:competitor_accounts, as label values referral_paths, accounts, connectors, competitor_activity, competitor_accounts). If you rename a table in BigQuery, Clustr finds it by that marker and keeps writing to it under its new name. Keep the label if you copy or recreate the table.

​
Troubleshooting