Deal naming conventions: how to name deals so each ID stays traceable
Part of Curated deals and PMPs
The short answer
A deal naming convention is a fixed pattern for the human readable name of each PMP or curated deal: client, market, site list version, format, deal type and flight dates, in the same order. The deal ID and exchange stay the true keys. The name lets planners, traders and finance find, filter and reconcile the right deal without guessing.
Key takeaways
- The deal ID and the exchange identify a deal; the name is a label for people, so it must never be the only link between systems.
- A good name uses short tokens in a fixed order: client, market, list version, format, deal type, currency and dates.
- The list version token points to the approved site list behind the deal, and a register row maps name, ID, exchange and version.
- Renames are safe when reports join on the deal ID, since Display & Video 360 locks the exchange and deal ID once saved.
- One named owner writes the convention, and the person who enters the deal checks the name against it before launch.
Why do deal names matter if the deal ID is the real key?
A private marketplace deal carries two kinds of identity. The machine identity is the deal ID on a given exchange. The OpenRTB 2.6 specification (opens in a new tab) defines the Deal object's id as "A unique identifier for the direct deal," and the bid that answers it returns the same value in dealid. The human identity is the name somebody typed at setup, and it is what reports, invoices and client decks show.
The two can drift apart. Google's Display & Video 360 reporting dimensions (opens in a new tab) show the split: Inventory Source is "The name of the deal that supplies buyable impressions to your line items," Inventory Source ID is "The Display & Video 360 identifier for a deal," and Inventory Source ID (External) is "The seller's (i.e. a publisher or exchange) identifier for a deal used in their systems." A convention makes the first column trustworthy; the other two stay the keys.
Definition
- Deal naming convention
- A written pattern for the readable name of each deal, with fixed tokens in a fixed order, plus the rule that the deal ID and exchange, not the name, are used to join records across systems.
What should a deal name include?
Pick tokens that answer what people ask when they cannot see a deal's settings: whose is it, where does it run, which list is behind it, what creative does it take, how is it priced and when does it run. Fix their order, separator and codes so names sort and filter cleanly in a spreadsheet.
| Token | Example | Why it is in the name | Rule |
|---|---|---|---|
| Client code | RVB | Separates clients in shared seats | Three or four letters from an agreed client list, never free text |
| Market | US-AR | Shows geography at a glance | ISO 3166-2 style codes, the scheme the OpenRTB Geo object uses for regions |
| List version | L4 | Points to the approved site list behind the deal | The version number from the list's own record, with no extra wording |
| Format | DSP or VID | Matches creative to deal | One code per format family the deal sells |
| Deal type | PA, PD or PG | Private auction, preferred deal or guaranteed | Matches the auction type the seller set |
| Currency | USD or CAD | Prevents a CAD floor from being read as USD | ISO 4217 codes, the scheme the Deal object's bidfloorcur uses |
| Flight | 20261102_20261220 | Sortable start and end dates | YYYYMMDD; write OPEN for an evergreen deal |
Display & Video 360's API says the display name "Must be UTF-8 encoded with a maximum size of 240 bytes," but a name that long is unreadable in a report column, so aim for under 60 characters. IAB Tech Lab's Deals API (opens in a new tab) defines the name as the "Name of the deal as created in the origin system" and warns that "This name may be displayed to the buyer." Its separate desc field, strongly recommended at 250 characters or less, is the home for anything that does not fit a token.
Leave out anything that changes during a flight, such as a bid price, a pacing note or the trader's initials. A name that needs weekly edits stops being trusted.
How do you link a deal name to a site list version?
The list version token is the bridge between planning and buying. It says which version of the approved site list the seller loaded. Rules for numbering and freezing list versions belong to the list itself, as covered in the media plan handoff guide; the deal name only carries the number.
A name alone cannot hold the whole link, so keep a deal register: one row per deal with the name, exchange, external deal ID, the buying platform's own ID, list version, site count and the date the seller confirmed the domains. The OpenRTB implementation guide (opens in a new tab) says a deal ID "should be treated as a 'targeting token' associated to orders, line-items or campaigns," so the register also lists the line items that target it.
When the list changes, decide whether the deal changes too. If the seller reloads the domains under the same ID, update the version token and the register row on the same day. If the seller creates a new deal, give it a new name and retire the old row. The Deals API's dinventory field signals whether a deal's sites may update after it goes live.
How do you rename deals without breaking reports?
Renaming is safe when nothing downstream depends on the name. Display & Video 360's Structured Data Files guide (opens in a new tab) marks the exchange and Deal ID of an inventory source as values that "cannot be updated once saved," while the name stays editable. The keys survive a rename; only text-matched spreadsheets and dashboards break.
There are limits on who can rename and what. Google's deal management article (opens in a new tab) says a user with access to all the partners or advertisers a deal is permissioned to can make changes, such as the name or rate type, and that "Programmatic Guaranteed line item names cannot be changed after creation." Report labels also lag: Google's data freshness page (opens in a new tab) says changing the names of entities like line items or insertion orders "takes 24 hours to be reflected in reports." It does not name deals, so check the next day's report after a deal rename.
Five steps for a safe rename
- Confirm the keys first. Find the exchange and external deal ID in the register so you change the right row.
- Rename in the buying platform. Apply the new name in the convention's format and log the old name in the register.
- Tell the seller. Ask whether the seller's own name should change too, so both sides see one label.
- Fix text-matched reports. Switch saved filters and dashboards that match the old name to the deal ID.
- Check the next day. Confirm that rows for the old and new names join on the same ID.
Who owns the naming convention?
The convention fails when anyone can edit it and nobody enforces it. Give it one owner, such as the head of the trading desk or programmatic operations, who keeps the written rules, the client code list and the register template. Traders apply it; finance and analytics consume it and report breaks. The platforms decide who can technically rename an entry, so the owner also checks that platform access matches the people meant to edit.
| Role | Owns | Checks |
|---|---|---|
| Desk lead or operations owner | The written convention, client codes and register template | A sample of new deal names each month against the rules |
| Trader entering the deal | The name and the register row for each deal they enter | Tokens against the deal sheet and the seller's confirmation |
| Planner | The list version and site count behind the deal | That the version token matches the approved list |
| Seller or curator | The deal ID, exchange and the name in its own system | That the buyer's name and theirs describe the same deal |
| Finance and analytics | Invoice matching and dashboards | That reports join on deal ID, not on name text |
When two clients, agencies or desks share a buying seat, agree the client code list across all of them before the first deal is entered, so no two clients end up with the same code.
What does a naming convention look like on a real brief?
Fictional example
Three deals for a home internet provider in Arkansas
A fictional regional home internet provider wants display and online video beside local news, home and family content in Little Rock, Fayetteville and Jonesboro, in USD. Its agency plans two curated private auctions from version 4 of an approved site list and one preferred deal with a statewide news publisher.
The desk names them RVB_US-AR_L4_DSP_PA_USD_20261102_20261220, RVB_US-AR_L4_VID_PA_USD_20261102_20261220 and RVB_US-AR_PUB_DSP_PD_USD_20261102_20261220. PUB replaces the list version because the preferred deal is one publisher's own inventory. Each gets a register row with exchange, external ID and line items.
Midway through the flight the planner approves version 5 of the list. The seller reloads the domains under the same IDs, so the trader changes L4 to L5 in both curated names, logs the old names and confirms the next day that report rows still join on the IDs.
What should a deal name check cover before launch?
Deal name and register check before a deal spends
- The name follows the token order, separator and codes in the written convention.
- The client code comes from the agreed list and is not shared with another client in the seat.
- The market token matches the deal's country and region targeting.
- The list version token matches the approved list the seller loaded, and the site count is recorded.
- The deal type and currency tokens match the seller's confirmation.
- The register row holds the exchange and external deal ID as a pair, copied from the seller's system.
- Saved reports and dashboards for the client filter on the deal ID, not on name text.
How does PlacementGraph help keep the list behind a deal traceable?
Frequently asked questions
Should the buyer and the seller use the same deal name?
It helps, but it is not required. The seller names the deal in its own system and, under IAB Tech Lab's Deals API, that name may be displayed to the buyer. The buyer can rename its own entry. If the names differ, record both in the register.
Can the deal ID itself follow the naming convention?
Plan on no. The deal ID is created in the seller's system, which IAB Tech Lab's Deals API calls the origin, and the buyer copies it. The buyer does not control its format. Keep meaning in the name and the register, and treat the ID as an opaque string that is copied, never retyped.
How should an evergreen deal be named?
Replace the end date with a fixed word such as OPEN. The Deals API says evergreen or always on deals should leave the end date blank, so the name should not invent one. Review open deals on a schedule, because their list version can age while the name stays the same.
Do deal groups need their own names?
Yes. Display & Video 360 lets buyers organize inventory into groups to manage and target several inventory sources at once. Give each group the same client and market tokens as its deals plus a group marker, so a client filter shows the groups and the deals inside them.
Sources
- OpenRTB 2.6 specification, Deal and Bid objects (opens in a new tab)IAB Tech Lab, OpenRTB repository
- OpenRTB implementation guide, section 7.3 PMP and direct deals (opens in a new tab)IAB Tech Lab, OpenRTB repository
- Deals API specification, Deal and Terms objects (opens in a new tab)IAB Tech Lab, deal-api repository, version 1.0
- REST resource: inventorySources (opens in a new tab)Google for Developers, Display & Video 360 API, checked October 22, 2026
- Create or edit entities with Structured Data Files (opens in a new tab)Google, Display & Video 360 Help
- Manage your deals (opens in a new tab)Google, Display & Video 360 Help
- Dimensions in reports (opens in a new tab)Google, Display & Video 360 Help
- Report data freshness and availability (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.