Server-side bidding is familiar to web ad ops teams, but in apps it works under different constraints: no browser, variable mobile networks, platform privacy rules and an SDK that has to render whatever wins. Prebid Server is a common way to bring open, competitive bidding into apps. This post walks through how an SDK and Prebid Server work together, step by step, and what to watch when you run it.
Why server-side bidding suits apps
In a browser, header bidding can call several bidders directly from the page. In an app, doing the same would mean each bidder’s code living inside the app, or the app making many parallel network calls over a mobile connection. Both are poor fits.
Server-side bidding moves the auction off the device. The app sends a single request to a server, the server calls bidders in parallel over fast data center connections and returns the result. The device does less work, the request is smaller and adding bidders happens on the server rather than in the app.
Prebid Server is the open-source server-side component of the Prebid project, and it supports app traffic alongside web. Publishers can run it themselves or use a hosted version through a provider.
The moving parts
A working in-app setup has a few components:
- The SDK in the app: collects placement, app and device information, builds the bid request, and renders or hands off the winning ad.
- Prebid Server: receives requests, expands stored configuration, runs the auction across bidders and returns bids.
- Bidders: demand partners connected to Prebid Server through adapters, each receiving an OpenRTB request (the IAB Tech Lab standard format for real-time bidding).
- A creative cache: stores winning ad markup or VAST video responses on the server side, so the app can fetch them by reference.
- A primary ad server (optional): some setups pass Prebid results into an existing ad server so bids compete with direct deals and other demand.
How a request flows, step by step
Here is the typical sequence for a single placement.
- The app reaches an ad moment. A screen loads, a video starts or a user taps a rewarded offer. The SDK prepares a request for that placement.
- The SDK sends a compact request. Rather than listing every bidder and parameter, the request usually refers to stored configuration by ID. It includes app details (such as the bundle ID), device information, the ad format and size, and privacy signals.
- Prebid Server expands the stored request. The server looks up the configuration for that account and placement: which bidders to call, their parameters, floors and timeout settings.
- Bidders are called in parallel. Each bidder receives an OpenRTB request describing the impression, the app and the device. Bidders that do not answer within the timeout are dropped from that auction.
- The auction resolves. Prebid Server collects valid bids and determines the winner, or returns the top bids for the ad server to decide.
- Creatives are cached. Winning markup or VAST is stored in the cache and the response includes a reference to it.
- The SDK renders or hands off. Either the SDK renders the winning ad directly, or it passes bid values as targeting keys to the primary ad server, which selects the final ad.
- Events are reported. Impression, win and video tracking events fire so bidders and the publisher can reconcile what ran.
Because bidder lists and parameters live in stored configuration, publishers can add or remove bidders without shipping a new app version.
Privacy signals have to travel with the request
In apps, the SDK is the only place privacy information exists, so it must pass that information accurately to Prebid Server, which forwards it to every bidder. The main signals are:
- Consent strings under the IAB Transparency and Consent Framework in Europe, and applicable US privacy signals where required.
- Platform tracking permission. On iOS, whether the user allowed tracking under Apple’s App Tracking Transparency determines whether the advertising identifier can be sent.
- Limit ad tracking and advertising ID status on Android and iOS.
- Child-directed flags for apps or users covered by children’s privacy rules.
- Attribution framework data, such as Apple’s SKAdNetwork information, so advertisers can measure installs in a privacy-preserving way.
A missing or wrong signal can cause bidders to ignore requests, or worse, receive data they should not. Test consent states explicitly, including the case where a user declines.
Latency, timeouts and rendering
Mobile networks vary more than office broadband, and apps have little patience for slow ads. A few practices keep auctions fast:
- Set realistic timeouts. Too long and users wait; too short and good bidders get dropped. Review timeout settings against actual bid response times per bidder.
- Trim slow or low-value bidders. Every bidder adds work to each auction. Remove those that rarely win or often time out.
- Load ahead for full-screen formats. For rewarded and interstitial ads, request in advance so the ad is ready when the moment arrives.
- Watch cache expiry. Cached creatives expire. If the app shows an ad long after the auction, the creative may be gone or the bid may no longer be valid.
- Verify rendering by format. Test banner, native and VAST video responses from each bidder, since markup that works on one partner’s test page may not render correctly in your app.
What to monitor once it is live
Server-side setups can hide problems if you only look at total revenue. Track these by bidder and placement:
- Bid rate, win rate and timeout rate.
- Render rate: how many won auctions actually displayed.
- Discrepancies between Prebid results and bidder or ad server reports.
- Revenue and fill changes after configuration updates.
- Invalid traffic flags and creative quality issues.
For the general comparison of client-side and server-side auctions on the web, our earlier post on header bidding covers the basics; the points above are specific to apps.
Key takeaways
- Server-side bidding fits apps because it moves the auction off the device and keeps requests small.
- An in-app setup combines an SDK, Prebid Server, bidder adapters, a creative cache and sometimes a primary ad server.
- Stored configuration lets publishers change bidders without app releases.
- Privacy signals from the app must reach every bidder accurately, including declined consent.
- Tune timeouts, preload full-screen ads and monitor render rates and discrepancies per bidder.
If you are planning Prebid Server for your app and want a second pair of eyes on the setup, get in touch with Vortex Media.
