Served domain reconciliation: matching the approved list to where ads ran
Part of Programmatic media planning
The short answer
Served domain reconciliation compares the domains a plan approved with the domains that actually received impressions, using log level files or placement reports from the buying platform. The analyst reduces each served URL to a comparable domain, matches it against the approved list version, then sorts the leftovers into URL variants, related app delivery, masked URLs and off list delivery.
Key takeaways
- Reconcile against the exact list version that was approved and uploaded, not the latest copy in a shared folder.
- A bid request field describes an offer; the buying platform's served record is stronger evidence of where an impression landed.
- Write URL matching rules for www, subdomain and path variants before looking at the data.
- Rule out related app inventory, inherited settings and masked URLs before treating a domain as off list.
What is required to reconcile planned domains with served domains?
Definition
- Served domain reconciliation
- A post launch comparison of the domains on an approved inclusion list with the domains recorded as serving the campaign, ending in a classified list of matches, explained differences and unexplained delivery.
Reconciliation fails quietly when the inputs are loose. Compare delivery with a spreadsheet edited after upload, and each hand edit looks like off list delivery or a missing site. Freeze the inputs with dates first, then open the delivery data. The planning side is covered in the programmatic media planning hub; this page starts where the upload ends.
Inputs to freeze before reconciliation starts
- The approved list version number, its approval date and the export file that was uploaded, with the domain count stated in the file.
- The list as the buying platform holds it: in Display & Video 360, the Download composite list option under Apps & URLs targeting returns the targeted apps, URLs, collections and channels for the line item.
- The delivery data for a stated date range: log level impression files or a placement report broken out by domain, exchange and inventory source.
- The event history (opens in a new tab) for the same range, downloaded as CSV with Include system changes switched on, so settings that changed mid flight are visible.
- The matching rules for subdomains, paths and app inventory, written down and agreed before anyone reads the results.
- A dated snapshot of the ads.txt file for each domain that needs a seller check later.
Which logs show the served domain?
Several records carry a domain or URL, and they prove different things. The OpenRTB bid request describes inventory before any bid. The buying platform's impression log and reports record what it bought. Read each field in its own documentation before treating it as the served domain.
| Field | What the documentation says | Limit for reconciliation |
|---|---|---|
| OpenRTB site.domain | "Domain of the site" in the OpenRTB 2.6 Site object (opens in a new tab) | Declared by the seller in the request; it describes an offer, not a rendered ad |
| OpenRTB site.page | "URL of the page where the impression will be shown" | Written in the future tense, before the auction; may be absent or truncated by the seller |
| Data Transfer DV360 URL | "The raw URL taken from the bid request received from the exchange" (Data Transfer file format (opens in a new tab)) | Some exchanges mask it, and the value then reads source_url_hidden |
| Data Transfer Referrer URL | "Contains the URL on which the ad appeared, when possible" | Google adds that it "may also be empty, or return ad server URLs" |
| DV360 report App/URL | "The name of a site, or mobile app" (dimensions in reports (opens in a new tab)) | Aggregated by site or app, so it names the property, not each page |
| DV360 report Inventory source | "The name of the deal that supplies buyable impressions to your line items" | Shows an Unknown or Unpermissioned Inventory Source label when the source is not available |
Log level files do not wait. Google's Data Transfer v2.0 overview (opens in a new tab) says impression and click files are delivered 24 times a day, one for each hour, and stay in Google Cloud Storage for 60 days. A team reconciling at the end of a long flight copies the files out as they arrive, or the first weeks are gone. DV360 fields populate only when advertisers are linked and permissions are granted.
How do you treat subdomains and URL variants?
A served URL such as HTTPS://Recipes.Example.com:443/fall/ and a planned entry such as example.com may be the same publisher. The rules for deciding come from the URI standard, the buying platform's targeting rules and the ads.txt definition of a root domain. Apply them to both lists and keep the original URL beside the normalized one.
| Variant | Rule | Source |
|---|---|---|
| Upper case scheme or host | Lowercase both; "the scheme and host are case-insensitive and therefore should be normalized to lowercase" | RFC 3986, section 6.2.2.1 (opens in a new tab) |
| Default port or empty path | Drop :80 or :443 and treat an empty path as "/"; the RFC lists http://example.com and http://example.com:80/ as equivalent | RFC 3986, section 6.2.3 |
| Paths and query strings | Strip them for domain matching, but keep the full URL for page level questions; paths stay case sensitive | RFC 3986, section 6.2.2.1 |
| Subdomains | Map to the root domain, the public suffix plus one label (so a name under co.uk keeps its own label), unless the plan listed the subdomain on purpose | ads.txt 1.1 specification (opens in a new tab) and the Public Suffix List (opens in a new tab) |
| Deep subdomains and folders | Match the depth the platform actually targets: two subdirectory levels and up to five subdomain levels in DV360 | DV360 app, channel and website targeting (opens in a new tab) |
Decide what a subdomain on the plan means. If the plan approved food.example.com because only that section fits the brief, a served row on news.example.com is off list although the root matches. If the plan approved example.com, both rows match. Write the decision into the list itself.
Why do served domains differ from the plan?
Before calling a row off list, test it against the documented causes that produce an unplanned domain without anyone breaking a rule.
| Cause | What the documentation says | How to confirm |
|---|---|---|
| Related app inventory | DV360 says targeting a website also targets the matching app's inventory, and an app can carry a content URL, so "your ads may show in that app, even if you haven't specifically targeted it" | Split rows by Environment; app rows tied to a listed website are explained |
| Inherited channels | Advertiser or partner channels can appear as blocked and not editable in Apps & URLs targeting | Compare the composite list with the approved version |
| Change delay | "a few hours may pass before Display & Video 360 updates your line item's bidding" | Match the row's date and hour with the change time in event history |
| Masked URL | The DV360 URL field can read source_url_hidden when the exchange masks it | Count masked rows by exchange and inventory source; they are unknown, not off list |
| Ad server address | Referrer URL can be empty or return ad server URLs | Treat ad server hosts as unresolved and look them up by placement ID |
| Wrong list attached | Not a platform behavior: a line item carries an older or different list | Compare the composite list download with the approved export, line by line |
Only the rows left after these checks are off list delivery. Keep them apart from unknown rows: a masked URL means the analyst cannot say where the ad ran, not that it ran somewhere bad, and reporting it as off list overstates the problem.
What should be done about off list delivery?
Six steps for an unexplained served domain
- Size it in context. Record the domain, dates, line item, exchange and inventory source, and its share of the line item's delivery.
- Find the setting that allowed it. Open event history for the line item and its parents, with system changes included, and look for a list change, new channel or targeting expansion near the first served date.
- Check who sold it. Read the domain's ads.txt for the exchange's account ID, then the exchange's sellers.json entry; the sellers.json specification (opens in a new tab) says a seller_id is "the same ID that appears in an ads.txt file".
- Decide add or block. If the domain would pass the plan's checks, propose it for the next list version with a reason; if not, exclude it and note the time.
- Fix the cause. Correct the inherited channel, attached list or environment setting so the pattern does not return next flight.
- Write it down. Add a note in event history and a line in the reconciliation record with the evidence, decision and owner.
How does PlacementGraph give reconciliation a fixed list to match against?
What does a reconciliation look like on a real flight?
Fictional example
A Colorado transit agency's fall service campaign
A fictional regional transit agency serving Denver, Boulder and Colorado Springs runs a fall display flight announcing weekend routes, on local news, community event and commuting sites. Version 4 of its inclusion list holds 58 domains and is uploaded to two line items. On day two the analyst downloads both composite lists and confirms they carry version 4.
After three weeks the analyst normalizes the served rows. Upper case hosts and www prefixes collapse into root domains, and two community calendar subdomains match approved roots. One weather site appears as app inventory, the matching app of an approved website, which DV360 documents. Rows from one exchange carry a masked URL and are reported as unknown.
Three domains remain. Event history shows a partner level channel added in week two by another team. The analyst asks its owner to remove it for this advertiser, adds a note, proposes one domain for version 5 because it passes the plan's checks, and logs the other two as excluded with the date.
Frequently asked questions
Should off list delivery be measured in impressions or in spend?
Report both when the data allows, with the date range named. Impressions show how much delivery landed on unplanned domains; spend shows the money at stake. Google notes that the DV360 total media cost fields in Data Transfer files may be zero, so check that column before computing a spend share.
When should the first reconciliation run after launch?
Early enough to fix a configuration gap while the flight can still benefit, and before the raw files expire. Google keeps Data Transfer files in Cloud Storage for 60 days, so a first pass in the opening week and a full pass before the flight ends keep the evidence available.
Does reconciliation work the same way for a curated deal?
The method is the same with one more layer. Group served rows by inventory source so the deal's delivery is read apart from open auction delivery, and compare the deal's rows with the domain list the deal was built from as well as the buyer's inclusion list.
Can a served domain match the plan and still be wrong?
Yes. A matching domain only shows that the platform recorded the approved name. If the selling account is missing from that domain's ads.txt file, or sellers.json names an unexpected seller, the row needs a supply path review before it counts as clean.
Sources
- Data Transfer v2.0: File Format (opens in a new tab)Google for Developers, Campaign Manager 360 (last updated September 14, 2026)
- Data Transfer v2.0 overview (opens in a new tab)Google for Developers, Display & Video 360 (last updated October 14, 2024)
- App, channel, and website targeting (opens in a new tab)Display & Video 360 Help
- Dimensions in reports (opens in a new tab)Display & Video 360 Help
- Event history (opens in a new tab)Display & Video 360 Help
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab (GitHub)
- RFC 3986: Uniform Resource Identifier (URI): Generic Syntax (opens in a new tab)IETF, January 2005
- ads.txt 1.1 specification (opens in a new tab)IAB Tech Lab (GitHub)
- sellers.json specification (opens in a new tab)IAB Tech Lab (GitHub)
- Public Suffix List (opens in a new tab)Public Suffix List project
- Guidelines on privacy and online behavioural advertising (opens in a new tab)Office of the Privacy Commissioner of Canada (modified August 11, 2025)
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.