If your site runs programmatic advertising, some of the bid requests leaving it are near copies of each other. Not fraud, usually. Just the shape the pipes grew into over fifteen years, one integration at a time, with nobody holding the pen.
On 16 September the IAB Tech Lab published the first draft of a document that tries to hold the pen. It is called Programmatic Standard Practices v1, it comes from the Tech Lab's Programmatic Governance Council, and it is open for public comment until 16 October. That is six days away.
It does not invent anything
Worth saying early, because the word "standard" makes people brace. This is not a new specification to implement. It is a description of how buyers and sellers should use the standards that already exist, the ones your partners already claim to support. OpenRTB, ads.txt, sellers.json, the supply chain object. All present, all years old, all applied inconsistently enough that the Tech Lab felt the need to write down what applying them properly looks like.
It also has no teeth. Nobody will be fined. What it creates is a yardstick, and yardsticks matter in this business, because the buyers deciding whether your inventory is worth bidding on will reach for whatever yardstick exists.
Replication is the one with a flat answer
The draft draws a line between two things that look identical in a log file.
Variation is several requests for the same opportunity travelling different paths, each carrying materially different information. A buyer learns something from each one. That is permitted, and it is how header bidding has always worked.
Replication is exact clones, or requests whose differences are immaterial. The same impression counted again, telling the buyer nothing it did not already know. On this the document does not hedge. It says plainly: "Do not engage in replication."
Then there is fan out, which is the one worth understanding properly, because it is the one most likely to be happening to your inventory without your knowledge.
One request goes out carrying an array. Somewhere downstream that array gets split into separate requests. One impression on your page arrives at a buyer four times. The buyer is not fooled for long. It concludes supply is abundant and bids accordingly, and the thing that absorbs the difference is your CPM.
Where duplication genuinely cannot be avoided, the draft asks that it be kept small, additive, and visible to the systems downstream, rather than hidden inside the pipe.
Bid caching keeps its two conditions
Bid caching means holding a bid response and applying it to a later auction for a different opportunity than the one it was solicited for. The draft does not ban it. It fences it.
A bid held past its expiry, signalled by imp.exp or bid.exp, is dead and should not be applied. And a cached bid may only cross placements that are materially the same, not whatever slot happens to be free. Bid pooling, the sibling practice of organising several valid bids inside one content session or pod, carries the same two conditions.
One placement, one identifier
Sellers should send exactly one placement or pod identifier for each unique placement in a given context. No generating more request identifiers than there are actual placements.
The specific habit it names is rotating identifiers across one placement that supports several formats. A slot takes banner, video and native, so it goes out three times under three identifiers, and a buyer counts three placements where you have one. OpenRTB has supported multiformat impression requests for years. The draft would rather you used them.
Refresh has to be declared honestly
If a slot refreshes, say so in the OpenRTB Refresh object, and say so accurately. The auction should then be timed to the declared minimum refresh interval, so bidding does not run several times more often than the advertisement actually changes. This is one of the few items in the document that sits squarely inside a publisher's own control.
What it asks of you specifically
Most of the draft binds the companies between you and the buyer. A handful of items land on the seller, and two of them are things we have written about before.
Keeping ads.txt and sellers.json current is named directly. If you have not looked at your file since you added a partner, the mistakes that quietly cost independent publishers money are worth half an hour. The supply chain object should ride in every bid request, so a buyer can see the whole path rather than the first two hops. Identifiers should not be altered in transit, and where identity bridging happens it should be declared in the eids object. Absent an arrangement you agreed to, no party in the chain should be overwriting or stripping attributes out of your requests.
Why bother, when none of it is enforceable
Because the alternative to a shared yardstick is the current situation, where every partner describes its own behaviour as normal and you have no standing to argue. A document you can point at changes the conversation with a partner from a matter of opinion to a matter of record.
And because the practical move here costs you nothing. Ask each partner one question: which of these practices do you already comply with? The answer, including an evasive one, tells you something useful about where your inventory goes after it leaves you.
Six days, and almost nobody like you is commenting
Comments go to support@iabtechlab.com and the window closes on 16 October. The Tech Lab has said feedback from this period will inform the Governance Council's future work.
The companies with standards teams have already read it. Independent publishers, who carry most of the cost when a single impression turns into five bid requests, are the quietest voice in a process that is about to describe what normal looks like. If any of this matches what you see in your own reporting, that is worth a paragraph in an email.
