A group of advertising companies wrote down rules for how automated ad auctions should work, mainly to stop the same ad slot from being auctioned off more than once at the same time. This matters to anyone who buys or sells online ads, because duplicate auctions waste computing power and money without adding a single new customer to reach. For the next month, anyone in the industry can send feedback before the rules are finalized, and companies do not have to follow them yet since they are voluntary.

The IAB Tech Lab's Programmatic Governance Council released the first version of its Programmatic Best Practices on September 16, 2026, a document that sets out shared rules for how buyers and sellers of digital advertising should handle automated ad auctions. The document opened for public comment the same day and will remain open for 30 days, closing on October 16, 2026, according to the IAB Tech Lab's Programmatic Standard Practices page.

The release marks the first formal deliverable from the Programmatic Governance Council, a body IAB Tech Lab announced on April 21, 2026 with founding members including Omnicom, WPP, Dentsu, Disney, Amazon Ads, The Trade Desk, Magnite, PubMatic, Hearst, News Corp, Yahoo, Raptive and Mediavine. According to the document, the council is co-chaired by Scott Both of Hearst, Huda Kazi of Warner Bros. Discovery, Harry Wilkins of Zynga and Ben Hovaness of Omnicom Media Group. Jill Wittkopp, vice president of product at IAB Tech Lab, is listed as the organization's contact for the initiative.

Unlike the technical specifications IAB Tech Lab typically publishes, such as OpenRTB or the SupplyChain object, the Best Practices document does not introduce new protocol fields or data formats. Instead, it sets operational rules for how existing standards should be applied, targeting a set of practices the council frames as sources of waste, redundant cost and reduced trust between buyers and sellers.

What the document covers

The Programmatic Best Practices, version 1.0, runs to seven substantive sections after an executive summary, covering support for existing IAB Tech Lab standards, supply chain accounting, bid caching and pooling, placement identifiers, ad refresh, request duplication and request integrity. A glossary at the end defines terms the document treats as having specific technical meaning, including bid caching, bid pooling, variation and replication.

According to the executive summary, the practices aim to establish "a common understanding that a request should represent a real person or audience, an attested device, and a known and testable supply chain." The document states its central concern is "the proliferation of bid requests associated with a single ad opportunity," arguing that reducing this volume lowers processing costs "throughout the supply chain" and frees platform resources "to more effectively optimizing toward advertiser goals."

The document is explicit that it does not restrict how companies choose their partners. As the executive summary puts it, "any participant in the ecosystem is free to choose their partners; the aim is the reduction of redundant requests by ensuring that requests are sent to each partner only once per underlying ad opportunity, per integration mechanism or inventory partner domain." Companies are additionally encouraged, on a general basis, to "clearly define and understand the business value of each integration partner."

Section one: supporting existing standards

The first substantive section is the shortest, and it sets a baseline rather than introducing new obligations. It calls on market participants to support the required fields and format of the most recent, widely deployed production version of OpenRTB, the real-time bidding protocol the IAB Tech Lab maintains, and to keep ads.txt and sellers.json files updated. Both files are already established parts of the transparency infrastructure that lets buyers verify which sellers are authorized to offer a given publisher's inventory, a system the IAB Tech Lab finalized alongside the SupplyChain object in 2019.

Accounting and supply chain

The second section addresses how buyers can trace where a bid request came from. It states that "a buyer should be able to identify the ad request initiator of a given bid request as well as the path the request traverses," a capability the document says lets buyers "distinguish the source of the request across header wrappers, server side auction partners and other ad request initiator, making it easier to identify duplication."

The document's single concrete instruction in this section is direct: "Support schain and ensure an schain object is included in each bid request." The schain object, formally the SupplyChain object, records each intermediary that handled a bid request as it moved from publisher to demand-side platform. It has existed in the OpenRTB specification since 2019 and moved into a more prominent position, source.schain, with the release of OpenRTB 2.6 in April 2022. Despite that history, adoption and validation of the object have been inconsistent. A HUMAN Security diagnostic published in late 2023 found that while a large majority of bid requests carried some form of the object, only a minority passed full validation against a publisher's declared sellers.

Bid caching and bid pooling

The third section addresses a practice the glossary defines precisely. Bid caching is "retaining a bid response to apply to a future auction for a different opportunity than the one it was solicited for." Bid pooling is "organizing multiple valid bids within a single content session or pod to optimize for revenue or user experience, including competitive separation and IAB Tech Lab content or ad category conflict resolution."

The document sets two boundaries on these practices. First, that a bid should not be stored or applied beyond its expiration, measured either at the impression level, imp.exp, or the bid level, bid.exp, both fields defined within OpenRTB. Second, that caching or pooling should only occur "across placements/opportunities that are materially the same," meaning the same user or audience, the same content, a similarly performing ad placement and an equivalent user experience, all within the original bid's time-to-live window.

Placements

The fourth section deals with how a single ad slot is identified across a request. It defines a placement as "a distinct ad slot within a digital property's content, defined by its format, position, and technical constraints," and states that the goal of a placement or pod identifier, whether expressed as a Generic Placement ID, a tag ID or an ad unit, "is to accurately represent the ad opportunity being offered and accurately communicate to buyers what they're bidding on."

The document instructs sellers to include exactly one placement or pod identifier for each unique placement within a given context, whether that context is a URL, an app page or a video stream. It specifically prohibits generating more bid request identifiers than there are actual placements on a page or ad slots in a video, and it discourages rotating identifiers across a single placement that supports multiple formats, such as native, display and video. Instead, the document points to OpenRTB's existing support for multiformat impression requests as the preferred mechanism.

Ad refresh

The fifth section addresses ad refresh, the practice of cycling new ad exposures through an existing placement while a user remains on a page without navigating away. According to the document, OpenRTB already supports this behavior through what it calls the Refresh object, and the guidance asks companies to declare refresh activity truthfully within that object rather than allowing it to happen silently.

The document's operational instruction ties auction timing to the declared refresh interval: "Build your ad-refresh setup to time the execution of auctions so they align with your defined minimum refresh interval," offering the example that if a refresh interval is set to 30 seconds, auctions should not run every five seconds "until the ad changes." The implication is that mismatched auction cadences, where bidding happens far more often than the ad itself actually changes, generate requests without corresponding value.

Request duplication

The sixth section is the document's most detailed, and it is here that the executive summary's stated priority becomes fully operational. The glossary separates duplication into two categories. Variation occurs when "multiple requests are generated for the same opportunity, but they traverse different supply chains or paths, contain materially different information in each bid request, or both." Replication occurs when "bid requests are exact clones or the variance is not material."

The document treats these two categories differently. It states plainly: "Do not engage in replication." Variation is treated with more nuance, since the document acknowledges that "instances of variation in which duplicated bids include material differences dictated by requirements such as privacy and transparency, will continue to exist," and asks only that any such accommodation "avoid violating the above principles to the extent possible."

The section also names a specific mechanical pattern it wants stopped: "fan out" behaviors, in which arrays within a bid request are exploded into individual separate requests, or in which every deal identifier generates its own distinct bid request, rather than being carried as an array within a single request. The document adds that "bid request recipients are expected to support multi-imp and multi-format requests and to be able to properly process other arrays in the request," placing an obligation on the receiving side of the transaction as well as the sending side.

The document acknowledges that some duplication is currently unavoidable given limitations in how much value the current OpenRTB specification can express in a single request. Where that duplication is required, the guidance asks that it be "constrained, incremental, and made observable to downstream systems," and states explicitly that "limitations of the spec should not be a catch-all reason for wide-ranging duplication." To help offset the effects of unavoidable duplication, the section asks demand participants to support multi-bid responses "where appropriate, especially when TID is present in the bid request" - a reference to the transaction identifier, the same field at the center of a separate dispute between Prebid and the IAB Tech Lab in August 2025 over whether identifiers should remain consistent across a request's full path or become bidder-specific.

Request integrity

The final substantive section addresses what happens to a request or bid after it has been generated. The document sets three boundaries. It asks that, absent prior arrangement directly between a buyer and a seller, no party should overwrite or remove objects or attributes from a request. It prohibits altering identifiers or their associations, offering a specific illustration: if a bid placed for one auction under one transaction identifier is later cached and applied to a different auction under a different transaction identifier, that mismatch should not trigger an auction win or a render event under the original identifier.

The third instruction addresses what the document calls silent identifier bridging, the practice of connecting one identifier to another without disclosing that the connection has been made. The guidance requires that any such bridging "must be declared using the defined attributes in the eids object in OpenRTB," and that "the buyerUID attribute guidance must be followed."

Context: a market the industry itself calls disordered

The Programmatic Best Practices document does not exist in isolation. It follows several years of independent measurement and industry commentary describing the same underlying problem the document targets: the same ad impression entering an auction more than once, competing against itself for a single buyer's attention, at a cost borne by infrastructure on both the buy side and the sell side.

The most direct prior measurement of the scale of that problem comes from DataBeat, a programmatic market intelligence unit operating under MediaMint, which published its June 2026 Sellers Report on June 11, 2026. That report measured a 46 percent duplicated-domain rate among what DataBeat classifies as Tier 1, or established, supply-side platforms, meaning nearly half of the publisher domains those platforms connect to can be reached through more than one supply path at once. The report attributed this condition to domains reachable through both a direct SSP relationship and at least one reseller path simultaneously, a configuration that allows the same impression to enter an auction more than once. DataBeat found an average of 1.31 intermediaries connecting each duplicated domain.

That duplication problem has already produced commercial responses from companies operating in the market. PubMatic began enforcing a revised Supply Policy effective April 16, 2026, under which publishers sending inventory volumes above a daily cap face what the company calls an Excess Inventory Fee, set at $0.001 CPM and rounded up to the nearest $10 per month, according to PPC Land's reporting on the policy. Publishers who continue to exceed their limits after notification risk having their domains blocked by PubMatic's Inventory Quality team. At the time, PPC Land's own inquiry to PubMatic noted that the company had not disclosed publicly whether the fee's trigger was total impression volume, raw queries-per-second, or some combination of signals.

Amazon Ads took a different approach to the same underlying cost problem. On April 15, 2026, the company donated its Dynamic Traffic Engine to the IAB Tech Lab's Open Source Initiative, placing the framework under the same industry governance structure that already covers OpenRTB, ads.txt and the Open Measurement SDK. The Dynamic Traffic Engine is a file-based signaling system that lets demand-side platforms tell supply-side platforms in advance which bid requests they are unlikely to bid on, allowing the SSP to filter those requests at the source rather than forwarding them and having the DSP discard them on arrival. Anthony Katsur, chief executive of IAB Tech Lab, described the goal at the time as extending "beyond infrastructure savings," calling it part of "establishing and managing a refined model of a broad supply chain that optimizes campaign performance by ensuring that every bid request represents a high-value opportunity for both buyers and sellers."

Publishers themselves had already begun addressing bid duplication independently, well before either the PubMatic fee or the Amazon donation. Major publishers including Chegg and the Daily Mail deployed bid throttling techniques starting in 2025 to limit how many duplicate requests their pages generate, stopping calls to a given slot once it has drawn a set number of requests without a bid.

Where the document sits relative to existing standards

Several of the practices the document lays out reference infrastructure that has existed for years but has struggled with inconsistent adoption or validation. The SupplyChain object, which the document's accounting section asks companies to support in every bid request, was released for public comment by the IAB Tech Lab on April 11, 2019 alongside sellers.json, with both standards finalized that July, according to PPC Land's explainer on the object. The object moved from an extension field, source.ext.schain, into a formal position within the specification, source.schain, with the release of OpenRTB 2.6 in April 2022.

Adoption of the object has not translated cleanly into verification. A HUMAN Security diagnostic published on November 1, 2023, drawn from bid requests the company protected in late October of that year, found that while 79 percent of requests carried a SupplyChain object overall, only 42 percent of the objects present passed full validation, and external consistency between the declared chain and a seller's published sellers.json file was weakest of all, at 50 percent. Those figures describe requests already several years into the object's existence, suggesting the Best Practices document's instruction to "support schain and ensure an schain object is included in each bid request" addresses a gap that has persisted rather than one that has closed with time.

Placement identifier practices, addressed in the document's fourth section, connect to a broader industry conversation about supply path optimization, the effort by buyers to consolidate and shorten the routes through which they purchase inventory. IAB Spain's first supply-side platform guide, published April 15, 2026, framed supply path optimization as the primary structural tool available to the industry for improving efficiency, explicitly naming validation of supply chains through ads.txt, app-ads.txt, sellers.json and the schain object as central to that effort, according to PPC Land's coverage of that guide.

The Programmatic Governance Council's mandate

The council that produced this document was formed roughly five months before releasing its first deliverable. IAB Tech Lab announced the formation of the Programmatic Governance Council on April 21, 2026, describing it as a body meant to bring structured governance to what the organization's own framing acknowledged was a disordered market handling more than $200 billion in US digital advertising transacted programmatically. Founding membership at the time spanned agency holding companies, publishers, and both demand-side and supply-side platforms: Omnicom, WPP, Dentsu, Disney, Amazon Ads, The Trade Desk, Magnite, PubMatic, Hearst, News Corp, Yahoo, Raptive and Mediavine.

The breadth of that founding roster, spanning holding companies, independent publishers, major demand-side platforms, major supply-side platforms and a streaming company, distinguishes the council from initiatives that originate from a single platform or vendor. The document released September 16, 2026 lists a somewhat different co-chair structure than the one reported at the council's formation, naming Scott Both of Hearst, Huda Kazi of Warner Bros. Discovery, Harry Wilkins of Zynga and Ben Hovaness of Omnicom Media Group as co-chairs, covering publisher, streaming, gaming and agency perspectives respectively.

According to the executive summary, the council intends the Best Practices document to be the first in an evolving series. "These practices will continue to evolve with the industry," the summary states. "We expect to publish version updates as new key issues arise and principals bring their concerns and solutions to the Programmatic Governance Council."

The public comment process

The document is open for public comment through October 16, 2026, a 30-day window from its September 16 release, according to the IAB Tech Lab's Programmatic Standard Practices page. The organization states that feedback, suggestions and questions should be sent to support@iabtechlab.com, and that IAB Tech Lab and the Programmatic Governance Council "will use industry feedback to inform the work as the Council continues its cross-industry collaboration on programmatic governance."

The document itself carries a Creative Commons Attribution Non-Commercial No-Derivatives license, meaning it may be shared but not commercially reused or altered without permission. It is drafted under the Programmatic Governance Council, whose membership list IAB Tech Lab maintains separately on its own site.

Because the document sets out recommended practices rather than a binding technical specification, adoption depends on voluntary participation from buyers and sellers across the supply chain rather than on any enforcement mechanism embedded in the document itself. That distinguishes it from a protocol update to OpenRTB, which changes what a bid request can technically contain, or from a policy change like PubMatic's Excess Inventory Fee, which attaches a direct financial cost to noncompliant behavior on that platform specifically. The Best Practices document instead asks the industry to align voluntarily around a shared definition of acceptable behavior, backed by the credibility of a council whose founding members include major buyers and sellers on both sides of the transactions the guidance addresses.

Why this matters for the marketing community

For advertisers, agencies and publishers who transact programmatically, the practical stakes described across the document's sections connect to a cost structure that recent measurement has begun to quantify. If a meaningful share of auction volume represents the same opportunity entering the bidstream more than once, as DataBeat's 46 percent duplicated-domain figure suggests for established supply-side platforms, then a portion of the infrastructure cost buyers and sellers both absorb is generated by requests that could never have produced an incremental sale, because they were never a distinct opportunity to begin with.

That cost has already begun to surface in commercial terms rather than remaining a purely technical concern. PubMatic's Excess Inventory Fee put a direct price on request volume for the first time among major supply-side platforms. Amazon's decision to place its Dynamic Traffic Engine under industry-wide governance, rather than keeping it as a proprietary tool, suggested that at least one major buyer viewed the duplication problem as significant enough to warrant a shared, rather than platform-specific, solution. Publisher-side throttling at companies including Chegg and the Daily Mail indicates the pressure has been felt independently on the sell side as well, well before this document's release.

What the Programmatic Best Practices document adds to that pattern is an attempt at a shared definition. Rather than each company addressing duplication through its own fee structure, filtering tool or throttling threshold, applied inconsistently and often without visibility to counterparties, the council is proposing common terminology, specifically the distinction between variation and replication, and common expectations, such as respecting bid and impression expiration windows and declaring identifier bridging rather than performing it silently. Whether that shared framework changes measured duplication rates in the months following its finalization, expected after the October 16 comment period closes, will depend on how many buyers and sellers beyond the council's founding members choose to implement it, and how IAB Tech Lab and the council address the specification limitations the document itself acknowledges still make some duplication unavoidable.

Timeline

Summary

Who: The Programmatic Governance Council, a body formed by the IAB Tech Lab on April 21, 2026 and co-chaired by Scott Both of Hearst, Huda Kazi of Warner Bros. Discovery, Harry Wilkins of Zynga and Ben Hovaness of Omnicom Media Group, with founding members including Omnicom, WPP, Dentsu, Disney, Amazon Ads, The Trade Desk, Magnite, PubMatic, Hearst, News Corp, Yahoo, Raptive and Mediavine.

What: The council released Programmatic Best Practices version 1.0, a set of voluntary operational guidelines covering support for existing IAB Tech Lab standards, supply chain accounting through the schain object, bid caching and pooling limits, placement identifier discipline, truthful ad refresh declaration, restrictions on duplicate bid requests, and request integrity rules against silent identifier bridging.

When: The document was released for public comment on September 16, 2026, with the comment period closing October 16, 2026.

Where: The guidance applies globally across the programmatic advertising supply chain, addressing behavior among publishers, supply-side platforms, demand-side platforms, header bidding wrappers and server-side auction partners.

Why: The document targets bid request duplication and related inefficiencies that independent measurement, including DataBeat's finding of a 46 percent duplicated-domain rate among established supply-side platforms, has linked to elevated infrastructure costs across the supply chain, costs that have already prompted commercial responses including PubMatic's excess inventory fee and Amazon's donation of its Dynamic Traffic Engine to the same standards body now publishing this guidance.