DV360 (Display & Video 360) does not have a single "export to BigQuery" button.
The data lives in three separate systems - entity metadata, event-level performance data, and aggregated report data - and each one has a different path to BigQuery.
Engineers building DV360 data pipelines often hit problems because they expect one mechanism to cover everything. Here is how all three paths work and how they fit together.
The three data paths
1. DV360 API BigQuery Connector (entity metadata)
The DV360 API BigQuery Connector is a BigQuery Data Transfer Service integration that pulls resource and configuration data from the Display & Video 360 API directly into BigQuery.
What it transfers:
- Advertisers, campaigns, insertion orders, line items
- Creatives, targeting settings, audiences
- Any entity-level configuration available through the Display & Video 360 API
What it does not transfer:
- Impression, click, or conversion event data
- Performance metrics of any kind
The connector runs on a regular schedule and updates BigQuery tables with the latest resource states. It is free to use - standard BigQuery storage and query pricing applies.
Use this when you need: campaign structure, creative metadata, targeting configuration, or any entity attribute that is not a performance metric.
2. Reporting Data Transfer (event-level performance data)
Reporting Data Transfer provides event-level impression, click, and conversion data for DV360 and Campaign Manager 360.
Key characteristics:
- Event-level granularity: individual impressions and clicks, not aggregated totals
- Delivery cadence: hourly CSV files for impressions and clicks; daily CSV files for conversions (activities)
- Delivery destination: Google Cloud Storage (as CSV), with an optional automatic import into BigQuery via the BigQuery Data Transfer Service for Campaign Manager 360 data
- Data retention: data can be stored beyond DV360's two-year platform retention limit
- Gated access: you must enroll by contacting your Google sales or support representative - this is not self-serve
What it enables:
- Custom aggregations not available through standard DV360 reporting
- Joining impression-level data with first-party data or other BigQuery sources
- Long-term data storage beyond platform limits
Use this when you need: granular event-level analysis, custom breakdowns, joining impression data with first-party data in BigQuery (including Ads Data Hub workflows), or data retention beyond platform limits.
3. Bid Manager API (aggregated report generation)
The Bid Manager API (distinct from the Display & Video 360 API) handles programmatic generation of aggregated performance reports.
When the DV360 UI runs a report, it is using the Bid Manager API under the hood. You can replicate this programmatically: submit a report job, poll until it completes, then download the resulting CSV.
Key characteristics:
- Returns aggregated metrics (impressions, clicks, spend, conversions) by dimensions you specify
- Does not provide event-level data - that is Reporting Data Transfer
- Output is a CSV report, not a direct BigQuery load
- The Display & Video 360 API explicitly does not include performance metrics - the Bid Manager API is the correct tool for this
Use this when you need: scheduled aggregated performance reports, custom dimension combinations, or report automation without event-level granularity.
How to combine them
The power of having all three is the ability to join them in BigQuery:
| Need | Tool |
|---|---|
| Entity metadata (campaign structure, creatives, targeting) | DV360 API BigQuery Connector |
| Event-level impressions and clicks | Reporting Data Transfer → Cloud Storage → BigQuery |
| Aggregated performance metrics by custom dimensions | Bid Manager API → CSV → BigQuery |
| First-party data join with impression data | Reporting Data Transfer + Ads Data Hub UPDM |
A complete DV360 analytics layer typically uses the BigQuery Connector for entity metadata and Reporting Data Transfer for event-level data, then joins them in BigQuery to produce reporting tables that combine "what was the creative?" with "how did it perform at the impression level?"
What breaks in practice
Expecting a single connector to do everything. The BigQuery Connector gives you entity configuration. The Reporting Data Transfer gives you event-level performance. Neither gives you both. Engineers who expect one tool to cover the other discover the gap when they cannot find impressions or clicks in the connector's output.
Reporting Data Transfer requires enrollment. This is one of the most common surprises. Unlike many GCP integrations that are self-serve, Reporting Data Transfer requires contacting Google directly. Build this lead time into your project timeline.
Report table naming in Reporting Data Transfer. DV360 creates report landing tables in BigQuery with date-suffixed names. Three report types (display traffic, YouTube traffic, reach) arrive independently with different column schemas. A pipeline that detects and processes new tables as they arrive needs to handle all three schemas - and handle the case where a new table type arrives unexpectedly.
DV360 entity hierarchy ordering. The campaign entity hierarchy has strict parent-child dependencies: Advertiser → Campaign → Insertion Order → Line Item → Creative. When delivering metadata to a downstream system, parent entities must arrive before child entities. Flattening the hierarchy and sending everything in one batch causes foreign key violations downstream.
Conversion window mismatch. DV360 conversions are reported in daily files, not hourly. If you join hourly impression data with daily conversion data on date, the date boundaries need to align - and timezone handling needs to be consistent across both.
Pipeline engineering notes
For production DV360 pipelines that cover all three data paths:
- The BigQuery Connector is the simplest: configure it in the GCP Console and it runs automatically.
- Reporting Data Transfer to Cloud Storage needs a separate ingestion step to parse CSV files and load them into BigQuery tables with consistent schemas.
- Bid Manager API reports require an async workflow: submit the job, poll for completion, download, parse, load.
- All three produce data that benefits from a normalization layer before it reaches a dashboard - field names, date formats, and grain assumptions differ between them.
For Ads Data Hub workflows that join DV360 impression data with first-party data, Reporting Data Transfer is the prerequisite: the ADH tables (like adh.google_ads_impressions) are sourced from the same event-level data that Reporting Data Transfer makes available.
Related
- Building a Reliable DV360 and Ads Data Hub Pipeline with BigQuery, Cloud Run, and AWS SQS - the architecture for a production pipeline using all three data paths with event-driven triggers and cross-cloud delivery.
- DV360 & Ads Data Hub Data Pipeline case study
If you are building a DV360 data pipeline and trying to figure out which data path covers your use case, or if you are running into the schema and ordering problems above, I can help scope and build it.