Deal targeting settings: who sets each layer, and where
Part of Curated deals and PMPs
The short answer
A deal's targeting is split between two systems. The seller sets what the deal offers, such as sites, formats or countries, and the buyer sets what its line item accepts. Both sides should apply the agreed terms, but an extra buyer layer can only narrow the supply, so each layer needs one named owner and a written record.
Key takeaways
- Write geography in the units the bid request uses: country codes, ISO 3166-2 regions, postal codes or a radius, never a loose market name.
- IAB Tech Lab's Deals API tells buyers to apply targeting matching the deal's terms on their side, since deal criteria are not guaranteed to appear in bid requests.
- Matching a seller's geography is safe; adding a narrower geography, device or audience layer on top is what starves a deal.
- Audience lists and frequency caps depend on user IDs in the request, so confirm the seller sends them first.
- Record every layer with its owner, exact values and date.
How is a deal's geographic scope specified?
Geography appears twice in a deal: once in the terms the seller sets up and once in each bid request. On the terms side, the IAB Tech Lab Deals API 1.0 (opens in a new tab) has a countries field, an array of country codes in which the deal is available; if it is empty or missing, the deal is assumed to apply to all countries. Anything finer than a country, such as a state or a metro area, has no field in that object and must be agreed in writing.
On the request side, the Geo object in the OpenRTB 2.6 specification (opens in a new tab) carries the location the buyer's targeting is tested against. Writing the deal in the same units makes the two easy to compare.
| Unit | How the request expresses it | How to write it on the deal |
|---|---|---|
| Country | country, as an ISO 3166-1 alpha-3 code | USA or CAN, listed one by one |
| State or province | region, as an ISO 3166-2 code; a 2-letter state code if USA | US-OH and US-WV, or CA-ON; never a nickname such as the Midwest |
| Metro area | metro, a Google metro code that the spec calls similar to but not exactly Nielsen DMAs | The code and its name; US only, so Canadian buys use provinces or postal codes |
| Postal code | zip, a ZIP or postal code | The list as a file, with its count |
| Point and radius | lat and lon, passed only when they conform to the accuracy in type | Center, radius and unit, and whether the seller sends coordinates at all |
Which targeting is set by the seller and which by the buyer?
The seller decides which impressions carry the deal ID. The buyer decides which of those impressions its line item will bid on. The OpenRTB implementation guide (opens in a new tab) describes the buyer's side plainly: match bids against each deal in the request and "enforce targeting for dealID and seatID." The Deals API adds that implementers are strongly encouraged to discuss where targeting criteria will be set, and to discuss the delivery implications when targeting is also applied in the receiving system.
| Layer | Set by the seller in the deal | Set by the buyer in the line item | Suggested single owner |
|---|---|---|---|
| Sites or domains | The domain list uploaded to the deal | A site list or exclusions on the line item | Seller, with the buyer reviewing the list |
| Countries | countries in the deal terms | Country targeting matching the terms | Both, with identical values |
| Regions, metros, postal codes | Optional seller geo filters | Regional or postal targeting | One side only, named on the sheet |
| Device type | Device filters on the deal | Device targeting | One side only |
| Language | Language filters, if offered | Language targeting | One side only |
| Audience data | A seller or curator data layer, if any | First-party or third-party lists | Agree case by case; see the audience section |
| Frequency | No field in the Deals API deal object | Frequency caps | Buyer, if user IDs are sent |
Display & Video 360's best practices for setting up deals (opens in a new tab) show why buyer settings depend on seller data. Region and city targeting need the publisher to send that detail, and so do language, browser, device, connection speed and carrier targeting. A buyer layer the seller cannot feed matches nothing.
How does double targeting stop a deal from spending?
Double targeting is a buyer layer that repeats or narrows a seller layer. Repeating identical values is what the Deals API asks for. Narrowing is where supply disappears: each layer keeps only the share of requests that passed the one before, and a filter set on both sides with slightly different values keeps only their overlap.
Google's help is direct about the last step. The same best practices page says settings like demographics and audiences, with deals, "do not work well together and usually end up being too restrictive, preventing deals from working." The troubleshooter for deals (opens in a new tab) then shows the result as impressions lost at the targeting stage, broken down by geography, device, language, audience list, demographics and other settings.
Finding the layer that starves a deal
- Confirm requests arrive. Check that the deal shows available requests; if it shows none, the problem sits with the deal setup, not targeting.
- Open the targeting breakdown. Use a past date range, because the breakdown is not available for the current day.
- Find the largest loss. Read which setting removes the most requests, such as geography or audience list.
- Compare it with the seller's value. If the seller already applies that layer, remove the buyer copy or make the values identical.
- Change one layer at a time. Note each change and its date, then read the breakdown again a day later.
Should audience data be layered on a curated deal?
A curated deal built from a reviewed site list already narrows supply by context. Adding audience data narrows it again, by user. Display & Video 360 advises confirming that the publisher sends user IDs, and if it sends none or only a few, removing demographic targeting, audience targeting and frequency caps from the insertion order and line item. Its Inventory Availability report (opens in a new tab) can filter by audience list, but its unique counts exclude users who block third-party cookies, and it may not show data for combinations matching fewer than 3,000 unique cookies.
| Approach | Strengths | Weaknesses |
|---|---|---|
| Context only, no audience layer | Keeps all supply the site list allows; needs no user IDs; fewer privacy questions | Cannot restrict to known customers or exclude past buyers |
| Buyer audience list on the line item | Uses the advertiser's own data; the buyer controls it | Depends on user IDs in requests; can cut supply sharply; consent rules apply |
| Seller or curator data layer | Applied before the request reaches the buyer; may reach users without buyer IDs | Less visible to the buyer; the Deals API auxdata field says only whether such a layer and fee exist |
Privacy rules also differ by market. In Canada, the Office of the Privacy Commissioner's guidelines on online behavioural advertising (opens in a new tab) say opt-out consent could be considered reasonable only under conditions, including this one: "The opt-out takes effect immediately and is persistent." In California, the California Privacy Protection Agency (opens in a new tab) describes a right to opt out of sharing personal information for cross-context behavioral advertising, and says businesses must honor qualifying opt-out preference signals such as the Global Privacy Control. Our guide to curated audiences covers the seller side standard.
How do you record deal targeting on the sheet?
The curated deal sheet holds the deal's full terms. Its targeting block should let anyone answer two questions in a minute: what does the seller filter, and what does the buyer filter. Display & Video 360's event history (opens in a new tab) records the time, date, description and user for each change and downloads as a CSV file, which makes a useful buyer-side log next to the sheet.
Targeting block on a deal sheet
- Countries are listed as ISO codes, and the same codes appear in the line item.
- Any region, metro or postal layer names its units, its values and the one side that applies it.
- Device and language layers say seller, buyer or none, never both with different values.
- The sheet says whether the seller sends user IDs, and whether any audience layer is applied, by whom.
- Frequency caps are noted with their level, or marked as not used.
- Each layer carries the date it was set and the person who confirmed it.
- A change to any layer opens a new version of the sheet.
What does a targeting plan look like on a real brief?
Fictional example
A landscaping firm buys a curated deal across the Mid-Ohio Valley
An unnamed landscape design and lawn care firm serves towns on both banks of the Ohio River, from Marietta in Ohio to Parkersburg in West Virginia. It wants display beside home, garden and local news content in both states, in English, from a curated deal built on an approved site list.
The curator sets the deal to the United States with a region filter for US-OH only, copied from an older Ohio campaign. The buyer adds the firm's service area as a postal code list on both sides of the river, a mobile device layer and a third-party homeowner audience. Week one shows requests but almost no bids.
The targeting breakdown shows the largest losses at geography and audience list. The desk asks the curator to change the region filter to US-OH and US-WV, keeps the postal list as the single buyer geo layer, removes the duplicate device filter and drops the audience list, since the seller confirms few user IDs. A new sheet version records each layer and owner.
How does PlacementGraph help set the geography a deal starts from?
Frequently asked questions
Does a deal's country list guarantee impressions only from that country?
No. The Deals API says deal criteria are not guaranteed to be accurately reflected in bid requests carrying the deal ID, and that buyers should always apply targeting matching the deal's terms. Its own example is a US only deal, where the buyer should add US targeting in the buying platform when trafficking the campaign.
Can one deal cover both the United States and Canada?
Yes. The Deals API countries field takes an array, so one deal can list both. Separate line items per country still help, because pacing, language and reporting can then be read apart. If Canadian French sites are included, record the language layer and its owner on the sheet.
What happens to frequency caps on a deal with few user IDs?
They can block delivery. Display & Video 360 says that if a publisher sends no user IDs, or only a few, demographic targeting, audience targeting and frequency caps should be removed at the insertion order and line item levels. Ask the seller about user IDs before deciding whether to cap at all.
What should happen when the client changes the geography mid-flight?
Agree the change with the seller first, then update the buyer side. Display & Video 360 notes that changing a negotiation may require another review, or the seller may generate a new deal automatically. Check whether the deal ID changed, update the line item, and issue a new sheet version with the date.
Sources
- Deals API Specification version 1.0 (opens in a new tab)IAB Tech Lab, deal-api repository
- OpenRTB 2.6 specification: Geo, Device and User objects (opens in a new tab)IAB Tech Lab, OpenRTB repository
- OpenRTB 2.6 implementation guide: PMP and direct deals (opens in a new tab)IAB Tech Lab, OpenRTB repository
- Best practices for setting up deals (opens in a new tab)Google, Display & Video 360 Help
- Troubleshoot your deals and line items (opens in a new tab)Google, Display & Video 360 Help
- Inventory Availability report (opens in a new tab)Google, Display & Video 360 Help
- Event history (opens in a new tab)Google, Display & Video 360 Help
- Negotiate a deal in Display & Video 360 (opens in a new tab)Google, Display & Video 360 Help
- Guidelines on privacy and online behavioural advertising (modified 2025-08-11) (opens in a new tab)Office of the Privacy Commissioner of Canada
- Frequently Asked Questions (opens in a new tab)California Privacy Protection Agency
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.