What is log level data, and how do buyers get and use it?
Part of Supply path transparency
The short answer
Log level data is the event by event record a buying or selling platform keeps for each auction: one row per impression, click or conversion, with timestamps, IDs, the site, the exchange and the price. Buyers request it through their platform contract, then join DSP rows to SSP rows on shared auction and request IDs to see what really happened.
Key takeaways
- Log level data is one row per event, while dashboards and invoices are sums; only rows can be matched across companies.
- Joining a buyer's log to a seller's log needs a shared key, such as the auction ID in a win notice or the request ID in each SupplyChain node.
- A DSP's export can lack seller IDs and the full chain, so a supply path review needs the SSP side of the record too.
- Requests work best when they name the fields, the date range, the delivery method and the permission from each party in the chain.
- Privacy rules apply to the user fields in a log: regulators expect only the data a purpose needs, kept no longer than necessary.
What is log level data in programmatic advertising?
Definition
- Log level data (LLD)
- Records written by an ad platform for each individual event, such as a bid request, a win, an impression or a click, rather than totals by day, site or campaign.
Google's Display & Video 360 documentation gives a concrete picture. Its Data Transfer overview (opens in a new tab) (updated October 14, 2024) says the service "provides raw reporting data that can deliver analytics beyond standard reporting," with impression, click and Floodlight activity data "in a log level format." The ANA describes the same idea from the buyer's side: its benchmark is "built on log-level data from leading advertisers and platforms" and matched through TAG TrustNet, which the ANA's Q1 2026 release (opens in a new tab) calls the utility "for connecting and matching impression log-level data (LLD) at scale."
| File | What it holds | Delivery |
|---|---|---|
| Impression files | One row per impression, in a log level format | 24 times a day, one per hour |
| Click files | One row per click, joinable to the impression | 24 times a day, one per hour |
| Floodlight activity files | Conversion activity recorded by the advertiser's tags | Daily |
| Match table files | Lookup tables that, per Google, reduce the size of each event file | Daily |
| Storage window | Files sit in Google Cloud Storage for 60 days, then are deleted | Copy them before day 60 |
What data do you need to optimize a supply path beyond static files?
Seller files are a directory. The sellers.json specification (opens in a new tab) defines a seller by its seller_id, name, domain and seller_type, and ads.txt adds which accounts a site authorizes. None of those fields holds a count, a price or a timestamp, so a file match can say a route is allowed but not whether it carried any of the buyer's money. Supply path work that moves budget needs rows.
| Question | Seller files can answer | Log level data can answer |
|---|---|---|
| Is this account allowed to sell the site? | Yes, from ads.txt and sellers.json | Only indirectly, by the accounts that appear |
| Which route won this impression? | No | Yes, from the exchange ID and SupplyChain nodes on the row |
| What did the buyer pay, and what was the clearing price? | No | Yes, from cost fields and the win notice price |
| How much spend went to reseller routes for one site? | No | Yes, by summing rows by route |
| Did the same impression arrive twice through two exchanges? | No | Partly, by grouping rows that share a transaction ID |
| Is the file current? | Yes, by its fetch date and cache expiry | No |
The two sources work as a pair. Files define the allowed routes before money moves; logs show which routes the money took. The supply path optimization hub covers the file side, and the SupplyChain object covers the chain each request carries.
Which log fields reconcile seller and buyer counts?
A DSP and an SSP each log the same auction under their own IDs. To compare counts and prices row by row, both logs need at least one value they both saw. OpenRTB 2.6 and the SupplyChain specification define the candidates.
| Field | Defined as | Use in reconciliation |
|---|---|---|
| source.tid | "Transaction ID that must be common across all participants in this bid request," recommended in OpenRTB 2.6 | Groups copies of one impression offered through several exchanges |
| BidRequest.id and ${AUCTION_ID} | The bid request ID, passed back in the win notice macro | Joins the exchange's request log to the buyer's win record |
| schain node rid | "The OpenRTB RequestId of the request as issued by this seller" | Links each hop's request ID along a resold path |
| imp.id and ${AUCTION_IMP_ID} | The impression object's ID, returned when that impression wins | Separates several ad slots in one request |
| ${AUCTION_PRICE} | "Clearing price using the same currency and units as the bid" | Compares what the exchange cleared with what the DSP recorded as media cost |
| DV360 Auction ID | "A string used to join events among view/click/conversion types" | Joins events inside Google's files; Google says not to assume any structure in it |
| Event time | DV360 gives request time in microseconds and says it "is not guaranteed to be unique" | A filter for windows, never a join key on its own |
Rows from two companies do not all match, and the published record shows how much shared standards help. ISBA's 2023 summary (opens in a new tab) of its second UK supply chain study, run by PwC, reported that greater standardisation of data quality lifted the ad impression match rate to 58 percent, from 12 percent in the 2020 study, and named vendors supplying log level rather than aggregate data as a key factor. ISBA says the results are not representative of the wider market, and they are UK findings.
How do you request log level data?
Five steps for a log level data request
- Start with the buying platform. For DV360, Google's Reporting Data Transfer page (opens in a new tab) (updated September 18, 2024) says teams enroll "by contacting your sales or support representative," with delivery through Cloud Storage or BigQuery.
- Name the fields, not a report. List the join keys and cost fields you need, using the platform's field names, plus the date range and time zone.
- Get permission from each party. Sellers hold their own logs. ISBA's free financial audit toolkit (opens in a new tab) includes an Audit Permission Letter, described as the instrument "required to gather the multiple supply-chain permissions," with a data fields list and data principles (version 1.2, September 2024).
- Write access into the contract. Put the right to receive logs, the delivery schedule and the retention period in the DSP, agency and deal terms before the flight starts.
- Plan storage and timing. Google warns the files "are often very large" and DV360 deletes them from Cloud Storage after 60 days, so copy them on a schedule.
What a written log request should state
- The campaigns, line items or deal IDs covered, and the date range in UTC.
- Each field by its platform name, with the join key marked.
- The delivery method, format and file frequency.
- Which user level fields are excluded or hashed, and why the rest are needed.
- How long the recipient may keep the files and when they are deleted.
What privacy limits apply to log data?
Event rows can carry user IDs, IP derived locations and device details, so privacy law follows them. The California Privacy Protection Agency's Enforcement Advisory 2024-01 (opens in a new tab) calls data minimization "a foundational principle in the CCPA" and quotes the statute: collection, use, retention and sharing "shall be reasonably necessary and proportionate to achieve the purposes for which the personal information was collected or processed." In Canada, the OPC's guidelines on online behavioural advertising (opens in a new tab) list, among the conditions for opt out consent, that information is "destroyed as soon as possible or effectively de-identified."
Platforms build some limits into the files. Google's file format says its User ID is a tracking ID that "does not expose the user's browser cookie or mobile device ID," and that the field "may be zeroed out for privacy reasons," with a separate column giving the reason. For a supply path review, route, price, site and time answer the question without user fields. Leaving user fields out of the request is the simplest way to keep the file proportionate. The cookie syncing glossary page explains where those IDs come from.
What does a log level review look like on a real plan?
Fictional example
A home inspection company in Maryland, Delaware and Washington, DC
An unnamed home inspection company serving Baltimore, Wilmington and Washington, DC ran a curated deal on real estate, home buying and local news sites for the spring home buying season. The agency's supply path review had confirmed each site's sellers in ads.txt and sellers.json before launch, but the client asked how much spend went through reseller routes.
The agency asked the DSP for impression files with auction IDs, exchange IDs, URLs and cost fields, and asked the deal's SSP, under a signed permission letter, for rows with the same auction IDs, seller IDs and schain nodes. User IDs were left out of both requests. The joined file showed spend by route for each site, which the team set beside the deal sheet. No performance figures are implied.
Which selling records can PlacementGraph supply before logs exist?
Frequently asked questions
Is log level data the same as a delivery report?
No. A delivery report sums events by day, site or line item, so it cannot be matched against another company's records. Log level data keeps each event as its own row, with the IDs that let a buyer join it to an SSP's row for the same auction.
Can an advertiser get log level data without a DSP contract change?
Sometimes, since some platforms offer it as an enrolled service, such as DV360's Reporting Data Transfer through a sales or support representative. Seller side rows are different: they belong to the SSP, and reaching them takes the seller's permission. Putting log access in the contract avoids negotiating it after a flight.
How long should a buyer keep log files?
Privacy regulators in California and Canada tie retention to the purpose of collection. DV360 removes Data Transfer files from Cloud Storage after 60 days, so buyers copy what they need for a review. Those regulators expect retention to be proportionate and data to be destroyed or de-identified when it is no longer needed.
Why do DSP and SSP counts differ?
Each side counts at a different moment: a win notice is "not necessarily indicative of a delivered, viewed, or billable ad" in OpenRTB 2.6, while billing notices fire on each exchange's own policy. Masked URLs, missing IDs and time zone differences add more gaps.
Sources
- Data Transfer v2.0 overview (updated October 14, 2024) (opens in a new tab)Google for Developers, Display & Video 360
- Reporting Data Transfer (updated September 18, 2024) (opens in a new tab)Google for Developers, Display & Video 360
- Data Transfer file format (updated September 14, 2026) (opens in a new tab)Google for Developers, Campaign Manager 360
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab
- OpenRTB SupplyChain object (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
- ANA Programmatic Transparency Benchmark Reveals Widening Gap Between Top and Bottom Advertisers (May 27, 2026) (opens in a new tab)ANA
- Programmatic supply chain study summary (January 18, 2023) (opens in a new tab)ISBA
- Financial audit toolkit for programmatic advertising (opens in a new tab)ISBA and the Cross-industry Programmatic Taskforce
- Enforcement Advisory No. 2024-01: Applying Data Minimization to Consumer Requests (opens in a new tab)California Privacy Protection Agency
- Guidelines on privacy and online behavioural advertising (opens in a new tab)Office of the Privacy Commissioner of Canada
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.