Why does my Google Ads transfer show different revenue numbers than the Ads UI for the last two or three days?

This is expected connector behavior, not a bug. Google Ads attribution and conversion data gets revised for a trailing window after the fact as more conversion data rolls in, so a transfer that only pulls new days without re-processing recent history will show numbers that later diverge from the (also-updating) Ads UI. Most Ads transfer configs are set to auto re-process a trailing window specifically to account for this.

What's the minimum schedule interval for a BigQuery Data Transfer Service connector?

It varies by connector, not a single platform-wide minimum. Google Ads, for instance, can't usefully run more than once a day for most report types since the underlying data doesn't refresh faster than that; file-based Cloud Storage/S3 transfers can run considerably more frequently, down to a period measured in hours in this example config. Check the specific connector's documented minimum before assuming a tighter schedule is even honored.

Are credentials like access_key_id for an S3 transfer stored securely?

They're stored by the Data Transfer Service backend, encrypted at rest, and not something this builder or its output exposes beyond what you typed in. Treat any example or template containing a credential field as a placeholder to replace, never check a real access key into source control just because it's sitting in a JSON config file alongside non-sensitive settings.

GCP BigQuery Data Transfer Builder

MonitoringGCP

Build BigQuery Data Transfer configurations for Google Ads, Cloud Storage, and S3 imports with scheduling.

BigQuery Data Transfer Service Configuration

Build BigQuery Data Transfer configurations for Google Ads, Cloud Storage, S3, and other data source imports with scheduling.

Required Fields

displayNamedataSourceIddestinationDatasetIdschedule

{
  "displayName": "Google Ads Daily Import",
  "dataSourceId": "google_ads",
  "destinationDatasetId": "marketing_data",
  "params": {
    "customer_id": "123-456-7890",
    "include_pmax": "true"
  },
  "schedule": "every day 04:00",
  "scheduleOptions": {
    "disableAutoScheduling": false,
    "startTime": "2026-03-15T04:00:00Z"
  },
  "notificationPubsubTopic": "projects/my-project/topics/bq-transfer-notifications",
  "emailPreferences": {
    "enableFailureEmail": true
  },
  "serviceAccountName": "bq-transfer@my-project.iam.gserviceaccount.com",
  "additionalTransfers": [
    {
      "displayName": "Cloud Storage CSV Import",
      "dataSourceId": "google_cloud_storage",
      "destinationDatasetId": "raw_imports",
      "params": {
        "data_path_template": "gs://my-data-bucket/exports/*.csv",
        "destination_table_name_template": "csv_import_{run_time|'%Y%m%d'}",
        "file_format": "CSV",
        "skip_leading_rows": "1",
        "write_disposition": "APPEND",
        "max_bad_records": "10"
      },
      "schedule": "every 6 hours"
    },
    {
      "displayName": "Amazon S3 Import",
      "dataSourceId": "amazon_s3",
      "destinationDatasetId": "cross_cloud_data",
      "params": {
        "data_path": "s3://partner-data-bucket/daily/",
        "destination_table_name_template": "s3_import_{run_time|'%Y%m%d'}",
        "access_key_id": "<REDACTED>",
        "file_format": "JSON"
      },
      "schedule": "every day 02:00"
    }
  ]
}

Generated Output

Output will appear here...

About This Tool

Build BigQuery Data Transfer Service configurations across connector types (Google Ads, Cloud Storage, Amazon S3, and others), each with a distinct params schema and its own minimum schedule interval, refresh window, and auth model. Google Ads transfers can automatically re-process a trailing window of recent days to pick up attribution/conversion data that Google Ads itself revises after the fact, while file-based transfers (Cloud Storage, S3) use write_disposition and max_bad_records the same way a batch load job does, since under the hood these connectors are essentially managed, scheduled load jobs rather than a live streaming pipeline.

Real-World Scenario

A marketing analytics team notices their BigQuery-based Google Ads revenue dashboard consistently undercounts the most recent two to three days compared to the native Ads UI, and initially suspects a bug in the downstream dbt transformation. After ruling that out, they trace it to the transfer's re-processing window being too short to capture Google Ads' own late conversion attribution updates. They use the builder to review the params block, extend the trailing re-processing window the connector re-pulls on each run, and after the next scheduled run, the dashboard's trailing few days start matching the Ads UI within the normal small reconciliation variance instead of consistently under-reporting.

When to Use This Tool

•Setting write_disposition to APPEND with a destination_table_name_template keyed on run_time for a recurring CSV import, so each scheduled run lands in its own dated table rather than overwriting or blindly accumulating in one table.
•Debugging a Google Ads transfer showing revenue numbers that don't match the Ads UI for the last few days, which is often not a bug, Google Ads data gets revised for a trailing window and the transfer needs to re-pull that window, not just append new days.
•Tuning max_bad_records upward temporarily while debugging a malformed upstream CSV export, then back down once the source data quality issue is fixed, so future bad rows fail loudly instead of being silently dropped.
•Choosing between a data_path (single object) and a data_path_template with wildcards for a Cloud Storage transfer, depending on whether the source produces one file per run or a batch of files matching a naming pattern.

Pro Tips

TIP

A file-based transfer's max_bad_records silently drops malformed rows up to that count rather than failing the whole load, a generous max_bad_records value can mask a real, growing data quality problem in the source system for weeks before anyone notices missing rows downstream.

TIP

Google Ads (and similar ad-platform) transfers need their trailing re-processing window tuned to match how far back that platform revises attribution data, too short a window means permanently-stale numbers for the most recent few days, not a one-time discrepancy that resolves itself.

TIP

Mixing multiple additionalTransfers with very different schedule cadences into one conceptual 'daily pipeline' can create confusing partial-data states downstream if consumers assume all sources refresh together, document each transfer's actual cadence explicitly rather than assuming uniformity.

How It Works Under the Hood

The builder requires displayName, dataSourceId, destinationDatasetId, and schedule to resolve, the fields common to every Data Transfer Service connector regardless of source type; the params block's actual required fields differ per dataSourceId (Google Ads needs a customer_id, S3 needs access credentials and a path), and the builder validates the JSON is well-formed but can't enforce which params a specific connector actually requires.

Frequently Asked Questions

Why does my Google Ads transfer show different revenue numbers than the Ads UI for the last two or three days?: This is expected connector behavior, not a bug. Google Ads attribution and conversion data gets revised for a trailing window after the fact as more conversion data rolls in, so a transfer that only pulls new days without re-processing recent history will show numbers that later diverge from the (also-updating) Ads UI. Most Ads transfer configs are set to auto re-process a trailing window specifically to account for this.
What's the minimum schedule interval for a BigQuery Data Transfer Service connector?: It varies by connector, not a single platform-wide minimum. Google Ads, for instance, can't usefully run more than once a day for most report types since the underlying data doesn't refresh faster than that; file-based Cloud Storage/S3 transfers can run considerably more frequently, down to a period measured in hours in this example config. Check the specific connector's documented minimum before assuming a tighter schedule is even honored.
Are credentials like access_key_id for an S3 transfer stored securely?: They're stored by the Data Transfer Service backend, encrypted at rest, and not something this builder or its output exposes beyond what you typed in. Treat any example or template containing a credential field as a placeholder to replace, never check a real access key into source control just because it's sitting in a JSON config file alongside non-sensitive settings.

Related Learning Guides

Firestore Data Modeling26 min read
Cost Optimization Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.