Does Google Ad Manager Data Transfer work on free GAM or only GAM 360?

Data Transfer is a Google Ad Manager 360 feature only. It is not available on the free tier of GAM. If you are on free GAM and want event-level data, your options are limited to the standard UI reports and API. Upgrading to GAM 360 requires a commercial arrangement with Google; the threshold is roughly 90 million monthly impressions for US, Canada, Australia, and New Zealand publishers, and 150-200 million for other regions.

What is the difference between Impressions and BackfillImpressions files in Google Ad Manager Data Transfer?

Impressions files contain events served by direct and programmatic direct line items you control in GAM. BackfillImpressions files contain events served by AdSense and Ad Exchange demand that fills unsold inventory via the backfill mechanism. If your GAM setup uses AdSense or AdX as a backfill source, you need both files to capture your full impression volume. Counting only the Impressions file will undercount total delivered impressions. The same Backfill distinction applies to Clicks, CodeServes, ActiveViews, and VideoConversions files.

Why do my Google Ad Manager Data Transfer impression counts not match the GAM UI reports?

Google documents a roughly 1 percent discrepancy between Data Transfer files and the GAM UI, and that is normal. The discrepancy exists because the two systems use different processing pipelines and different cut-off points for late-arriving data. The more common cause of larger discrepancies is a pipeline issue on your side: partial files processed before delivery completes, DST-related file gaps (spring-forward days produce only 23 files instead of 24), or Backfill files excluded from the count. If your variance exceeds 2-3 percent consistently, check your pipeline before assuming the data is wrong.

Should I use BigQuery Data Transfer Service or build my own pipeline from Cloud Storage for Google Ad Manager data?

Use the BigQuery Data Transfer Service connector if you want an automated, low-maintenance pipeline and are comfortable with Google's table schema as-is. It handles scheduling and ingestion without custom code. Build your own pipeline from Cloud Storage if you need custom transformations before load, want to send data to a non-Google warehouse like Snowflake or Redshift, or need to merge Impressions and BackfillImpressions into a unified table before analysis. The native connector is faster to stand up. The custom path gives more control but requires a data engineer to maintain it.

How do I handle Daylight Saving Time gaps in Google Ad Manager Data Transfer file delivery?

Data Transfer file names use Pacific Time. When Pacific Time springs forward in March, one hour is skipped, so you receive 23 files instead of 24 for that calendar day. When it falls back in November, you receive 25 files. A pipeline that expects exactly 24 files will either error out or miss an hour of data. The fix is to process files by their actual delivery timestamps rather than expecting a fixed count per day, and to reconcile totals against the GAM UI for those two days each year.

Which Google Ad Manager Data Transfer fields are most useful for diagnosing floor price performance?

The two fields that matter for floor analysis are SellerReservePrice, which is the floor in effect at the time of the auction, and BidPrice from the BackfillBids file, which shows the price offered by each buyer. Comparing the BidPrice distribution to the SellerReservePrice for the same ad unit and time window tells you whether your floor is clearing most bids (floor too low), blocking a significant share (floor in the right zone), or blocking nearly everything (floor too high). The Impressions file alone does not surface losing bids, which is why BackfillBids is required for a proper floor audit.

Google Ad Manager Data Transfer Files: The Operator Guide

Google Ad Manager Data Transfer Service delivers raw impression-level log files to your storage every hour, plus full bid-level data via BigQuery integration. It's the only path to the data the GAM UI aggregates away: per-impression timestamps, all bid responses, win prices, latency timing, supply path data. Worth enabling for any GAM publisher running multi-network mediation, doing programmatic discrepancy analysis, or building reporting that the UI can't produce. Below the surface of "raw log files" is real complexity around timezones, partial deliveries, and field semantics that breaks naive processing.

Disambiguation up front: which "GAM" are we talking about

If you searched for "data transfer in GAM" you got results for Google Ad Manager and for Google Apps Manager (a CLI tool for managing Google Workspace). They're unrelated products. This article is about Google Ad Manager Data Transfer Files, the raw log delivery service for ad-tech reporting. If you're looking for the G Suite admin CLI, you want a different page.

When Data Transfer is worth enabling

The GAM UI gives you aggregated reports: revenue per network, eCPM by ad unit, fill rate by geo. For most publishers running AdMob and basic mediation, that's enough. The UI is fast, the reporting is good, and there's nothing on the table that justifies the operational overhead of raw log processing.

Data Transfer is worth enabling when:

You need bid-level data. The UI shows winning bids only. Data Transfer shows every bid that came in for every impression, including the ones that lost. This unlocks floor effectiveness analysis (are your floors filtering out cheap demand or cutting out high-CPM creatives?), bid landscape modeling, and competitive auction analysis.
You're running multi-network mediation in GAM. Per-network discrepancy investigation is impossible from the UI alone. You need the raw impression timestamps to match against your mediation partners' reporting and identify where the variance lives.
You're doing latency analysis. GAM ad serving timestamps in microseconds let you reconstruct page latency and identify bidder timeout problems. The UI averages this away.
You're building custom dashboards. Looker, Metabase, or any BI layer needs row-level data. Data Transfer plus BigQuery is the standard pipeline.
You need data older than the UI keeps. UI history retention is limited. Files in your storage are forever.
You're auditing supply chain integrity. Data Transfer includes seller chain data per impression. Worth real money if you're investigating where reseller fees are eating into your yield.

Below those use cases, Data Transfer is operational overhead without payoff. A small publisher running AdMob mediation and pulling weekly reports from the UI doesn't need it. A senior ad ops team running multi-SSP, header bidding, and direct deal infrastructure needs it before the team can do meaningful optimization work.

What's in the files (and what you actually use)

Two file types, delivered hourly to Cloud Storage or BigQuery:

Network Impressions files: every impression GAM served, with the winning line item, advertiser, creative, and price. Roughly 40 fields per row. The fields most operators actually use:

Time and EventTimeUsec2: impression timestamp. The Usec2 field is in microseconds. If you process it as seconds you'll be off by a factor of a million. Common bug.
LineItemId, OrderId, CreativeId: the line item that served and the creative shown
AdvertiserId: ranges across all advertisers in your account
Country, Region, Postal: geo at impression time
Device: browser/device fingerprint at impression time
RequestedAdUnitSizes and Width/Height: what was requested vs what served (relevant for adaptive banners)
AudienceSegmentIds: third-party segments active at impression time
EstimatedBackfillRevenue: when the impression was filled by an AdSense or AdMob backfill, this estimates the revenue
SellerReservePrice: your floor at the time of the auction
AdvertiserBidPrice: what won
BackfillBids: bid data from non-winning bidders in the same auction (this is the goldmine)

Bid Responses files (BigQuery only): every bid GAM received from every authorized buyer, even the bids that didn't win. This is what makes Data Transfer materially different from the UI. Not just the auction outcome, but the full bid landscape.

The BackfillBids field deserves attention. It contains the alternate bids GAM received during the auction. With this field, you can answer questions like "what would my revenue have been if I'd lowered my floor by 10 percent" or "which bidder is most often the runner-up and how close are they coming to winning." That's the kind of analysis that drives real yield optimization.

Processing pitfalls (the silent failures most teams hit)

Data Transfer files look like CSVs delivered hourly. The complications start when you process them at scale.

Microsecond timestamps

EventTimeUsec2 is in microseconds (1 second = 1,000,000 microseconds). The legacy Time field is in seconds. Mixing them produces timestamps off by 6 orders of magnitude. The bug is silent: your dashboard shows impressions clustering at 1970-01-01 because Unix epoch math went sideways. Sanity-check your timestamps after every parser change.

GAM delivers one file per hour in your account's reporting timezone. On daylight saving transitions you get 23 files (spring forward) or 25 files (fall back). If your loader assumes 24 files per day, your DST days will look incomplete or duplicate. Two days a year, this breaks reporting silently.

Partial files

If GAM hits a delivery error, files arrive partial and may be redelivered later (sometimes hours later, sometimes the next day). Your loader needs idempotent ingestion: same file path, you re-ingest, no duplicates. The naive "process every file we see" pattern doubles up rows on partial-redelivery days.

Backfill deduplication

When AdMob or AdSense fills GAM-eligible inventory via backfill, the impression appears in GAM Network Impressions with EstimatedBackfillRevenue. The same impression also appears in your AdMob or AdSense reporting. If you sum both sources, you double-count the backfill revenue. Your reporting needs explicit dedupe logic.

File naming and time semantics

File names use the format NetworkImpressions_<network_id>_<YYYYMMDD_HH>.... The hour in the filename is the START hour of the events in that file, in your account's reporting timezone. Not UTC. Most loaders confuse this and end up with timezone-mixed data.

Row-level errors

Some rows fail GAM's own validation and arrive truncated or with empty fields. Your loader should reject malformed rows to a quarantine table rather than fail the whole batch. Most teams discover this only after a week of "data looks weird" investigations.

Operator reporting use cases that the UI can't deliver

These are the analyses that justify the Data Transfer operational overhead.

Floor effectiveness

Compare SellerReservePrice against the distribution of BackfillBids. If most of your floors sit above the 75th percentile of received bids, you're filtering out viable demand. If they sit below the median, you're not protecting yield. The UI tells you neither. Data Transfer makes this analysis trivial after one query.

Bid landscape and runner-up tracking

For every impression, you have the winner and the alternates. Run a query that groups by LineItemId and counts how often each bidder is in the top 3 but doesn't win. The pattern tells you which networks are "almost there" and might benefit from a floor tweak or higher mediation priority.

Discrepancy diagnosis

Mediation reporting from your AppLovin or Unity setup shows their numbers. GAM Data Transfer shows what GAM saw on the impression. When the two disagree by more than 5 percent, the diagnostic path runs through impression timestamps, line item IDs, and the EstimatedBackfillRevenue field. The UI hides the data you need for this.

Latency proxy via CodeServes

The time delta between request received and impression served is hidden in the UI. Data Transfer exposes the timestamps you need to compute it per impression. Identify which ad units have the worst tail latency (P99) and you've found the placements where bidder timeout is killing fill.

Supply path audit

The seller chain data per impression lets you trace which authorized resellers ended up in the path and what their take was. This is where Beamflow-style supply chain audits start. Data Transfer is the data feed.

How to set up Data Transfer

The official enable flow is straightforward but easy to misconfigure. Quick operator version:

Confirm GAM 360 or Manage Inventory access. Standard GAM doesn't have Data Transfer. You need the paid tier or an MCM Parent relationship that grants access.
Enable Data Transfer in GAM Admin. Specify what files you want delivered (Network Impressions, Network Backfill Impressions, Network Requests, Network Code Serves) and how (Cloud Storage bucket or BigQuery dataset).
Set the report timezone correctly. This determines the time semantics of all your files. Match your reporting timezone or you'll spend the next year converting timestamps in every query.
Set up the BigQuery transfer service if you're using BigQuery. The setup is in Cloud Console, not GAM. The dataset name pattern is critical for downstream tooling.
Enable the optional fields you actually need. BackfillBids is the big one. Without it, half of the analysis use cases above are impossible.
Test ingestion in a sandbox before wiring production reporting. First-time DST transitions and partial-file scenarios will surface within the first month.
Verify field schema versions. GAM updates the schema occasionally and adds fields. Your loader needs to handle additions gracefully.

The lead time from enable to clean data flowing into your reporting stack is typically 1-2 weeks for a small team, longer if you're integrating with multiple downstream consumers.

When the UI is enough

Data Transfer is operational overhead. Don't enable it just because it's available. Skip it if:

You're running AdMob alone or AdMob plus one mediation network with simple waterfall logic
Your team doesn't have a data engineer or someone fluent in SQL/BigQuery
Your reporting needs are summary-level (revenue by week, eCPM by network) and the UI delivers them
You're not running multi-bidder header bidding or in-app bidding with discrepancy concerns

The UI is well-designed and serves most publishers fine. Data Transfer is the next layer for senior teams. If you don't have the next-layer questions, don't add the next-layer cost.

Frequently asked questions

Do I need Google Ad Manager 360 to use Data Transfer?

Yes. Data Transfer is a paid feature in GAM 360 and is also available to Manage Inventory child publishers when their MCM Parent has it enabled. Standard GAM (the free tier) does not include Data Transfer Service. If you're a publisher operating under MCM, your Parent account controls whether you get Data Transfer access.

What's the difference between Network Impressions and Bid Responses files?

Network Impressions files contain one row per ad impression GAM served, with the winning line item and creative. Bid Responses files (BigQuery only) contain every bid GAM received from authorized buyers, including bids that didn't win. Network Impressions tells you what happened. Bid Responses tells you what could have happened. The two together give you the full auction landscape.

How long does GAM keep the files?

Files delivered to your storage stay there permanently. You own them. GAM's own retention only covers the UI reporting layer (typically 30 to 60 days for detailed views). Once you've enabled Data Transfer, your storage is the source of truth for historical impression data.

Can I use Data Transfer without BigQuery?

Yes. Files deliver to Google Cloud Storage by default. You can process them with any tool that reads from Cloud Storage: Spark, Snowflake's external tables, Redshift COPY commands, or simple Python scripts. BigQuery integration is the most direct path because it's pre-configured for the file schema, but it's not required.

What's the latency from impression to file delivery?

Files for a given hour typically arrive 1 to 3 hours after the hour ends. You won't get real-time data. For real-time monitoring you need a different approach (Pub/Sub, custom webhook from your wrapper). Data Transfer is for analytical workloads, not operational alerting.

How do I match GAM Data Transfer with mediation network reporting?

The match is at the impression timestamp plus line item plus creative ID. Mediation networks (AdMob, AppLovin MAX) report by their own internal IDs. The mapping is your responsibility. Most teams build a translation layer that takes the network's report, joins on line item or ad unit, and reconciles against GAM's Data Transfer rows. Discrepancies of 1 to 3 percent are normal. Anything above 5 percent is worth investigating.

What to do this week

If you're considering enabling Data Transfer:

Confirm GAM 360 or Manage Inventory access. Without it, this isn't an option.
Identify the specific operator question that justifies the overhead. "Better data" isn't enough. "I need to diagnose a 7 percent revenue discrepancy with my header bidding wrapper" is.
If the use case warrants it, enable in a sandbox first. Set the timezone correctly the first time. Get a colleague to review the schema before you wire production downstream consumers.
Build idempotent ingestion from day one. Partial files and DST transitions will hit you eventually.
Start with one or two analyses (floor effectiveness or discrepancy diagnosis are the highest-ROI starting points). Don't try to consume every field on day one.
Plan for ongoing maintenance. GAM occasionally updates the schema. Your loader needs to handle additions.

If you're already running Data Transfer and the analysis layer isn't producing actionable insight yet, the issue is usually the analysis pipeline, not the data feed. The fields are rich. Most teams don't extract enough value because the queries weren't designed by someone who understood both the GAM data model and the operator questions worth asking.

If you're trying to figure out whether Data Transfer fits your specific GAM setup or how to extract more from a setup you already have, book a 30-minute call. I'll look at your current reporting and tell you whether Data Transfer would pay back the operational cost based on your actual stack and what questions you're not yet able to answer.