Facebook Marketing to MySQL: How to Move Your Data
Move Facebook Marketing into MySQL with Airbyte. Why the lookback window re-reads data on purpose, why deduplication is essential, and marking days provisional.
Moving Facebook Marketing into MySQL puts advertising data where an application or an internal tool can query it. A client reporting portal, an agency dashboard or a budget tracker that needs campaign spend is far simpler to build against a database it already connects to than against Meta's API.
One naming note first, because it catches people searching the catalogue: the connector is called Facebook Marketing rather than Facebook Ads or Meta. This guide covers the managed path, and a behaviour that makes rows arrive more than once on purpose.
Facebook Marketing to MySQL at a glance:
Why move data from Facebook Marketing to MySQL?
Two situations account for most of these pipelines, and neither is deep analytics.
The first is powering a reporting application. An agency portal showing clients their campaign performance, or an internal budget tool, reads from a database it already connects to rather than calling Meta's API on every page load and managing rate limits of its own.
The second is joining ad spend to relational data you already hold, such as client records or budgets. If you want multi-year attribution analysis across many accounts, a warehouse is the better destination for reasons of volume.
What do you need before you start?
Two credentials items and two settings that shape what the numbers mean:
An access token and your ad account ID. The account ID is the numeric identifier from Ads Manager, and depending on connector version the field may want it with or without its prefix, so read the label. The Facebook Marketing source documentation covers the setup.
A deliberate start date. Optional, and leaving it blank replicates all data. On a relational destination with a volume guideline that matters more than it would on a warehouse, so set it to what your application actually displays.
Your Facebook attribution window. Meta allows click-through attribution of up to 28 days, with view-through limited to one day. If you have set a custom attribution window in your account, the connector's lookback window should match it rather than being left at its default.
A MySQL user with write access. On the target schema, ideally one dedicated to synced data. Airbyte adds its own metadata columns, so plan to expose views to your application rather than the raw tables.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the MySQL side before you begin.
How do you build a Facebook Marketing to MySQL pipeline in Airbyte?
Step 1: Check your attribution settings in Meta
Ask whoever runs your Meta account what attribution window is configured, because the connector's lookback should match it. This is a five-minute conversation that determines whether your conversion numbers settle correctly, and it is much easier than reconciling a discrepancy later.
Step 2: Configure the Facebook Marketing source
Click Sources in the left navigation, then New Source, and select Facebook Marketing, following adding a source. Supply the access token, account ID, start date and the lookback window from step 1. Set the time increment deliberately, because switching between time increment settings later triggers a full re-sync.
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. Watch identifier lengths, since MySQL allows 64 characters and the flattened names from Meta's nested insight structures can run long.
Step 4: Use a deduplicating sync mode
Click Connections, then New connection, select your streams and choose incremental append and deduped as the sync mode on the insights streams. That is not a preference on this connector, it is how you handle the deliberate re-reading described below. Daily is the right cadence.
If you manage several ad accounts, no extra configuration is needed for timezones. Where multiple accounts in different timezones are synced within one connection, each account's date range is computed independently from its own timezone setting.
Why does the same row arrive more than once?
Because it is meant to. The connector uses a lookback window to repeatedly read data from the last several days during an incremental sync, which means some data is synced twice or more despite the cursor value being up to date. That is not a fault, it is how updated conversion figures reach you.
Meta attributes conversions retroactively within the attribution window, so a campaign's numbers for last Tuesday are still moving several days later. A pipeline that read each day once and never returned would capture the first version of every figure and none of the corrections.
On a destination feeding an application this matters more than it would on a warehouse. Without deduplication your portal shows a client their spend counted several times over, which is the kind of error that damages trust rather than merely a dashboard. Deduplication collapses the overlap on the way in, which is why the sync mode above is stated as a requirement.
What changes when an application reads the result?
Mostly how you explain moving numbers. A dashboard analyst expects recent figures to firm up; a client looking at a portal does not, and will ask why yesterday's spend changed overnight. That is attribution doing its job, and your interface should say so rather than leaving people to guess.
A practical approach is to mark recent days as provisional in whatever your application displays, using the lookback window as the boundary. Figures older than that have settled and can be presented plainly; anything inside it is still moving and saying so costs you nothing.
Expose views rather than raw tables too. That hides Airbyte's metadata columns, gives your application a stable interface when Meta changes a field, and is the natural place to apply the provisional marking so every consumer treats it the same way.
Frequently asked questions
Which connector do I use for Facebook Ads?
It is listed as Facebook Marketing in the catalogue. Searching for Facebook Ads or Meta may not find it.
Why is the same row appearing multiple times?
By design. The lookback window makes the connector re-read recent days so updated conversion data is captured. Use a deduplicating sync mode, which on this destination is essential rather than optional.
Why did yesterday's spend change overnight?
Meta attributes conversions retroactively, so recent figures keep moving within the attribution window. Mark those days provisional in your application rather than presenting them as final.
Do I need separate connections for ad accounts in different timezones?
No. Each account's date range is computed independently from its own timezone setting, and no configuration is required for it.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. You will want MySQL views hiding the metadata columns and marking recent days as provisional.
Get your Facebook Marketing data into MySQL
Match the lookback window to your Meta attribution setting, use a deduplicating sync mode because an application double counting spend is worse than a dashboard doing it, keep the start date tight given the volume guidance, and mark recent days provisional so nobody is surprised when they move.
Airbyte's connector catalog includes 600+ pre-built connectors, so paid media can reach an application and a warehouse at once. For the analytical version, see Facebook Ads to Snowflake, and for paid search alongside it, Google Ads to Snowflake.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.