Google Ads to MySQL: How to Move Your Data

Moving Google Ads into MySQL makes sense for one purpose: putting campaign figures where an application can read them quickly. A client dashboard or an internal tool wants yesterday's spend for a particular campaign in milliseconds, which is a lookup rather than an analysis.

This guide covers the managed path with Airbyte. Two things shape the build: advertising reports are larger than this destination is comfortable with unless you choose carefully, and the figures you load keep changing after you load them.

Google Ads to MySQL at a glance:

Why move data from Google Ads to MySQL?

One situation genuinely suits this, and it is worth being clear about the other.

The good case is serving an application. An agency portal showing each client their campaign performance, or an internal tool that displays spend alongside other operational data, needs fast lookups against a modest, well-chosen slice. MySQL does that cheaply and sits beside whatever else the application already reads.

The poor case is analysis, which is the more common reason people reach for an advertising pipeline. Cohort comparisons, multi-year trends and keyword-level exploration are aggregation problems across a lot of rows, and guidance for this destination is around ten gigabytes. If that is your intention, Google Ads to BigQuery will serve you far better and cost less effort than fighting a row limit.

What do you need before you start?

Four things, and the first has a queue attached while the second decides viability:

A developer token, which Google approves. Requested from a Manager account and reviewed rather than issued on demand, so start it early. The Google Ads source documentation covers the request and the OAuth credentials alongside it.

A volume estimate for the streams you want. Campaign-level daily figures are small. Keyword-level or search-term-level figures across many accounts are not, and the difference between those two decisions is the difference between a comfortable database and an unhappy one.

Customer identifiers, and a login customer ID where relevant. Reaching accounts through a manager requires that extra field, and omitting it produces an access error that reads like a permissions problem.

A MySQL database and a view layer plan. The destination adds metadata columns, and report field names flatten into columns that can approach the 64-character identifier limit. Applications should read views rather than tables.

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

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

Step 1: Choose the grain before you choose anything else

Decide what the application actually displays, then take only the streams that support it. Campaign-level daily performance for a handful of accounts is a small table that MySQL will serve happily for years. The same data at keyword level, or across fifty client accounts, is a different proposition entirely. This is the decision that determines whether this pairing works, and it is easier to make now than after the disk fills.

Step 2: Configure the Google Ads source

Click Sources in the left navigation, then New Source, and select Google Ads, following adding a source. Supply the developer token, OAuth credentials, customer identifiers, start date and conversion window, plus the login customer ID if you reach accounts through a manager. Keep the start date modest, since an application rarely needs three years of history.

Step 3: Configure the MySQL destination

Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. Give this its own database rather than mixing advertising tables into an application schema, because the naming and the metadata columns are not what an application developer expects to find.

Step 4: Create the connection and index what the application reads

Click Connections, then New connection, select your streams and a sync mode. Daily is right, since attribution settles over weeks. Then add indexes on whatever the application filters by, usually campaign identifier and date, because a lookup-serving table without them is just a slow table.

Watch total size over the first month against the ten gigabyte guidance, because advertising data grows steadily rather than suddenly and nobody notices until it matters.

Which part of Google Ads actually fits here?

The structure and the summaries, not the detail. Campaigns, ad groups and ads describe your account and amount to very little data. Report streams carry the performance figures and multiply by every dimension you include, so the same period can be a few thousand rows or a few hundred million depending entirely on the grain you asked for.

That multiplication is what makes this pairing risky rather than wrong. An agency syncing campaign-level daily figures for twenty clients has a table measured in megabytes. The same agency syncing search term performance has one measured in tens of gigabytes within a year, which is past the point where MySQL is the sensible choice and past the point where anybody wants to migrate.

So let the application define the grain rather than taking everything available in case somebody wants it. If an analyst later asks for keyword-level history, that is a second pipeline into a warehouse rather than an argument for widening this one. Keeping the two separate is much easier than untangling a database that was asked to serve both.

What happens to figures that keep changing after you load them?

They get rewritten, which an application reading them needs to expect. The conversion window defaults to fourteen days, so conversions continue being credited to earlier clicks for a fortnight, and each sync updates rows you already loaded. Yesterday's number is provisional, and so is the number from ten days ago.

For an analytical destination that is unremarkable, because analysts understand attribution. For an application it is more awkward, since a client looking at a portal on Tuesday and again on Friday sees different figures for the same day and reasonably asks which one is right. Both are, and nothing in the table says so.

Two things make that manageable. Expose an as-at indication in the view your application reads, even just the date the figures were last refreshed, so the interface can say when a number was current. And decide whether recent days should be labelled provisional in the interface itself, which is a product decision rather than a data one but is far easier to make now than after the first client query about it.

Frequently asked questions

Is MySQL a sensible destination for advertising data?

For serving a modest, well-chosen slice to an application, yes. For analysis across years or at keyword level, no, and a warehouse will cost you less trouble.

Why is my table growing so quickly?

Almost certainly the grain of your report streams. Every dimension multiplies the row count, so keyword or search term level produces orders of magnitude more than campaign level.

Why do figures change after they have loaded?

The conversion window, fourteen days by default. Conversions keep being credited to earlier clicks, so recent rows are updated on each sync rather than staying fixed.

I get an access error but permissions look correct.

Check whether a login customer ID is needed, which it is when reaching accounts through a manager. Its absence looks exactly like a permissions failure.

Can I do this without writing code?

The pipeline, yes. The views your application reads and the indexes supporting them are SQL, and both are what make this a serving layer rather than a copy.

Get your Google Ads data into MySQL

Be honest about what this pairing is for, because it serves an application well and analyses badly. Choose the grain from what the interface displays, request the developer token early since Google reviews it, and index what the application filters by. Then expose an as-at date in your views, because the conversion window keeps rewriting recent figures and a client comparing Tuesday against Friday deserves an explanation rather than a mystery.

Airbyte's connector catalog includes 600+ pre-built connectors, so campaign figures can reach the products that display them. For the same source into a column store, see Google Ads to ClickHouse, and for another advertising platform into the same destination, Facebook Marketing to MySQL.

Start syncing now →