Callrail to BigQuery: How to Move Your Data

Moving CallRail into BigQuery lets you check its attribution against your own spend. CallRail tells you which campaign a call came from, and whether the campaigns it credits are the ones your advertising platforms also claim is a question only a warehouse holding both can answer.

This guide covers the managed path with Airbyte. Two things shape the build: the connector covers a narrower slice of CallRail than the product does, and call records describe identifiable people in a way marketing reporting rarely needs.

Callrail to BigQuery at a glance:

Why move data from Callrail to BigQuery?

Two situations account for most of these pipelines.

The first is attribution you can verify. Every platform in a marketing stack reports favourably on itself, and calls are frequently the conversion that matters most for businesses where people ring rather than buy online. Setting CallRail's view against your ad platforms' own is the point of this.

The second is completing the funnel, since a call is where an online journey often ends and your other analytics stop. Volumes are modest, so this is a cheap pipeline whose value is almost entirely in the joins rather than in the call data by itself.

What do you need before you start?

Four things, and the last one is a conversation rather than a setting:

An account identifier, an API key and a start date. All three are required, and the key is created in CallRail's account settings. The CallRail source documentation lists the fields and the available streams.

Agreement about what the connector covers. Four core streams are available, which is less than the product offers, so check the list against what your analysis assumes before promising anything.

A BigQuery dataset in the right location. Location is fixed at creation and BigQuery will not join across locations, so put this wherever your advertising and web analytics data already sit.

A decision about caller details. These are phone numbers belonging to members of the public who rang a business, and almost no marketing report needs to see one.

If your network restricts traffic by IP, add the Airbyte Cloud IP addresses to the relevant allow list before you begin.

How do you build a Callrail to BigQuery pipeline in Airbyte?

Step 1: Check the stream list against your questions

Write down what people want to know, then read the four available streams and mark which questions they answer. Calls, companies, text messages and users cover a good deal, and they do not cover everything CallRail does. Finding the gap now costs a few minutes; finding it after somebody has designed a dashboard around form submissions costs considerably more.

Step 2: Configure the CallRail source

Click Sources in the left navigation, then New Source, and select CallRail, following adding a source. Supply the account identifier, API key and start date, all of which are required. Note which user created the key, since an API key generally carries that person's access and a departure can quietly end a pipeline.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project identifier, dataset and service account credentials. Call volumes are small by warehouse standards, so batched standard inserts are ample and Cloud Storage staging is unnecessary.

Step 4: Create the connection, then build the reporting view

Click Connections, then New connection, select your streams and a sync mode. Daily suits marketing reporting. Then build the view marketing will actually read, before anybody is given access to the underlying tables, for the reasons below.

Have that view filter on the extraction timestamp partition as well, since BigQuery bills on bytes scanned.

What does the connector actually cover?

Four core streams: calls, companies, text messages and users. That is a sensible core and it is narrower than the product, so anybody who has spent time in CallRail's interface will notice things missing that they think of as central to how the tool works.

The most consequential absence is the tracker configuration itself. CallRail works by assigning phone numbers to campaigns, and those assignments are what turn a ringing phone into an attributed lead. They do not arrive as a lookup table here, which means your attribution comes denormalised onto each call record rather than as something you can join to or audit separately.

In practice that is workable and worth understanding. The attribution fields on a call tell you what CallRail decided at the time, which is what you want for reporting, and it means you cannot easily answer questions about trackers that never received a call. If auditing your tracker setup matters, that part stays in CallRail's interface.

Who should be able to see caller details?

Almost nobody, and rather fewer people than will have dataset access by default. A call record identifies a member of the public by their phone number, often alongside their location and everything CallRail inferred about how they found you. That is personal data about someone who rang a business, not about a customer who signed anything.

The useful analysis needs none of it. Calls by campaign, cost per call, conversion rate by source and duration distributions are all counts and aggregates, and an analyst can produce every one without seeing a single number. The identifying detail is only needed by whoever is following up individual calls, which is a different job done in a different system.

Authorised views are the right tool here. Build a view exposing the aggregates and attribution fields without the caller identifiers, grant marketing access to that view rather than to the underlying dataset, and the reporting works exactly as intended while the raw records stay restricted. Agree a retention period too, because a warehouse keeps things indefinitely and nobody decided that these should be.

Frequently asked questions

Which streams are available?

Four core ones: calls, companies, text messages and users. Check that list against your questions before designing anything around parts of CallRail it does not cover.

Can I get my tracker configuration?

Not as its own stream. Attribution arrives on each call record instead, which serves reporting well and does not let you audit trackers that never received a call.

Should analysts see caller phone numbers?

No. Every useful marketing measure is an aggregate, so expose an authorised view without the identifiers and restrict the underlying dataset.

The pipeline stopped after a staff change.

An API key generally carries the access of the person who created it, so a key made by someone who has left is worth checking first. Note the owner when you set this up.

Can I do this without writing code?

The pipeline, yes. The authorised view marketing reads, and the join to your ad spend, are SQL and they are the reason for building this.

Get your Callrail data into BigQuery

Check the four available streams against the questions people asked, because the connector covers less than the product and the gap is easier to find now. Note who owns the API key. Put the dataset where your ad spend already lives, since the join is the entire point. Then build an authorised view carrying the attribution and none of the caller identifiers, and give marketing access to that rather than to the raw records.

Airbyte's connector catalog includes 600+ pre-built connectors, so calls can be judged against the spend that produced them. For the advertising data to join against, see Google Ads to BigQuery, and for product analytics into the same destination, Amplitude to BigQuery.

Start syncing now →