Database connectors are easy to reason about. A row is inserted, change data capture picks it up, the row lands once and the Monthly Active Rows (MAR) meter ticks once. Marketing connectors do not work like that, and teams who assume they do get two unpleasant surprises: numbers in the warehouse that quietly change after the fact, and a bill that is several times larger than the row counts in their dashboards suggest.
The cause is the same in both cases. Ad platforms report performance against a conversion attribution window. A click today can be credited with a conversion that happens 30 days from now, and the platform retroactively rewrites the metrics for that click's original date. To stay correct, Fivetran must re-read a rolling window of history on every sync - so yesterday's rows are not finished changing, and the same ad-day-campaign row can be an "active row" many times over.
This tutorial covers how to configure Google Ads, Meta (Facebook) Ads, LinkedIn Ads and GA4 in Fivetran so that the marketing warehouse is both accurate and predictable, and when to skip Fivetran for a source entirely.
1. The three settings that decide everything
Across the ad connectors, three configuration choices dominate cost and correctness:
| Setting | What it controls | Cost impact |
|---|---|---|
| Conversion / attribution window | How many days of history are re-read each sync | Linear - a 30-day window re-reads ~30x more rows than a 1-day window |
| Report or table selection | Which pre-aggregated reports Fivetran requests | Very high - each report is its own grain and its own row count |
| Sync frequency | How often the rolling window is re-read | High when combined with a long window |
The interaction is what bites. A 30-day conversion window on hourly syncs is not 30x the cost of a 1-day daily sync - it re-reads a month of history 24 times a day. Marketing data is reported daily by the platforms; hourly syncs of a daily-grain report buy you almost nothing except MAR.
Start here: daily syncs, a conversion window that matches what the marketing team actually reports on (usually 7 or 30 days), and the smallest set of reports that answers their questions.
2. Google Ads: pick your report tables deliberately
The Google Ads connector is built on the Google Ads Query Language API, and Fivetran exposes it in two ways.
Standard schema tables. Campaign, ad group, ad, keyword and their daily stats tables. Predictable, well modelled, and enough for most reporting.
Custom reports. You define a set of fields, segments and metrics, and Fivetran materialises it as its own table. This is where costs are made or broken, because row count is a product of the segments you choose. A campaign-level daily report for 200 campaigns is 200 rows a day. Add segments.device (x4), segments.ad_network_type (x5) and segments.geo_target_region (x50) and the same report is 200,000 rows a day - before any conversion-window re-read.
Practical rules:
- One report per question, not one report with every segment "in case someone asks".
- Never segment by geography or keyword at the same grain as device unless a person has explicitly asked for that cross-tab.
- Manager (MCK) accounts: select only the child accounts that are actually live. Agencies commonly sync a hundred dormant accounts for years.
- Check
customer.idis in every custom report. Reports without it are effectively unusable in a multi-account warehouse.
Metrics in Google Ads are already aggregated by the API, so you cannot re-derive a different segmentation later in dbt. That is the real reason to think about segments up front: it is a schema decision, not just a cost decision.
3. Meta Ads: the breakdown trap and the 28-day window
Meta's Insights API has the same shape of problem and a sharper edge: breakdowns. Fivetran's Meta connector lets you define custom insights tables with breakdown dimensions (age, gender, placement, country, publisher platform, device). Row counts multiply exactly as they do with Google segments, and Meta will not let you combine some breakdowns with others at all - so a single "do everything" table is not even possible.
The defaults to review:
- Attribution window. Meta's default reporting window is 7-day click / 1-day view; historical re-reads typically run 28 days. If finance reports on a 7-day window, do not sync 28.
- Prebuilt vs custom insights. The connector ships prebuilt insights tables (by account, campaign, ad set, ad). Use these first. Add a custom table only when a breakdown is genuinely required.
- Action tables.
ad_insights_actionsand friends are long-format tables with one row per action type per ad per day. They are usually the single largest table in the schema. Sync them only if conversion-type detail is used downstream. - Currency. Meta reports in each ad account's currency. If you run multi-currency accounts, plan a conversion table now; it is far more painful to retrofit once dashboards exist.
4. GA4: this is the one where Fivetran may not be the answer
GA4 is the most common mistake in a marketing stack build. There are three ways to get GA4 data into a warehouse, and they are not equivalent.
A. GA4's native BigQuery export. Free from Google, event-level, daily or streaming. This is the only option that gives raw events, which is what you need for session stitching, funnel analysis or user-level attribution. If the destination is BigQuery, use it. No Fivetran MAR is consumed.
B. Fivetran's GA4 connector (Data API). Pre-aggregated reports, defined by dimension and metric sets, subject to the Data API's cardinality limits and sampling behaviour. Useful when the destination is not BigQuery, when you want GA4 aggregates sitting alongside ad spend in Snowflake or Databricks, or when you need pre-GA4-export history.
C. Both. Common and defensible: events to BigQuery for analysis, a small set of Fivetran-synced GA4 reports in the main warehouse so marketing dashboards match the GA4 UI.
One caveat that generates support tickets: GA4 Data API reports will not always reconcile with the BigQuery export or the GA4 UI. Thresholding, sampling, consent-mode modelling and different attribution models all cause variance. Decide once which number is the number of record, write it down, and stop investigating differences below the agreed tolerance.
If you are choosing a destination as part of this work, our notes on Fivetran to BigQuery cover the partitioning and cost controls that matter when GA4's export lands next to Fivetran tables in the same project.
5. Modelling the rolling window without lying to your dashboards
Because the last N days keep changing, a marketing warehouse needs an explicit rule for what is final.
A workable pattern:
- Land raw report tables as Fivetran writes them, keyed on
(account_id, date, entity_id, segments...). Fivetran upserts in place - you always see the latest platform truth. - Build a
fct_ad_performancemodel that unions platforms onto a common grain (date, account, campaign, spend, impressions, clicks, conversions, revenue). - Add an
is_finalflag:date < current_date - interval '<conversion window> days'. - Make dashboards default to final data, with an explicit "including provisional last N days" toggle. Marketing wants recent numbers; finance wants numbers that do not move.
- If anyone needs to know what a metric said last week versus today, that is a snapshot requirement, and Fivetran History Mode or a dbt snapshot on the derived model is the mechanism - not a bug report.
That last point is worth being blunt about with stakeholders. "Last month's spend changed" is almost never a pipeline failure. It is attribution working as designed.
6. Keeping the MAR bill honest
Ad connectors are the most common cause of a surprise Fivetran invoice, because their row counts are driven by configuration rather than by business volume. A short audit, run quarterly:
- Rank tables by MAR using the Fivetran Platform Connector's usage tables, not by intuition. It is almost always one action or breakdown table.
- Check every custom report's segments against a real dashboard. Delete reports nobody queries; they still cost full MAR.
- Match conversion windows to reporting practice, per connector, and re-check after any change in how marketing reports conversions.
- Drop dormant ad accounts from the connector's account selection.
- Reduce sync frequency on daily-grain reports to daily or twice daily. This is usually the single largest, least controversial saving.
- Watch for re-sync events. A full historical re-sync of a segmented ad report can cost more than a month of normal syncing. Before triggering one, confirm that a targeted re-sync of the affected table will not do.
If you want this instrumented rather than audited by hand, the approach in Fivetran Pipeline Observability gives you per-connector MAR and freshness alerting, and our wider guidance on connection-level MAR pricing explains how these rows are counted in the first place.
7. API deprecations: the maintenance tax nobody budgets
Ad platform APIs version aggressively. Google Ads API versions are deprecated on a published schedule; Meta's Marketing API retires versions roughly annually; LinkedIn and TikTok change field availability with little notice. Fivetran handles the upgrades, but the schema consequences land on you: renamed fields, removed metrics, new columns appearing mid-quarter.
Two defences, both cheap:
- Set your connector's schema change handling deliberately rather than leaving it on the default, and subscribe someone to the change notifications. The mechanics are in our schema drift playbook.
- Put dbt tests on the columns your dashboards depend on -
not_nullon spend,uniqueon the report grain, an accepted-range test on cost per click. A silently removed metric becomes a failed test rather than a board slide with a zero on it.
Where to start
If you are standing up a marketing warehouse this quarter: one platform at a time, prebuilt tables before custom reports, daily syncs, a conversion window copied from what marketing actually reports, GA4's native export if you are on BigQuery, and an is_final flag in the model layer from day one. Add segmentation when someone asks for it and can say what decision it changes.
If you already have a marketing stack and a MAR number that nobody can explain, the audit in section 6 usually finds the answer in under an hour.
SyncSpur works on exactly this kind of configuration - connector selection, report design, MAR reduction and the dbt layer above it. If your ad spend reporting is expensive, inconsistent with the platform UIs, or both, get in touch and we will take a look at the actual connector config.