Google Ads to Snowflake: How to Move Your Data

Moving Google Ads into Snowflake is how you form your own view of what advertising is worth. Google reports the conversions Google attributed to itself, which is not a criticism so much as a description of how attribution works, and joining spend to your own revenue data is the only way to check it.

This guide covers the managed path with Airbyte. Two things matter more than the configuration: getting a developer token is a prerequisite that can stall the project entirely, and Google's own retention policy caps how far back granular data goes, which makes your warehouse the only long-term record.

Google Ads to Snowflake at a glance:

Why move data from Google Ads to Snowflake?

Two situations account for most of these pipelines.

The first is return on ad spend measured on your terms. Joining campaign cost to your own revenue and retention data produces a number that belongs to you rather than to the platform, and lets you compare channels that each report differently in their own interfaces.

The second is history, and on this source it is unusually pressing. Google's data retention policy limits granular data to a fixed window, so a warehouse that has been accumulating for years holds detail the platform itself no longer will.

What do you need before you start?

The first item is a Google approval process rather than a setting, so begin it before anything else:

A developer token, which needs a Manager account. Standard Google Ads accounts cannot generate one, so you need a Google Ads Manager account first, and Google is selective about who receives a token. The Airbyte team has worked with Google to allowlist Airbyte, and the Google Ads source documentation explains what to say when you apply.

Awareness of your token's access level. Every developer token carries an access level and a permissible use. The access level governs whether you can work with production accounts and how many operations and requests you may run daily, so a low-tier token is a throughput constraint as well as a permissions one.

Your customer identifiers, and a login customer ID if relevant. Customer IDs are ten digit numbers without dashes, supplied as a comma-separated list. If your access runs through a Manager account, supply that account's login customer ID as well.

Snowflake objects and a role. A warehouse, database, schema and a role able to create tables in that schema. A dedicated role keeps credit consumption attributable, which is useful on a pipeline that re-reads recent data by design.

If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.

How do you build a Google Ads to Snowflake pipeline in Airbyte?

Step 1: Apply for the developer token

Create a Google Ads Manager account if you do not have one, then apply for a developer token explaining why you need it and that you will be using Airbyte. This is the long pole in the project and it involves waiting on Google, so start it on day one rather than after you have configured everything else.

Step 2: Configure the Google Ads source

Click Sources in the left navigation, then New Source, and select Google Ads, following adding a source. Sign in with Google to authenticate, or supply the client identifier, client secret and refresh token directly, then add the developer token, your customer identifiers, a start date and the conversion window.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role with your authentication method. Airbyte creates one table per stream with its own metadata columns alongside your data.

Step 4: Use a deduplicating sync mode

Click Connections, then New connection, select your streams and choose a deduplicating incremental sync mode on the report streams. The conversion window means recent days are deliberately re-read as conversions attribute retroactively, and deduplication is what stops that overlap becoming duplicate rows. Daily is the right cadence.

If a sync fails or behaves oddly once running, the companion piece on failing data integration between Google Ads and Snowflake covers diagnosis in more depth than this guide does.

Why does history stop at 37 months?

Because Google enforces it. Starting in connector version 6.0.0, report streams and custom queries using a date segment are limited to the 37 month granular data retention window set by the Google Ads Data Retention Policy, and the connector skips data older than that.

The behaviour follows sensibly from that. A start date more than 37 months ago is treated as 37 months ago instead, and if both your start and end dates fall outside the window the connector emits no records for that range at all. So an empty result for an old period is the policy working rather than a fault.

The consequence worth acting on concerns upgrades. If you already run this connector on version 5.x or earlier, you may hold data in Snowflake that Google will no longer serve, and an upgrade combined with a careless refresh could lose it. Read the migration guide first, because that history is now genuinely irreplaceable.

Why do recent numbers keep changing?

Because conversions are attributed retroactively. Somebody clicks an ad today and converts next week, and Google credits that conversion back to the original click. Yesterday's figures are therefore provisional, and the conversion window, which defaults to fourteen days, is how the connector accounts for that.

That means recent days are re-read on each sync and their numbers move. It is the same pattern as other advertising platforms, and it has the same implications: use a deduplicating sync mode so the overlap collapses, and reconcile against Google's own reporting on a date well outside the window rather than a recent one.

Set the window to match your business rather than accepting the default. If your customers typically convert within days, fourteen is generous. If your sales cycle is long, a wider window captures conversions the default would miss, at the cost of re-reading more data on every run.

Frequently asked questions

Why can I not generate a developer token?

Standard Google Ads accounts cannot. You need a Google Ads Manager account, and Google approves token applications selectively, so start that process early.

Why is my historical backfill returning nothing?

Granular data is limited to a 37 month retention window. A start date beyond that is treated as 37 months ago, and if both start and end fall outside the window no records are emitted for that range.

I am upgrading from version 5.x. What should I be careful about?

Preserving historical data already in your destination, since Google will no longer serve it. Read the migration guide before upgrading rather than after.

What should I set the conversion window to?

Something matching your sales cycle rather than the fourteen day default. Longer captures more late conversions and re-reads more data on every sync.

Can I do this without writing code?

Yes. The setup above is UI-driven, and the developer token is an application to Google rather than a development task. You will want Snowflake views joining spend to your revenue data.

Get your Google Ads data into Snowflake

Apply for the developer token first, because everything else waits on it. Match the conversion window to your sales cycle, use a deduplicating sync mode so the deliberate re-reads collapse, and treat the Snowflake copy as the long-term archive, since Google's granular history stops at 37 months and yours does not have to.

Airbyte's connector catalog includes 600+ pre-built connectors, so paid search can sit beside the other channels you compare it against. For paid social, see Facebook Ads to Snowflake, and for mobile attribution on the same customers, AppsFlyer to Databricks.

Start syncing now →