Offsite ads are ads bought on inventory that is offsite from the buyer’s perspective. A platform or demand-side platform (DSP) receives an ad opportunity from a publisher-side path, decides whether one of its advertisers should bid, and returns either a bid response or a no-bid.
Offsite inventory is a relative term. For the publisher, the same slot is onsite inventory because it lives on the publisher’s own page, app, video player, or native surface. For the buyer-side platform, it is offsite inventory because the buyer can bid on the opportunity but does not own the surface that will render the ad. The buyer can still use advertiser budgets, bids, creatives, prediction models, and conversion signals; it does not control the page or app.
Where It Lives
Offsite buying lives in the open-web side of Advertising Marketplace Players. The seller side starts with inventory on a publisher-owned surface and usually routes that opportunity through a sell-side platform (SSP) or exchange path. The buyer side receives a bid request, evaluates demand, and returns a bid response.
| Role | What it controls in one offsite opportunity |
|---|---|
| Publisher | The page, app screen, video player, or native surface where the ad can render; from the publisher’s perspective, this is its onsite inventory. |
| SSP or exchange path | Packaging, floor price, routing, timeout, winner selection, and seller-side notices. |
| Buyer-side bidder / DSP | Campaign lookup, budget/frequency checks, bid decision, creative choice, and buyer-side logging. |
| Advertiser | Budget, bid strategy, creative, targeting, and measurement configuration. |
| Measurement parties | Viewability, fraud, app attribution, conversion events, or advertiser-owned outcome streams. |
OpenRTB is the common protocol shape for this path. An OpenRTB bid request describes one seller-side opportunity: publisher/app, placement, size, media type, floor price, device, geography, privacy flags, and allowed user/context signals. An OpenRTB bid response says whether the buyer will bid, what price it offers, which creative or markup it wants to serve, and which tracking or billing fields the seller should call later.
One Bid Path
The diagram shows one offsite bid path. The buyer-side bidder can use its own demand and models, but the publisher-side path owns the surface, auction routing, render path, and many of the later notices.
RunCo sells running shoes through a DSP. A user opens a news article. The news publisher has a native slot beside the article and exposes that slot through its SSP.
- The publisher creates the opportunity. The article page or app screen has a slot that may contain an ad. This is publisher-owned inventory. It is onsite for the publisher and offsite for the buyer-side bidder.
- The SSP or exchange path sends a bid request. The request describes the slot, floor price, media type, publisher/app context, device, geography, and privacy constraints.
- The buyer-side bidder evaluates demand. It looks up advertiser campaigns that could serve, checks budget and frequency state, applies privacy and publisher restrictions, predicts value, and chooses bid or no-bid.
- The bidder returns a response. A bid response can contain price, creative metadata or markup, advertiser domain, category attributes, and tracking fields. A no-bid says the buyer declines this opportunity.
- The seller-side path selects the winner. The buyer can bid and still lose because another buyer offered more, because the bid missed the floor, or because the response arrived after the timeout.
- The publisher renders the winning creative. If this buyer wins, the render still happens on the publisher-owned surface.
- Later notices and events close the loop. Win notices, billing notices, impression trackers, click trackers, conversion streams, and reconciliation jobs update spend and reporting.
Why This Is Different From Onsite Serving
Onsite serving means the platform owns the surface and the ad stack for that opportunity. A promoted card inside the platform’s own feed is onsite inventory. The same company can create the ad slot, choose ad load, run retrieval/ranking/auction, return render instructions to its own client, and measure the result through first-party logs.
Offsite bidding moves the surface boundary. The buyer-side system can still use the advertiser’s campaign, budget, creative, and models, but it receives an externally created opportunity under seller-side timeouts and protocol fields. A timeout means no bid reaches the seller-side auction. A seller-side block can reject a valid buyer response. A winning bid can fail to become a billable event if render or billing notices do not complete.
| Question | Onsite inventory | Offsite inventory |
|---|---|---|
| Who owns the user surface? | The same platform that is running the onsite ad stack. | A publisher or app developer; the buyer-side bidder does not own it. |
| Who creates the ad opportunity? | The platform’s product surface. | Publisher/SSP path. |
| Who sends the request to the buyer? | Usually no external buyer request; the platform calls its own serving stack. | SSP or exchange path sends a bid request. |
| Who renders the creative? | Platform-owned client or page. | Publisher-owned client or page. |
| What can break after bid decision? | Client render, measurement, billing events. | Timeout, seller blocks, winner selection, render, notices, measurement, billing events. |
Buyer-Side Work Inside The Bidder
The bidder has a stricter latency envelope than an onsite serving path because the network hops consume part of the auction deadline. It usually cannot run an expensive full-stack decision for every bid request. That pressure shapes the implementation:
| Step | What the bidder does |
|---|---|
| Request normalization | Translate OpenRTB fields into internal request facts: media type, placement, publisher/app, floor, privacy state, and user/context identifiers allowed for ads. |
| User and context matching | Map request identifiers or contextual facts to audience, frequency, retargeting, or conversion signals when policy permits. |
| Demand retrieval | Find advertiser campaigns that can buy this publisher/media/context combination. |
| Budget and frequency checks | Remove demand that cannot spend, has hit caps, or is blocked for this publisher/user/context. |
| Scoring and bid choice | Estimate value and choose a bid price, creative, and response metadata. |
| Response shaping | Convert the internal decision back into OpenRTB response fields and trackers. |
The bidder pays infrastructure cost for requests it loses. Traffic quality, duplicate supply paths, request filtering, and timeout management become economic questions because they change both infra spend and reachable auction value.