Inventory packages in programmatic: what is inside the box
Part of Curated deals and PMPs
The short answer
An inventory package is a named bundle of ad inventory that a publisher, publisher group, exchange or buyer assembles so it can be sold or bought as one unit through a deal ID. It may hold a fixed list of sites, sections or apps, or a rule that changes over time, so buyers should ask what it contains.
Key takeaways
- A package is a seller's or buyer's bundle of inventory; the deal ID is how that bundle is bought.
- Publishers, publisher groups, exchanges and buyers can all build packages, and each answers to different interests.
- Transparency ranges from full URLs to blind inventory, so the first question is what level of site detail the package exposes.
- The Deals API gives sellers fields to declare the domains, seller IDs, publisher count and whether the inventory can change.
- A package saves setup time; a custom site list gives the buyer control; a plan should know which trade it is making.
What is an inventory package in programmatic buying?
Definition
- Inventory package
- A defined set of ad inventory, such as sites, site sections, apps, formats or audience segments, grouped under one name so it can be offered to buyers and bought as a single unit through a deal ID.
The word package is used loosely, so it helps to anchor it in documented definitions. The Authorized Buyers Marketplace API (opens in a new tab) describes an auction package as one that "Defines a segment of inventory that buyer wants to buy," created by a buyer and able to be shared with multiple buyers, who subscribe and unsubscribe. Google Ad Manager's help page on Private Marketplace deals (opens in a new tab) lists Marketplace Packages beside Preferred Deals and Private Auctions as non-guaranteed deals that can receive a deal priority. In both, the package is the bundle and the deal is the way it is transacted.
The IAB Tech Lab Deals API 1.0 (opens in a new tab), released on February 6, 2026, uses the same language when it describes deals that carry data in a package or that are packaged by a curator. Our programmatic curation guide covers who curates and how curation fees are declared. This page is narrower: what a package holds, and how a buyer finds out.
Who builds inventory packages?
Four kinds of builder appear below. Each one chooses the contents with its own goals in mind, which is worth knowing before reading the package description.
| Builder | Possible contents | Question to ask |
|---|---|---|
| A single publisher | Its own sites, sections or apps, grouped by topic, format or audience | Which domains and sections are in, and is any third party data applied? |
| A publisher group or sales house | Several sites under one owner or one sales agreement | Does the Deals API pubcount value say single publisher or multi-publisher, and why? |
| An exchange or SSP | Inventory from many publishers that sell through it, grouped by category, format or quality rule | Is the list of domains fixed, or rebuilt by a rule during the flight? |
| A buyer or curator | A segment of inventory set up for one or more buying seats to subscribe to | Who owns the package, and which seats can bid on it? |
The publisher count field in the Deals API shows why the builder matters. pubcount 1 means single publisher and 2 means multi-publisher, but the specification notes that a single company with several web and app properties counts as one publisher, and that inventory aggregation services representing multiple publishing sites may also be considered a single publisher deal. A package marked single publisher can therefore still span many unrelated sites.
Publishers also decide what buyers can discover in the first place. In Google Ad Manager, publisher profiles (opens in a new tab) let a network's inventory be discovered in the Marketplace, and buyers see only the sites and apps the publisher adds to a child profile. What a buyer is shown is a choice the seller made.
How can a buyer see which sites a package contains?
Start with the level of transparency on offer. IAB's 2013 paper Programmatic and Automation: The Publishers' Perspective (opens in a new tab), written by its Programmatic Publisher Taskforce, notes that publishers can offer different buyers different levels of transparency, and lists five options. They still describe the range a package can sit on.
| Level | IAB example | What the buyer can check |
|---|---|---|
| Full URL | publisher.com/sports/NFL/Giants/article1235.html | Every page an ad ran on, the strongest basis for a content review |
| Section targeting | publisher.com/sports | The site and section, enough to judge topic fit |
| Top level domain | publisher.com, news.publisher.com | The site, so ads.txt, sellers.json and site quality can be reviewed |
| Masked URL | www.publishermarketplace.com | Only a placeholder; the real sites cannot be reviewed |
| Blind | No information is passed | Nothing about where the ads ran |
In the bid stream, the OpenRTB 2.6 (opens in a new tab) Site object carries domain and page, the URL where the impression will show, but the site name may be aliased at the publisher's request. The Publisher object's id corresponds to a seller_id in the exchange's sellers.json file, which lets a buyer trace each impression to a seller account, as our sellers.json guide explains.
Before launch, the Deals API gives sellers a place to declare contents. Its Inventory object can list sitedomains, appbundles, sellerids and content categories, and the specification says it should only be included when the deal is for a static set of sites or applications. The dinventory field states whether sites or apps may update after the deal is live: 1 means they will not, 2 means the inventory is updated dynamically, and 0 means undisclosed. An empty sitedomains list implies the deal may run across many unspecified domains.
How do packages differ from a custom site list?
A package is built before the buyer arrives; a custom site list is built for one brief and handed to a seller or curator to turn into a deal. Neither is better in general. They trade speed against control.
| Point | Ready-made package | Custom site list |
|---|---|---|
| Time to launch | Fast: the package, and sometimes the deal ID, already exist | Slower: the list is built, reviewed and set up as a new deal |
| Scale | Can be large, because it is built for several buyers | Limited to the sites that fit the brief and are sellable on the exchange |
| Control over sites | The builder chooses; contents may change if inventory is dynamic | The buyer chooses and approves each site |
| Fit to the brief | General: a topic, format or audience shared across advertisers | Specific to one client's topics, markets and exclusions |
| Effort to verify | Needs the domain list and a served domain report to check | Checked before the deal exists, then reconciled after launch |
| Builder's interests | May reflect what the builder needs to sell | Reflect the brief, within what sellers will accept |
What should a buyer ask before using a package?
Questions to put to the seller before buying an inventory package
- We have the full domain and app list behind the package, not only its name and description.
- We know whether the inventory is fixed for the flight or rebuilt by a rule, and how changes will be announced.
- We know whether the package is single publisher or multi-publisher, and who owns each site.
- Each listed domain's ads.txt names the seller of the package, and the seller ID appears in the exchange's sellers.json.
- We know whether non-publisher data is applied to the package and whether a fee is attached.
- We know the transparency level of the delivery report: full URL, section, domain or less.
- The package's geography, languages and formats match the brief.
- We will receive a served domain report, and we have agreed what happens to delivery on sites outside the list.
Write the answers on the deal sheet alongside the deal ID, so the next planner can see what the package held when it was bought.
What does reviewing a package look like on a real brief?
Fictional example
A home lighting retailer weighs a package in the Gulf South
An unnamed retailer of ceiling fans and home lighting wants display beside home improvement, decorating and local lifestyle content in Louisiana, Mississippi and Alabama, in English. A seller offers a ready-made home and garden package with a deal ID that could go live that week.
The trading desk asks for the domain list and the Deals API values. The list arrives with dinventory set to 2, so the sites can change during the flight, and pubcount set to 1, although the domains belong to several owners sold through one sales house. About a third of the listed domains are national recipe and celebrity home sites with little regional readership.
The desk keeps the package for a small test budget with a weekly served domain report and builds a custom site list for the main flight from regional home and lifestyle publishers, which the same seller sets up as a separate deal.
How does PlacementGraph help when a buyer wants its own list instead of a package?
Frequently asked questions
Is an inventory package the same as a deal?
Not quite. The package is the bundle of inventory; the deal is the agreement and the deal ID used to buy it. One package can sit behind several deals with different buyers or prices, and a buyer may see only the deal ID unless it asks for the package contents.
Can a buyer remove sites from a seller's package?
Sometimes. A seller may agree to a narrower version as a new deal, or the buyer can exclude domains in its own buying platform. Exclusions on the buyer side reduce the sites the deal can deliver on, so check that what remains still has enough inventory for the budget.
Are packages built by content category reliable?
They are as reliable as the classification behind them. OpenRTB lets sellers describe a site, a section and a page with IAB Tech Lab content categories, but those values are declared by the seller. Ask how categories are assigned and review a sample of listed sites yourself.
What is a run of network package?
A package that covers all or most of a publisher's or network's inventory rather than a chosen subset. It can give scale and simple setup, with little control over which sites or sections the ads reach, so it calls for a domain list and a served domain report like any other package.
Sources
- REST resource: buyers.auctionPackages (opens in a new tab)Google, Authorized Buyers Marketplace API
- About Private Marketplace deals (opens in a new tab)Google Ad Manager Help
- Publisher profiles and buyer visibility (opens in a new tab)Google Ad Manager Help
- Deals API 1.0 specification (opens in a new tab)IAB Tech Lab, deal-api repository
- Deal API 1.0 release (1.0-202602), published February 6, 2026 (opens in a new tab)IAB Tech Lab, deal-api repository
- Programmatic and Automation: The Publishers' Perspective (opens in a new tab)IAB, 2013
- OpenRTB 2.6 specification, Site and Publisher objects (opens in a new tab)IAB Tech Lab, OpenRTB repository
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.