Curated deal maintenance: keeping an approved site list current
Part of Curated deals and PMPs
The short answer
Curated deal maintenance keeps the domains behind a live deal in step with the approved list. Set a review date, recheck each site's seller authorization and available supply, route removals and additions through one named approver, issue each change as a new list version, and send the seller a written change notice that it confirms before anyone edits targeting.
Key takeaways
- An approved list starts to age on launch day, so each curated deal needs a review date and a named owner.
- A site that loses seller authorization and a site that simply stops sending requests are two different problems with two different fixes.
- Additions pass the same checks as the original list and need the same approver before the seller hears about them.
- The seller's written confirmation, not the buyer's spreadsheet, shows that a change reached the deal.
How do I keep a curated deal's inclusion list current after approval?
Definition
- Curated deal maintenance
- The routine work of checking, changing and recording the sites behind a live curated deal so that the deal keeps running on the list the client approved, and nothing else.
Approval freezes a list at one moment. Afterward, publishers edit ads.txt files, exchanges update sellers.json directories, and content drifts, and the deal does not notice. IAB Tech Lab's Deals API 1.0 (opens in a new tab) says plainly that the specification "does NOT support proposals, revisions, or negotiations" and that those are agreed between the parties outside the API, so upkeep is a process the buyer and seller set up themselves.
The same specification gives a useful starting point. Its dinventory field tells the receiving system whether inventory "will NOT update once the deal goes live" (value 1) or "is updated dynamically" (value 2), and the guidance says implementers "are strongly encouraged to communicate and discuss the specifics of any and all inventory updates." Agree that value at setup. A deal set as static means a list change may need a new deal; a dynamic deal means the seller can edit the domains under the same deal ID.
A maintenance cycle for one curated deal
- Record the live baseline. Note the deal ID, exchange, approved list version, site count and the dinventory value agreed with the seller.
- Recheck seller authorization. For each listed domain, confirm the ads.txt line for the deal's exchange and the matching sellers.json entry still exist.
- Recheck supply. Read the deal's request counts by site and flag domains that stopped sending requests.
- Draft the change set. List removals and proposed additions, each with a reason and the evidence date.
- Approve and version. The named approver signs off, and the change set becomes a new list version.
- Notify the seller and wait for confirmation. Only then does the desk change any buyer side targeting.
What happens when a listed site stops selling through the exchange?
The domain goes quiet and stays on the list. Maintenance means working out why, because the fix depends on the cause. The ads.txt 1.1 specification (opens in a new tab) tells consuming systems that "If no cache-control directives are present consuming systems should default to an expiry of 7 days," so a removed authorization can take days to show up in filtering, and the timing differs by system.
In Display & Video 360, the deals troubleshooter (opens in a new tab) separates the cases. Total available requests is "The number of impressions matching the inventory sources selected," and the prebid stage counts queries "filtered because they are from Unauthorized Sellers" under an ads.txt reason. A domain with no available requests points to supply; a domain whose requests arrive and are filtered as unauthorized points to the seller files.
| What you see | Likely cause | Evidence to collect | Maintenance action |
|---|---|---|---|
| The ads.txt line for the deal's exchange is gone | The publisher no longer authorizes that seller account | Dated copy of the ads.txt file | Remove the site from the deal list in the next version |
| The exchange's sellers.json no longer lists the seller ID | The exchange closed or changed the account | Dated sellers.json lookup for the seller ID | Ask the seller whether a new account replaced it, then remove or update |
| Both files intact, no requests for the domain | Supply stopped or the seller's deal targeting no longer includes the site | Request counts by site for the deal | Ask the seller to confirm the domain is still in the deal setup |
| Requests arrive but are filtered as unauthorized | A mismatch between the files and the seller account in the request | Troubleshooter prebid reason and the request's seller ID | Send both records to the seller and hold the site until resolved |
How should site additions to a live deal be approved?
Additions carry more risk than removals: a removal shrinks the deal, while an addition puts new pages in front of the brand. Treat a proposed site like a site on the original list, with the same reading, quality and seller checks.
Who approves matters as much as the checks. A workable standing rule: the person who approved the original list approves additions, in writing, before the seller is asked to change anything. A site proposed by the seller or curator is a candidate, not an approval.
Approval checks for a site added to a live curated deal
- The site was read against the current brief, with two or three example article URLs saved.
- The site passed the same quality and made for advertising checks used for the approved list.
- The site's ads.txt authorizes the deal's exchange, and the seller ID matches that exchange's sellers.json.
- The site is not already on another deal for the same client, unless that overlap is intended.
- The addition has a written reason and the approver's name and date.
- The change set lists the new version number and the new site count.
When one list feeds deals on several exchanges, see the cross exchange deals guide for carrying a change set to each deal.
On what schedule should a curated deal list be reviewed?
The sources cited on this page set no single review interval for deal lists. One published rule comes from the Trustworthy Accountability Group. Section 4.11 of its Brand Safety Certified Guidelines (opens in a new tab), version 5.0 dated July 2026, requires direct buyers and intermediaries in the program to document how inclusion and exclusion lists are maintained and to execute those procedures "as part of their internal quarterly review process." That applies to companies in the certification program, not to all buyers, but it gives a defensible outer limit.
| Trigger | What to recheck | Suggested owner |
|---|---|---|
| Fixed calendar date, at least once a quarter | Seller files, request counts and fresh articles for all listed sites | Planner |
| Before a new flight on the same deal ID | Seller files and the list version the seller has on file | Trader |
| A site's requests drop to zero for a full week | That site's ads.txt line, sellers.json entry and deal setup | Trader, with the seller |
| A brief change from the client | Whether each site still fits the new topics and avoid topics | Planner and the approver |
| A publisher sale, redesign or new owner | Content mix, ad load and who now sells the site | Planner |
How do you tell the seller about changes to a deal's site list?
Send a written change notice for each new list version, and treat the change as pending until the seller confirms it. Buyer side tools do not carry the change for you. Display & Video 360's synced deals page (opens in a new tab) says deals with existing inventory sources "will automatically update with the exchange's latest details," while deals entered by ID "won't be automatically synced." A sync does not tell the seller what the buyer approved.
Some changes also reopen the deal's terms. Google's deal changes page (opens in a new tab) says changes to an accepted deal "will require approval" for items including CPM, approved impression volumes, delivery dates, ad sizes and "additional terms," and that deals that have ended cannot be changed. When a list change alters scale enough to touch volume or price, expect a renegotiation, not a quick edit.
What a deal list change notice contains
- The deal ID, the exchange and the deal name as the seller knows it.
- The old and new list version numbers, with the new site count.
- Each removed domain with its reason and evidence date.
- Each added domain with the confirmation that it is sold through the deal's exchange.
- The requested effective date, in the time zone of the seller's reporting.
- A request for written confirmation that the seller's deal setup now matches the new version.
Before an addition goes live, ask the seller to send domain names in its bid requests. Google's deal best practices (opens in a new tab) say "Make sure the publisher is sending domain name information," which lets the buyer see delivery move to the new version.
How does PlacementGraph keep a deal's site list versioned and checked?
What does curated deal maintenance look like on a real brief?
Fictional example
A window replacement company's deal in the Rio Grande Valley
A fictional window and door replacement company serving McAllen, Brownsville and Harlingen, Texas, runs an evergreen curated private auction beside home improvement, local news and household budget content, in English and Spanish. At launch the agency and the seller agreed dynamic inventory, so the seller can edit domains under the same deal ID. The approved list is version 3, with 40 sites (a fictional count).
At the quarterly review the planner finds two sites whose ads.txt files no longer list the deal's exchange, and one site with intact files but no requests for ten days. The first two go on the change set as removals with dated file copies. The third goes to the seller as a question, and the seller replies that the publisher paused its account; it stays on the list for one more review.
The planner also proposes two Spanish language home renovation sites. Both pass the checks, and the client lead who approved version 3 signs version 4. The trader sends the change notice and changes nothing on the buyer side until the seller confirms in writing that its setup matches version 4.
Frequently asked questions
Should a removed site come back automatically when it starts selling again?
No. Treat a returning site as a new addition. Its content, ad load or selling path may have changed while it was away, so it goes through the same checks and approver and enters in a new list version, with its removal record kept.
Can the seller add sites to a curated deal without asking the buyer?
Only if the deal was set up that way. A deal agreed as static inventory should not change, and the Deals API dinventory value 2 is the signal that sites may be updated after launch. On a dynamic deal, ask the seller to send its own change notices.
Does a list change need a new deal ID?
It depends on how the seller set up the deal. Where inventory was agreed as dynamic, the seller can edit domains under the same ID. Where it was agreed as static, or where the change also alters price, volume or dates, the seller may issue a new deal and the desk has to target the new ID.
Who should keep the master copy of the deal list?
The buyer side, in a versioned record that names the approver for each version. The seller's setup is the live copy, compared with the record after each change notice. When they disagree, the approved version wins and the seller's setup is corrected.
Sources
- Deals API 1.0 specification (opens in a new tab)IAB Tech Lab, GitHub
- ads.txt 1.1 specification (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- Troubleshoot deals (opens in a new tab)Google Display & Video 360 Help
- Synced deals (opens in a new tab)Google Display & Video 360 Help
- Make changes to deals (opens in a new tab)Google Display & Video 360 Help
- Best practices for deals (opens in a new tab)Google Display & Video 360 Help
- Brand Safety Certified Guidelines, version 5.0 (July 2026) (opens in a new tab)Trustworthy Accountability Group
- sellers.json specification (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.