Deal delivery reconciliation: proving a deal ran on its intended sites
Part of Curated deals and PMPs
The short answer
Deal delivery reconciliation proves that a private or curated deal served on the sites its approved list named. Join the buyer's deal and site report to the list version in force each day, add the seller's log with deal ID and page URL, sort each domain as matched, off list or unknown, and report actions.
Key takeaways
- The proof is a join of three records: the deal ID, the approved list version with its dates, and a domain level delivery report.
- Buyer reports show the site a deal ran on; seller logs can add the page URL, but only if access is agreed with the seller.
- Off list delivery on a deal is contained in the buying platform first and explained by the seller second.
- Unknown locations stay unresolved in the report; they are not counted as compliant delivery.
What evidence shows a deal delivered on its intended sites?
A claim that a deal ran on its approved sites rests on three records joined together. The first identifies the deal on both sides. The second is the approved list, in the version that applied on each day of the flight. The third is a delivery record that names the site for each impression or each day of impressions. If any one is missing, the claim cannot be checked.
| Record | What it holds | Where it comes from | What it cannot prove alone |
|---|---|---|---|
| Deal identity | The buyer platform's deal ID and the seller's own deal ID | The buying platform and the seller's confirmation | Which sites the deal reached |
| Approved list version | Domains, version number, approver and effective dates | The buyer's list record | That the seller loaded that version |
| Domain level delivery | Impressions by deal and site, or by deal and page | Buyer reports and, where agreed, seller logs | Why a domain outside the list appeared |
Deal identity needs care because one deal has two IDs. Display & Video 360's report dimensions (opens in a new tab) define Inventory Source ID as "The Display & Video 360 identifier for a deal" and Inventory Source ID (External) as "The seller's (i.e. a publisher or exchange) identifier for a deal used in their systems." Put both on the report so the seller can search its own systems with the number it knows.
Which logs show the domains a deal served on?
On the buyer side, the core record is a report grouped by deal and site. Display & Video 360 defines App/URL as "The name of a site, or mobile app" and Inventory Source as "The name of the deal that supplies buyable impressions to your line items," and it reports "Unknown or Unpermissioned Inventory Source" when deal information is missing. Run the report by day so each row can be matched to the list version in force that day.
On the seller side, the evidence can go down to the page. Google Ad Manager's Data Transfer fields (opens in a new tab) include DealId, the "ID of the Ad Exchange (AdX) or Ad Manager deal that applied for this impression," and RefererURL, "The URL of the page that requested and that displayed the ad." Google's fields by file type (opens in a new tab) page lists both in the Impressions and Backfill Impressions files and warns that "A small number of duplicated records is expected," so deduplicate before counting.
| Source | Field that names the location | Deal field | Access |
|---|---|---|---|
| Buying platform report | App/URL | Inventory Source and both Inventory Source IDs | Buyer runs it |
| Seller impression log | RefererURL (page) and Domain | DealId | Seller shares an extract, if agreed |
| Bid request record | site.domain and site.page | deal.id, returned as bid.dealid | Buyer's bidder logs, where kept |
Public documentation does not entitle a buyer to a seller's logs. Write the request into the deal terms before launch: which fields, which date range, which time zone and how soon after each week. The domain matching rules, such as how subdomains and app delivery are treated, are set out in the served domain reconciliation guide; agree them with the seller too, so both sides sort domains the same way.
What should happen when a deal serves on sites outside its list?
Off list delivery on a deal has a short list of documented causes. Display & Video 360's inventory source page (opens in a new tab) notes that video inventory belongs to a player that "may be embedded on more than one website," that "reporting will show the actual site where impression was served," and that buyers can use website targeting to restrict delivery. Its website targeting page (opens in a new tab) adds that ads on targeted content "may show in that app, even if you haven't specifically targeted it." A seller may also have loaded an older or wider domain list than the one approved.
Handling an off list domain on a live deal
- Confirm it is outside the list. Apply the agreed matching rules and the list version for that day before calling it off list.
- Contain it on the buyer side. Display & Video 360 channels (opens in a new tab) can be blocked, and a blocked channel applies automatically across the partner or advertiser where it was set.
- Send the seller the evidence. Give both deal IDs, the domain, dates and impression counts, and ask which cause applies.
- Record the seller's answer. An embedded player, a stale list on the seller side and an unexplained domain each need a different fix.
- Agree the remedy. Correct the seller's setup, and settle any credit or makegood under the deal's own terms.
- Recheck the next week. The domain should be gone from the following week's report.
How do you reconcile seller and buyer counts for a deal?
Counts will not match exactly, because each system records a different event; the impression discrepancies guide explains why. For placement proof, the question is narrower: do both sides see the same domains, in roughly the same proportions? Google's reporting discrepancies page (opens in a new tab) gives the setup rules: "Ensure the date ranges are exactly the same in both reports," "Verify that both reports are set to the same time zone," and "Always compare data from generated reports."
Before comparing seller and buyer domain counts on a deal
- Both reports cover the same dates, in the same time zone.
- Both are filtered to the same deal, identified by both IDs.
- The seller's log has been deduplicated.
- Domains on both sides were reduced to the same form under the agreed matching rules.
- Recent days that are still preliminary are left out or marked.
- Each domain appears on both sides, or its absence on one side is noted.
A domain that appears in the seller's log and not the buyer's report, or the reverse, matters more than a gap in totals. It suggests that one side is grouping or naming sites differently, and it is the first thing to raise with the seller.
How should deal delivery reconciliation be reported?
Keep the report short and repeatable, with the same layout each week so trends show. The client needs to see the share of delivery on matched domains, the off list and unknown lines, and what was done about each.
| Section | Contents |
|---|---|
| Header | Deal name, both deal IDs, exchange, date range, time zone and list version with its effective dates |
| Matched domains | Each approved domain that delivered, with impressions from the buyer report and, if available, the seller log |
| Off list domains | Each domain outside the list, its impressions, the seller's explanation and the containment date |
| Unknown locations | Impressions with no site or no inventory source, kept as unresolved |
| Approved but silent | Listed domains with no delivery, passed to list maintenance |
| Actions | Open items with an owner and a due date |
Silent approved domains are not a reconciliation failure, but they belong on the report because they shrink the deal. Pass them to the curated deal maintenance review so they are checked for lost authorization or lost supply.
How does PlacementGraph give a deal a fixed list to reconcile against?
What does a deal delivery reconciliation look like on a real flight?
Fictional example
A home warranty company's deal in Spokane and Coeur d'Alene
A fictional home warranty company runs a curated private auction in Spokane, Washington and Coeur d'Alene, Idaho, beside home ownership, local news and household budget content, with display and online video, in English. The approved list is version 2, with 35 sites (a fictional count), and the deal terms ask the seller for a weekly impression log extract with deal ID, page URL and domain, in Pacific time.
In week one the buyer report by deal and site shows 33 approved domains delivering, two approved domains silent, and three domains outside the list. One is a subdomain of a listed news site, which the agreed matching rules count as matched. One is a recipe site that embeds a listed publisher's video player. The third has no explanation yet.
The trader blocks the recipe site and the unexplained domain with a blocking channel, sends both deal IDs and the counts to the seller, and asks for a cause. The seller confirms the embedded player and finds the third domain came from an older list loaded at setup. It reloads version 2, and the next week's report shows no off list domains. The two silent sites go to the list review.
Frequently asked questions
Who should run the reconciliation, the buyer or the seller?
The buyer, because the buyer holds the approved list and answers to the client. The seller supplies its log extract and explanations. Agree in the deal terms who sends what and when, so the first week's reconciliation does not wait on a request nobody made.
Is page level evidence needed, or is the domain enough?
For a deal built from a site list, the domain answers the question the client asked: did the deal run on approved sites. Page URLs add proof when the list approved only some sections of a site, or when off list delivery needs explaining. Ask for them where the seller can share them.
What if the seller cannot share any logs?
Reconcile on the buyer report alone and say so in the header. The domain level report still shows matched, off list and unknown delivery, but without the seller's view you cannot confirm the counts from both sides. Note the limit for the client and raise log access at the next renewal.
Should off list impressions be removed from the invoice?
That depends on the deal's terms, so read them before the flight starts. The reconciliation supplies the evidence: domain, dates, impressions and the seller's explanation. Whether that leads to a credit, a makegood or no change is a commercial question for the buyer and seller.
Sources
- Dimensions in reports (opens in a new tab)Google Display & Video 360 Help
- Explore Data Transfer fields (opens in a new tab)Google Ad Manager Help
- View Data Transfer fields by file type (opens in a new tab)Google Ad Manager Help
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab
- Add an inventory source to Display & Video 360 (opens in a new tab)Google Display & Video 360 Help
- App, channel, and website targeting (opens in a new tab)Google Display & Video 360 Help
- Channels (opens in a new tab)Google Display & Video 360 Help
- Reporting discrepancies (opens in a new tab)Google Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.