OpenRTB loss reason 206 changed from an app bundle exclusion to a store ID exclusion.

A loss dashboard that labels 206 as an app bundle exclusion is reading the OpenRTB 2.5 table. A bidder that labels the same integer as a store ID exclusion is reading the current list. Both integrations are following a published spec. They are following different editions.

What 2.5 printed

OpenRTB 2.5 section 5.25 introduced the loss reason list. In that table, 206 is Creative Filtered - App Bundle Exclusions. The list ends at 213, Creative Filtered - Not Allowed in PMP Deal. There is no 214 and no 215. Exchange-specific values start at 1000.

If your exchange integration was written against that PDF and never updated, a blocked bundle still arrives as 206.

What the current list says

In September 2021 the OpenRTB 3.0 list renamed 206 from Bundle to App Store ID Exclusions, and added 215 for App Bundle Exclusions. The change log describes the rename as keeping 206's intent consistent across 2.x and 3.x. The printed 2.5 table still says bundle. Treat the September 2021 list as the current definition, and treat a partner who cites 2.5 as still on the older one.

OpenRTB 2.6 does not print its own loss list. The ${AUCTION_LOSS} macro in 2.6 points at the OpenRTB 3.0 table. On that table:

• 206 is Creative Filtered - App Store ID Exclusions. The exchange compared the promoted app's store id, bid.bundle, with bapp or a publisher block. Play ids are package names. Apple ids are numeric.
• 215 is Creative Filtered - App Bundle Exclusions. This is the condition 2.5 reported as 206.

The current list also marks exchange-specific values at 500 and above, where 2.5 marked them at 1000 and above.

What to do with a 206 in production

Ask the exchange which list it implements before you build the alert. An exchange on the current list is telling you the store id was excluded, and a bundle exclusion from that same exchange arrives as 215. An exchange still on the 2.5 table is telling you the bundle was excluded, and it will not send 215 at all.

Drop the blocked id from the campaign on that inventory, and check the id format before you call it a policy block. A Play package name and an Apple numeric id are both legal bid.bundle values, and a block on the wrong form looks like a 206 when the campaign was never going to match.

The loss reason 206 page and the loss reason 215 page spell out the field each code checks. The loss reason code table is the current list, with the 2.5 difference called out above the range notes.

The other codes worth splitting out

Once 206 and 215 are labeled against the right list, the rest of a falling win rate sorts by range. These four are the ones that usually explain the drop, and each one names the field to inspect:

• 100 compares bid.price with imp.bidfloor in imp.bidfloorcur. The request cur array does not set the floor currency. A yen floor sent without JPY is read as USD.
• 102 is a loss to a higher bid. ${AUCTION_MIN_TO_WIN} on the loss notice, when the exchange fills it, is the price that would have won.
• 203 is a size mismatch against banner.w and banner.h, or any pair in banner.format.
• 212 is an animation longer than the placement allows. The request does not carry that limit. It lives in the creative policy, and a looping banner keeps drawing 212 until the creative changes.

202 and 207 sit in the same creative range: a crid the exchange already disapproved, and an http URL inside a creative served where imp.secure is 1.