Running Prebid Server in production

0:00Welcome, outcomes and key terms

Play from 0:00 Your app team needs to change a bidder's placement ID tonight. The app store review will take days.

Play from 0:06 And your AMP pages can't run Prebid.js at all.

Play from 0:10 Both problems have the same answer, and it lives on Prebid Server. In Module 3 you saw how one Prebid Server auction works. Now we run it for real.

Play from 0:20 Welcome back to the RediAds Academy Header Bidding Masterclass. This is Module 4: Running Prebid Server in production.

Play from 0:32 By the end of this module, you'll be able to do four things.

Play from 0:36 Explain what Prebid Cache does, and set a cache time-to-live that won't give you blank ads.

Play from 0:42 Build a stored request, and check exactly what Prebid Server made of it.

Play from 0:47 Trace a header bid through an AMP page and through an app.

Play from 0:51 And size, cost and choose a Prebid Server set-up, self-hosted or managed, with a checklist you can take into the meeting.

Play from 1:02 Eight terms first. Each one comes back with an example.

Play from 1:06 Prebid Cache stores creatives so they can be fetched when the ad renders. hb_cache_id is the key-value that carries a cached creative's ID to the ad server. TTL, time-to-live, is how long the cache keeps it. A stored request is configuration kept on the server and merged into incoming requests.

Play from 1:31 The resolved request is what Prebid Server actually builds after that merge. A stored response is a saved answer, used for testing. rtc-config is the part of an AMP ad tag that calls Prebid Server. And a managed host runs Prebid Server for you.

Play from 1:52 Here's where we are. Module 3 was how a hybrid auction works. Module 4 is running it in production. After this, Modules 5 and 6 set up Google Ad Manager to use your bids, including creatives that read from the cache.

2:10Prebid Cache

Play from 2:10 Chapter one: Prebid Cache. A small service that quietly makes video, AMP and apps work.

Play from 2:20 In Module 2, the winning creative waited inside Prebid.js on the page, ready to render. That doesn't always work.

Play from 2:29 A video player doesn't want ad markup. It wants a URL that returns VAST XML.

Play from 2:35 An AMP page only gets key-values back from Prebid Server. There's no Prebid.js on the page to hold the creative.

Play from 2:43 And in an app, carrying every creative around in memory, just in case it wins, is wasteful.

Play from 2:50 All three need the same thing: store the creative once, and pass a short pointer instead. That's Prebid Cache.

Play from 3:00 You ask for caching in the request to Prebid Server, under ext dot prebid dot cache.

Play from 3:12 ``json "ext": { "prebid": { "targeting": { "includewinners": true }, "cache": { "bids": { "ttlseconds": 300 }, "vastxml": { "ttlseconds": 300, "returnCreative": false } } } } ``

Play from 3:24 bids caches the whole winning bid, including its markup. The ID comes back as the key-value hb_cache_id.

Play from 3:34 vastxml caches only the VAST XML of video bids. That ID comes back as hb_uuid.

Play from 3:44 ttlseconds says how long the cache should keep it. returnCreative, false, leaves the creative in the cache but out of the response, which saves bandwidth.

Play from 3:55 One catch: caching does nothing unless targeting is also set in the request. Prebid Server returns the cache location as key-values, so it needs targeting switched on.

Play from 4:09 Let's follow one cached creative.

Play from 4:12 Prebid Server stores the winning creative in Prebid Cache, and gets back a unique ID.

Play from 4:18 That ID travels to the ad server as a key-value, hb_cache_id, next to hb_pb and hb_bidder. Two more keys, hb_cache_host and hb_cache_path, say where the cache lives.

Play from 4:38 In Google Ad Manager, the Prebid line item wins. Its creative, the Prebid Universal Creative, uses those three values to fetch the creative from the cache.

Play from 4:49 And renders it. For video, the player fetches the VAST XML from the same kind of URL instead.

Play from 4:58 Prebid Cache is a separate, open-source service with a very small job.

Play from 5:03 Writes are a POST to slash cache, with one or more values, each either XML or JSON. It answers with a UUID for each one.

Play from 5:15 Reads are a GET to slash cache, question mark uuid equals that ID.

Play from 5:21 Behind it sits a fast store such as Redis, Aerospike, Cassandra or Apache Ignite. The cache servers themselves need very little CPU or memory. The store does the real work.

Play from 5:37 How long should the TTL be? These numbers are illustrative.

Play from 5:41 The rule: the TTL must outlast the longest normal gap between auction and fetch. If your player sometimes fetches its VAST four minutes after the auction, a sixty-second TTL means blank ads on those plays.

Play from 5:57 But a longer TTL costs memory. The store holds roughly writes per second, times TTL, times object size. Fifty writes a second, for three hundred seconds, at five kilobytes each, is about seventy-five megabytes.

Play from 6:14 Raise the TTL to an hour and it's about nine hundred megabytes, for the same traffic.

Play from 6:19 And the TTL is best effort, with a maximum set by the host. Treat it as a target, not a promise.

Play from 6:29 Three Prebid Cache mistakes we see.

Play from 6:32 One: a TTL copied from an example, shorter than the real gap to render. You get blank ads that look like a creative problem.

Play from 6:42 Two: assuming the cache keys are always there. If the cache is full or unreachable, Prebid Server can leave hb_cache_id out, and your Ad Manager line items that target it won't match.

Play from 6:57 Three: testing a cached creative by pasting an old cache URL into a browser. It's probably expired. Run a fresh auction, then fetch.

Play from 7:08 Quick check. Pause the video if you want to think.

Play from 7:16 Some video ads served through Prebid Server render blank. The player fetches the VAST a few minutes after the auction. Which setting do you review first?

Play from 7:23 ttlseconds, in the cache request. If the cached VAST expires before the player asks for it, the ad is blank.

7:33Stored requests and stored responses

Play from 7:34 Chapter two. The feature ops teams come to rely on most: stored requests. Then their testing twin, stored responses.

Play from 7:45 Here's the idea.

Play from 7:46 The incoming request is thin. It carries the page or app details, the ad slots, and an ID.

Play from 7:54 On the server, that ID points to stored JSON: the bidders, their params, price granularity and caching settings.

Play from 8:02 Prebid Server merges the two into one complete OpenRTB request before it calls a single bidder.

Play from 8:10 There are two levels. A top-level stored request holds settings for the whole request. An impression-level one holds one slot's bidders.

Play from 8:21 Let's build one for The Monsoon Times. IDs and params are illustrative. Here's what arrives from the page or app.

Play from 8:43 ``json { "id": "req-7781", "site": { "page": "https://monsoontimes.example/markets/sensex" }, "imp": [{ "id": "div-mpu", "banner": { "format": [{ "w": 300, "h": 250 }] }, "ext": { "prebid": { "storedrequest": { "id": "monsoon-mpu" } } } }], "ext": { "prebid": { "storedrequest": { "id": "monsoon-web" } } } } ``

Play from 9:05 Inside the impression, a stored request ID: monsoon dash mpu. That's this slot's settings.

Play from 9:13 At the top level, another ID: monsoon dash web, for settings shared across the site.

Play from 9:19 Notice what's missing: not a single bidder. Everything live is here, the page, the slot and its size. Everything ops controls is on the server.

Play from 9:32 Here's monsoon dash web, stored on the server.

Play from 9:42 ``json { "cur": ["USD"], "ext": { "prebid": { "targeting": { "pricegranularity": "medium", "includewinners": true }, "cache": { "bids": { "ttlseconds": 300 } } } } } ``

Play from 9:51 The currency. The price granularity Prebid Server should use for hb_pb. And caching, so the winner gets an hb_cache_id.

Play from 10:01 None of this is about one slot. Change it once, and every request that points here picks it up.

Play from 10:12 And monsoon dash mpu.

Play from 10:24 ``json { "ext": { "prebid": { "bidder": { "sovrn": { "tagid": "403370" }, "ix": { "siteId": "300" }, "pubmatic": { "publisherId": "156209", "adSlot": "mpu_300x250" } } } } } ``

Play from 10:36 Three bidders, each with its params. It's the same block you saw in Module 3's request walk-through, except it now lives on the server.

Play from 10:46 To add a fourth bidder, you edit this record. No page release, and for an app, no app store update.

Play from 10:54 Prebid Server puts it together.

Play from 11:24 ``json { "id": "req-7781", "cur": ["USD"], "site": { "page": "https://monsoontimes.example/markets/sensex" }, "imp": [{ "id": "div-mpu", "banner": { "format": [{ "w": 300, "h": 250 }] }, "ext": { "prebid": { "bidder": { "sovrn": { "tagid": "403370" }, "ix": { "siteId": "300" }, "pubmatic": { "publisherId": "156209", "adSlot": "mpu_300x250" } } } } }], "ext": { "prebid": { "targeting": { "pricegranularity": "medium", "includewinners": true }, "cache": { "bids": { "ttlseconds": 300 } } } } } ``

Play from 11:53 The live parts from the page. The slot's bidders from the stored impression. And the site settings from the stored top-level request.

Play from 12:02 This is what the bidders' adapters actually work from. And you can see it for yourself.

Play from 12:09 Here's how.

Play from 12:10 Send a request with test equals one at the top level. Prebid Server's response then includes ext dot debug dot resolvedrequest: the request after stored data has been merged in.

Play from 12:24 From Prebid.js, you can set that with the ortb2 config: test, one.

Play from 12:30 Use it whenever a stored field and a live field could overlap. Don't work out from memory which one wins. Look at the resolved request.

Play from 12:40 And switch test off afterwards. Bidders treat test requests as non-billable.

Play from 12:47 Where does monsoon dash mpu actually live?

Play from 12:50 In files on each server, which is fine for testing. In a database, usually, shared by every Prebid Server and replicated to each region. Or behind an HTTP service.

Play from 13:04 Prebid Server caches them in memory, and only goes back to the source for new or stale ones. That's fast, but an edit can take a while to reach every server. Check the refresh settings before you promise "instant".

Play from 13:19 And one detail from the Go version: stored data isn't applied recursively. If a stored request contains impressions with their own stored IDs, those inner IDs won't be resolved.

Play from 13:32 So who edits stored requests, and with what?

Play from 13:37 Prebid Server doesn't ship an editor. Prebid's own hosting guide says there are no open-source tools for populating that database. Hosts build their own interface or API.

Play from 13:50 If you self-host, that's a tool your team builds and maintains.

Play from 13:55 Either way, treat stored requests like code. Keep the JSON in version control, review changes, and keep a way to roll back. One wrong param in a shared record breaks every slot that points at it.

Play from 14:11 Stored responses are the testing twin. Instead of storing configuration, you store answers.

Play from 14:18 A stored auction response replaces the whole result for an impression. No bidder is called at all. That's ideal for checking your Ad Manager set-up and rendering with a known, repeatable bid.

Play from 14:31 A stored bid response is narrower. The auction runs, but for the bidders you name, a saved response is fed through their adapter. It's how you test one adapter's parsing without waiting for real demand.

Play from 14:45 The Prebid Mobile SDK's test config IDs work this way too. None of these belong in normal production traffic.

Play from 14:54 Three stored request mistakes we see.

Play from 14:57 One: one stored impression shared by every placement, to save time. Then someone edits it for the homepage, and the app changes too. Give each placement its own record.

Play from 15:10 Two: editing a record and checking the result straight away. The servers may still be using their cached copy. Wait for the refresh, or check the resolved request on a few servers.

Play from 15:22 Three: leaving a stored auction response ID on a live ad unit after testing. Every reader sees the same test bid, and no real bidder is called.

Play from 15:33 This version of The Monsoon Times has no bidders on the page. Ask Prebid.js for the ad unit's bids: one entry, and its bidder is null.

Play from 15:43 Here's the request to Prebid Server. Two stored request IDs: one for this slot, one for the site. Nothing else about bidders.

Play from 15:52 Now the response. Because the page set test to one, Prebid Server sends back the resolved request. There are the three bidders and their params, pulled in from the stored impression. And price granularity and caching, from the site record.

Play from 16:12 Now let's make an ops change. We'll add rubicon to the stored impression. On a real host, this is their interface or your database; here it's one call to our mock. Reload the page. The page code hasn't changed at all. And the resolved request now has four bidders. Rubicon is in the auction.

Play from 16:31 Quick check. Pause the video if you want to think.

Play from 16:38 You edit a stored impression to add a bidder. Two minutes later, some page views show the new bidder and some don't. What's the likely reason?

Play from 16:45 Caching. Each Prebid Server keeps stored requests in memory and refreshes them on its own schedule. Until every server has refreshed, some auctions use the old copy.

16:59AMP and app SDKs

Play from 16:59 Chapter three. Two environments where Prebid Server isn't optional: AMP pages and mobile apps.

Play from 17:09 AMP doesn't let you run Prebid.js, or any custom JavaScript, on the page. So the auction has to happen somewhere else.

Play from 17:18 AMP's answer is real-time config, RTC. Before the AMP runtime asks the ad server for an ad, it can call out to a few vendors and add what they return to the ad request.

Play from 17:31 Prebid Server is one of those vendors, through a dedicated endpoint: slash openrtb2 slash amp.

Play from 17:41 Five steps.

Play from 17:43 One. The amp-ad tag carries an rtc-config telling the AMP runtime to call Prebid Server.

Play from 17:51 Two. The runtime calls slash openrtb2 slash amp, with a tag ID, the slot's size and the page URL.

Play from 18:00 Three. Prebid Server loads the stored request for that tag ID, adds what came in the URL, and runs the auction.

Play from 18:09 Four. It stores the winners in Prebid Cache, and returns only targeting key-values, including the cache ID.

Play from 18:17 Five. AMP adds those key-values to the Google Ad Manager request. If the Prebid line item wins, its creative fetches the winner from the cache and renders it.

Play from 18:29 Here's a simplified amp-ad tag, wrapped to fit the screen, in the form that works with any Prebid Server host.

Play from 18:35 ``html ``

Play from 18:40 tag_id is the stored request ID. Everything about bidders lives there.

Play from 18:45 Macros like ATTR width, CANONICAL_URL and CONSENT_STRING let AMP fill in the slot, the page and the consent string for you.

Play from 18:56 And timeoutMillis is how long AMP waits for this callout. Five hundred is the value in Prebid's own example.

Play from 19:08 Some large hosts are registered with AMP as named vendors, so their tags are even shorter. Because an AMP page can only send a tag ID, it's the clearest example of why stored requests exist.

Play from 19:20 The stored request behind that tag ID has a few rules.

Play from 19:24 It must contain exactly one impression, and no app object. One AMP slot, one stored request.

Play from 19:33 Inside: the bidders and their params on that impression, the price granularity, the currency, and your supply chain object.

Play from 19:41 And ext dot prebid dot cache dot bids. Without it, there's no cache ID, and the AMP creative has nothing to fetch.

Play from 19:52 What about identity on AMP? There's no Prebid.js to call slash cookie underscore sync.

Play from 19:59 Instead, you add a one-by-one amp-iframe that loads a small page from Prebid called load-cookie dot html. It runs the sync for Prebid Server.

Play from 20:11 The iframe needs a sandbox that allows scripts and same-origin. And AMP limits how many small iframes a page may have, so you may only get one.

Play from 20:22 If your page uses a consent tool and your host runs an older load-cookie page, Prebid's guide points you to a consent-aware version.

Play from 20:32 Apps follow a similar pattern, through the Prebid Mobile SDK for iOS and Android.

Play from 20:38 One. At start-up, the app initialises the SDK with your Prebid Server's address and your account ID.

Play from 20:47 Two. Each ad unit in the app is created with a config ID. That config ID is a stored request ID.

Play from 20:55 Three. The SDK sends an OpenRTB request to slash openrtb2 slash auction, the same endpoint Prebid.js uses. Prebid Server merges the stored request, calls the bidders and caches the creatives.

Play from 21:12 Four. With Ad Manager, the SDK adds the key-values to the ad request, and if Prebid wins, the creative comes from the cache. The SDK can also render the winner itself, or work through mediation.

Play from 21:27 So what can ops change without shipping a new app version?

Play from 21:31 Anything in the stored requests: bidders, params, price granularity and cache TTL.

Play from 21:38 What still needs a release: a new ad unit or format in the app, an SDK upgrade, and settings held in the app itself, like the SDK's own timeout.

Play from 21:50 That's a strong reason to design config IDs carefully up front. Each placement gets its own, even if two start with the same bidders.

Play from 22:00 Here are the three side by side.

Play from 22:03 On the web, Prebid.js calls slash openrtb2 slash auction. Bidder config lives on the page, or in stored requests.

Play from 22:13 On AMP, the AMP runtime calls slash openrtb2 slash amp. Bidder config lives only in stored requests.

Play from 22:23 In apps, the Prebid SDK calls slash openrtb2 slash auction. Again, bidder config lives in stored requests.

Play from 22:32 Same server, three front doors.

Play from 22:36 Three AMP and app mistakes we see.

Play from 22:40 One: an AMP stored request without the cache block. The auction runs, bids come back, and the ads render blank.

Play from 22:49 Two: shipping an app build with the SDK's test config IDs still in it. Every reader gets the same stored test response.

Play from 22:58 Three: trying to debug AMP from the AMP page. You can't get debug output there. Copy the slash openrtb2 slash amp call and run it yourself with debug equals one, which is exactly our next demo.

Play from 23:15 Here's the AMP tag from a moment ago. The only thing it tells Prebid Server about bidders is the tag ID.

Play from 23:27 AMP debug output isn't available on the AMP page, so let's do what the troubleshooting guide suggests: make the same call ourselves, with debug equals one. The answer is a targeting object, plus some debug detail because we asked for it.

Play from 23:38 Open targeting. hb_pb, hb_bidder, hb_size, and the cache ID, host and path. That's everything AMP will add to the Ad Manager request. There's no creative in here at all.

Play from 23:54 So let's do what the Prebid creative would do: use the host, path and cache ID to fetch the winner from Prebid Cache. And there it is: the price and the creative markup. Key-values to the ad server, creative from the cache.

Play from 24:11 Halfway. Pause the video if you like.

Play from 24:18 Your AMP pages show Prebid key-values in the Ad Manager request, and the Prebid line items win, but the ads are blank. Where do you look?

Play from 24:25 The cache. Check that the AMP stored request asks for ext dot prebid dot cache dot bids, that hb_cache_id is present, and that the cached creative still exists when the creative fetches it.

24:42Cost, capacity and latency

Play from 24:43 Chapter four. What it actually takes to run Prebid Server, how big it needs to be, and why location matters so much.

Play from 24:53 "Running Prebid Server" means more than one server.

Play from 24:57 A global load balancer, so each reader reaches the nearest region. Regional load balancers, which also handle the secure connections, because Prebid Server and Prebid Cache don't terminate SSL themselves.

Play from 25:11 The Prebid Servers, which mix network and CPU work. Prebid Cache, with its fast store behind it. And a replicated database for accounts and stored requests.

Play from 25:23 Monitoring for all of it. The Go version can report metrics to InfluxDB or Prometheus; the Java version to InfluxDB, Graphite, Prometheus or the console.

Play from 25:34 And upgrades. Prebid's hosting guide asks hosts to check for updates at least quarterly. There are new releases most weeks.

Play from 25:44 How big? Prebid's docs don't give sizing figures, so let's work one out. Every number here is illustrative.

Play from 25:53 Thirty million page views a month is about a million a day.

Play from 25:57 Say one and a half Prebid Server requests per page view, from refreshes and infinite scroll. That's one and a half million requests a day, or about seventeen a second on average.

Play from 26:11 Traffic isn't flat. Morning news and a big cricket match can triple it. So plan for about fifty a second at peak.

Play from 26:19 Then add headroom, so one region can absorb another's traffic. Double it: about a hundred requests a second.

Play from 26:29 And that's just what comes in. Still illustrative.

Play from 26:33 Each request fans out to every server-side bidder. Six bidders at fifty requests a second is about three hundred outbound bidder calls a second.

Play from 26:43 At around three kilobytes per bidder request, that's roughly seven megabits a second leaving your servers at peak, before any responses.

Play from 26:53 Over a month, at the average rate, it's about eight hundred gigabytes sent to bidders.

Play from 26:59 So plan capacity on peak fan-out, not on page views. Adding one server-side bidder adds a sixth more outbound traffic here, overnight.

Play from 27:10 Now the cost lines.

Play from 27:12 Compute, which grows with peak requests times bidders. Data transfer: every auction sends one request per bidder out of your network, so check your cloud's outbound pricing. The cache store's memory, which grows with writes times TTL.

Play from 27:29 Logs. Raw auction logs, with every bidder call, can outgrow everything else. Decide what you keep, and for how long.

Play from 27:38 And people: upgrades, on-call, the stored request tool and privacy reviews. For many small and mid-sized publishers, this is the biggest line of all.

Play from 27:51 Regions matter more than most people expect. These round-trip times are illustrative.

Play from 27:57 A reader in Mumbai calling a Prebid Server in Mumbai might wait around twenty milliseconds for a round trip. In Frankfurt, around one hundred and twenty. On the US east coast, around two hundred.

Play from 28:11 And a page's first call needs more than one. A new secure connection takes about two round trips to set up, then one more for the answer. Call it three.

Play from 28:21 With a three-hundred-millisecond network budget, Mumbai uses sixty. Frankfurt uses three hundred and sixty, already over. The US east coast uses six hundred.

Play from 28:34 So whichever way you go, put Prebid Server near your audience. For an Indian audience, that means India.

Play from 28:43 One more timing detail, inside the server.

Play from 28:46 Prebid Server doesn't give each bidder the full tmax. It holds some back for its own processing and network, so the bidders' replies arrive in time.

Play from 28:57 The Go and Java versions do this with different settings, and hosts tune them per region. In a slower region, bidders get a smaller share.

Play from 29:07 So a bidder with a seven-hundred-millisecond tmax might really get six hundred. Illustrative. If its response times sit near that line, it'll time out on the server more often than you expect.

Play from 29:21 So what do you watch? These are examples, not rules. Set your own baselines.

Play from 29:28 Per region: requests a second, error rate, and the slower end of auction response times, not just the average.

Play from 29:37 Per bidder: response time and timeout rate from the response's ext, and bid rate. Asking for return all bid status adds a reason code per bidder that didn't bid, such as a timeout.

Play from 29:51 And the plumbing: cache write failures, stored request lookups that fail, and how many versions behind the latest release you are.

Play from 30:01 Three production mistakes we see.

Play from 30:03 One: one region, far from readers, because it was the default in the cloud console. The whole network budget goes on distance.

Play from 30:13 Two: sizing from average traffic. The first big match day finds the limit for you.

Play from 30:20 Three: running the same version for a year. Bidder adapters, privacy rules and the OpenRTB spec keep changing, and so should your server.

Play from 30:32 Here's our hybrid page again: a one-second bidder timeout, and seven hundred milliseconds for the server. Our mock Prebid Server is adding a short delay, like a server in the same city. The call comes back well inside the timeout. And sovrn's server bid is in the auction, competing with the browser bidders.

Play from 30:54 Now the same page, with a long delay, like a server on another continent. At one second, Prebid.js stops waiting and cancels the call. Only the two client-side bids are left. And Prebid.js lists the server bidders as timed out.

Play from 31:05 Nothing is broken here. The server ran its auction. The bids were simply too late, because the distance used up the network budget.

Play from 31:17 Quick check. Pause the video if you want to think.

Play from 31:26 Most of your readers are in India, but your Prebid Server runs in Frankfurt. Your bidder timeout is one thousand, and the server timeout is seven hundred. What happens on a reader's first page view?

Play from 31:35 The set-up round trips to Frankfurt can use more than the three-hundred-millisecond network budget, so server bids often arrive too late. Move the server closer, before you touch the timeouts.

31:49Build versus managed

Play from 31:50 Last chapter. You've seen what running Prebid Server involves. Now the practical question: do you run it yourself, or let someone run it for you?

Play from 32:02 If you self-host, first a choice of code base.

Play from 32:06 Prebid Server comes in two versions: Go, the original, and Java, a later port. Both are maintained under Prebid.org.

Play from 32:16 Their features are close but not identical. Before you choose, check the feature list for anything you rely on, such as a particular bidder, module or privacy feature.

Play from 32:28 A managed host has made that choice for you. Ask which one, and how far behind the latest release they run.

Play from 32:36 Here's a neutral comparison.

Play from 32:39 Cost. Self-hosting means paying for servers, bandwidth, storage and engineering time. A managed host usually charges a fee or a revenue share.

Play from 32:50 Operations. Self-hosted, it's your team's pager. Managed, it's the host's.

Play from 32:57 Regions. Self-hosted, you choose where to deploy, but every region costs money. A managed host may already be close to your readers. Or it may not.

Play from 33:09 Data and control. Self-hosting gives you raw logs and full control. With a managed host, check what data you get back, and who else sees it.

Play from 33:21 If you're talking to managed hosts, here's a checklist in three parts. First, performance.

Play from 33:28 Where are your regions, and what round-trip time do you measure from my readers' cities? Ask for numbers from Mumbai, Delhi, Chennai, wherever your audience is.

Play from 33:39 Go or Java, and how far behind the latest release do you run? How fast do adapter and privacy updates reach production?

Play from 33:48 Do you support every bidder I use, and can I bring my own seats and params?

Play from 33:54 Second, day-to-day operations.

Play from 33:57 How do we edit stored requests: an interface, an API, or a support ticket? How long do edits take to reach every server, and is there a change history I can roll back?

Play from 34:10 Can my team use test requests and see the resolved request when we debug?

Play from 34:15 What reporting do I get: raw logs, an analytics feed, or dashboards only?

Play from 34:22 Third, the contract.

Play from 34:24 Privacy: which consent frameworks do you support, and how long do you keep logs and IDs? India's data protection rules, notified in November 2025, phase in through 2027, so bring your lawyers into this one.

Play from 34:41 Money: is it a fee or a revenue share, and whose numbers is it billed on? What's the uptime commitment, and how do you tell me about incidents?

Play from 34:51 And exit: can I export my stored requests and account settings in a form I can load somewhere else? Ask before you sign, not when you leave.

Play from 35:03 And four questions for your own team.

Play from 35:06 Do you have engineers who can run a twenty-four-seven service? Where are your readers, and can you afford servers near them? Do you need raw auction logs, or are reports enough? And how soon do you need AMP or app support?

Play from 35:22 If most answers are "not yet", a managed host is a sensible start. That's what we do at RediAds. RediWrap, our Prebid wrapper, runs server-to-server bidding for you, so you don't host Prebid Server yourself. With the team and the scale, self-hosting gives you full control. Many publishers start managed and move in-house later.

Play from 35:46 Let's apply it. This publisher is illustrative.

Play from 35:50 A news site: thirty million page views a month, eighty-five per cent of readers in India, two developers, nobody on call at night, and an app launch in six months.

Play from 36:02 Engineers for a twenty-four-seven service: not yet. Servers near readers: needs an Indian region. Raw logs: nice to have. Apps: soon.

Play from 36:14 So: a managed host with an Indian region, measured from their readers' cities, stored requests the ad ops team can edit, and an export clause.

Play from 36:25 And a date in the diary, twelve months out, to rerun the four questions with real traffic numbers.

Play from 36:33 Three mistakes we see in this decision.

Play from 36:36 One: choosing a host on price alone, without measuring latency from your readers' cities.

Play from 36:43 Two: no exit plan. Your stored requests are your configuration. If you can't export them, you can't leave.

Play from 36:52 Three: self-hosting because the software is free. The software is. The servers, bandwidth and people are not.

Play from 37:02 Before we wrap up, three myths about running Prebid Server.

Play from 37:06 Myth one: the cache keeps creatives for as long as the TTL says. It's best effort. Set it with margin, and watch for blanks.

Play from 37:17 Myth two: managed means hands-off. The host runs the servers. You still own the stored requests, the bidder mix, the Ad Manager set-up and the testing.

Play from 37:28 Myth three: one region is enough if the server is fast. Speed inside the data centre doesn't help a reader on the other side of the world. Distance comes out of the network budget first.

Play from 37:43 Let's recap Module 4.

Play from 37:45 Prebid Cache holds creatives for video, AMP and apps. Its ID travels as hb_cache_id, and the TTL must outlast the gap to render.

Play from 37:59 Stored requests keep bidder configuration on the server. Check the resolved request instead of guessing the merge.

Play from 38:07 AMP calls slash openrtb2 slash amp with a tag ID, and apps use config IDs. Both depend on stored requests and the cache.

Play from 38:18 Size for peak fan-out, put servers near readers, and keep them upgraded.

Play from 38:24 Build or buy with clear eyes: cost, operations, regions, data and an exit plan.

Play from 38:34 That's Module 4, and the end of the Prebid Server half of the course. You know how the cache, stored requests, AMP and apps fit together, and what it takes to run it all.

Play from 38:53 In Module 5, we set up Google Ad Manager so it really uses your header bids: key-values, price granularity and line items.

Play from 39:03 Want to practise first? Play the header bidding levels in the RediAds Academy, on blog dot rediads dot com.

Play from 39:08 And when you want a partner for any of this, the RediAds team is at rediads dot com. See you in Module 5.