Answers
OpenRTB answers
10 questions that come up constantly in ad tech, each with its own page and a direct answer in the first paragraph. Shorter than a guide, longer than an FAQ entry, and grounded in the field names the specification actually uses. For step-by-step walkthroughs, see the guides.
Money and supply path
Where the money goes on the way to the impression, and who decides the price.
Supply path optimization is a buyer's practice of deciding which intermediaries to buy an impression through, then cutting the rest. The same impression is usually offered by several exchanges and resellers at once, at different prices and fees, so buyers compare paths on cost, win rate, and how verifiable the seller chain is, then concentrate spend on the shortest defensible path. In OpenRTB the evidence for that decision lives in source.schain, cross-checked against the publisher's ads.txt and each intermediary's sellers.json.
Full answer →Bid shading is a buy-side pricing technique that submits a bid below the buyer's true maximum, estimating the lowest price that still wins. It exists because the industry moved from second-price to first-price auctions: under first price (OpenRTB at=1) the winner pays exactly what it bid, so bidding your full valuation means overpaying on every win. OpenRTB has no bid shading field. The model lives inside the DSP and is trained on auction feedback, mainly loss notices (lurl) carrying ${AUCTION_MIN_TO_WIN} and loss reason codes.
Full answer →Curation is the packaging of inventory plus data into a ready-to-buy deal, assembled on the sell side by a curator: a data company, an agency, a retail media network, or the SSP itself. The buyer sees one deal ID; the audience segments and inventory filters behind it are applied upstream, before the request is sent. In OpenRTB a curated deal arrives as an ordinary entry in imp.pmp.deals with no marker saying it was curated, which is exactly why curation is hard to audit. IAB Tech Lab's Curation object addresses that in the separate Deal Sync API, not in the bid request.
Full answer →MFA stands for made for advertising: sites and apps built to monetise acquired traffic rather than to serve an audience. The tells are commercial, not technical: very high ad density, auto-refreshing slots, slideshow or clickbait content, and paid traffic acquisition. Nothing in OpenRTB marks a request as MFA, and MFA inventory usually passes ads.txt, sellers.json, and payload validation cleanly, so buyers filter it with inventory lists and quality vendors, using signals like imp.refresh, site.cat, and per-domain performance to build those lists.
Full answer →Debugging
Questions that start with something not working.
A bidder is one HTTPS endpoint that accepts a POSTed JSON bid request and returns a bid response before tmax expires. The minimum viable implementation parses the request, decides on each imp, and returns either HTTP 200 with a BidResponse whose id echoes the request id and whose bids carry impid, price, mtype, and adm or nurl, or HTTP 204 with no body to pass. Everything else, targeting, pacing, shading, sits behind that contract. The hard parts are latency (your compute budget is tmax minus network round trip) and honouring what the request declares: cur, wseat, bcat, badv, and privacy signals.
Full answer →Low fill means bidders are getting your requests and passing, so the question is which filter they hit. Check in this order: floors set above the market clearing price; missing or malformed required fields, which get a request dropped before it is ever priced; stale media-type signalling, above all video.placement without video.plcmt; privacy signals that are absent or self-contradictory, which make buyers drop EEA traffic; a tmax too tight for the path; and blocked categories, advertisers, or seats. Validate one real request before reading any dashboard.
Full answer →Trust and privacy
What a bid request claims about a person, and how much of it is checkable.
ID bridging is populating a device or user identifier in a bid request with one that was not actually observed on that impression: reusing a stale IFA, filling device.ifa on inventory that cannot legitimately carry one, or passing a probabilistic household match as if it were deterministic. The buyer sees a targetable, cappable identifier and pays accordingly; what it bought was a guess. No validator can detect it from a single payload, but the EID provenance fields added in OpenRTB 2.6-202409 (inserter, matcher, mm) plus consistency between device.ifa, lmt, and dnt make the origin of an ID inspectable.
Full answer →For a typical bid request, yes. GDPR Article 4(1) counts online identifiers as personal data, and an ordinary OpenRTB request carries several: device.ifa or cookie-derived ids in user.eids, device.ip or ipv6, geo coordinates, and the page or app being viewed, all attached to one browsing event. In 2024 the Court of Justice of the EU held in C-604/22 that even the TCF consent string is personal data when it can be combined with an IP address. This is engineering guidance, not legal advice.
Full answer →Have a payload rather than a question?
Paste it into the bid request tester. It validates against the OpenRTB snapshot you pick, entirely in the browser, and every finding names the rule id and the JSON path. The same checks run from the CLI, an MCP server for AI agents, and the JSON Schemas.