Prebid Server and hybrid auctions

0:00Welcome, outcomes and key terms

Play from 0:00 In Module 2 you read a Prebid.js wrapper line by line: the ad units, the bidders, the timeout, and the hand-off to Ad Manager.

Play from 0:10 Every one of those bidders was called from the reader's own browser.

Play from 0:14 This module asks what happens when you move some of them out of the browser, onto a server.

Play from 0:21 Picture a reader on a mid-range phone, on a train, with a patchy signal. Your page wants eight bidders' prices, and the phone is already struggling.

Play from 0:32 At some point the browser can't carry any more. This module is about moving the auction somewhere that can.

Play from 0:40 Welcome back to the RediAds Academy Header Bidding Masterclass. This is Module 3: Prebid Server and hybrid auctions.

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

Play from 0:54 Explain why client-side header bidding hits a ceiling, and what that ceiling is made of.

Play from 1:00 Read an s2sConfig block and say exactly which bidders run where, and how long the server gets.

Play from 1:08 Read one Prebid Server request and response, field by field.

Play from 1:13 And follow a cookie sync from start to finish, so you know why server-side bidders lose sight of your readers, and what wins some of that back.

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

Play from 1:28 S2S means server-to-server: the auction runs between servers, not in the browser. PBS is Prebid Server, the open-source server that runs it. s2sConfig is the block in Prebid.js that hands bidders over to Prebid Server. A hybrid auction has some bidders in the browser and some on the server, in one auction.

Play from 1:55 OpenRTB is the industry's standard format for bid requests and responses. tmax is the time limit written inside an OpenRTB request. Cookie sync is how the server learns which user ID each bidder knows. And match rate is the share of requests where a bidder actually recognises the user.

Play from 2:19 Here's where we are. Modules 1 and 2 were the auction in the browser. Modules 3 and 4 move it to a server: how it works, then how to run it.

Play from 2:30 Then Ad Manager, then debugging and monitoring. Key-values, price buckets and the ad server's decision all stay the same. What changes is where the bidding happens.

2:44The browser bottleneck

Play from 2:45 Chapter one. Why move an auction that works out of the browser at all? Because the browser has limits, and every extra bidder pushes you closer to them.

Play from 2:57 Here's a page running eight bidders client-side.

Play from 3:01 The browser asks each bidder directly, and every bidder lives on its own domain.

Play from 3:06 So each one can cost a DNS lookup, a new connection and a secure handshake before a single byte of the bid request is sent.

Play from 3:16 And the browser won't open unlimited connections at once. Your bid requests share the network with your images, fonts, analytics and content. Add enough bidders and requests start to queue.

Play from 3:31 So one more bidder isn't one more request. It's four costs.

Play from 3:36 Network: another domain, another connection, another request in the queue.

Play from 3:41 Code: another adapter in your Prebid.js file, for every reader to download and parse.

Play from 3:48 Processing: building the request, reading the response and running the bid through the auction, all on the main thread.

Play from 3:56 And syncing: most bidders also want to fire user-sync pixels or iframes, which means more requests after the auction.

Play from 4:03 None is huge alone. At eight or twelve bidders, they add up.

Play from 4:11 Let's count them for one page view. These numbers are illustrative.

Play from 4:16 Eight client-side bidders: eight bid requests, to up to eight new domains.

Play from 4:22 After the auction, say six of them fire a user sync. Six more requests, some redirecting to a second domain.

Play from 4:30 So one ad auction can mean fourteen or more requests on top of your page. On fibre you barely notice. On the phone on the train, each one waits its turn.

Play from 4:42 Now the hybrid version: two bidders stay in the browser, and six go to Prebid Server. Two bid requests, plus one request to Prebid Server, plus one cookie sync call.

Play from 4:55 Syncs don't vanish: Prebid Server still asks the browser to sync bidders it doesn't know yet. But it only asks for the IDs it's missing, while client-side syncs are decided afresh on every page. You'll see this in the next chapter's demo.

Play from 5:12 And the costs don't land evenly. These numbers are illustrative too.

Play from 5:17 On a fast laptop, a full client-side auction might use around three hundred milliseconds of main-thread time.

Play from 5:24 On a mid-range phone, the same code can take three or four times longer. The processor is slower, and the network is less reliable.

Play from 5:34 That time competes with your reader scrolling, tapping and reading. It also costs battery. And for most Indian publishers, mobile is where most of the traffic is.

Play from 5:47 Which leaves you stuck in a loop.

Play from 5:49 You add bidders to get more competition. More competition should mean higher prices. But more bidders mean more latency on the device. And more latency means more bids miss the timeout, or a slower page if you raise it.

Play from 6:06 So the bidders you added stop helping. That's the catch-22 of client-side header bidding: the thing that raises yield also slows the page that earns it. Prebid Server breaks the loop by moving most of that work off the device.

Play from 6:24 Two mistakes we see in this chapter's territory.

Play from 6:27 One: adding a bidder for its promised prices without checking what it costs the page. Measure page speed and revenue per thousand sessions before and after, as you did with timeouts in Module 2.

Play from 6:42 Two: counting only bid requests. Sync requests cost network time too, and rarely show up in any dashboard.

Play from 6:51 Quick check. Pause the video if you want to think.

Play from 6:58 You add four more client-side bidders. Revenue barely moves, and pages feel slower. What's the most likely reason?

Play from 7:04 The catch-22. The extra bidders add latency on the device, so more bids miss the timeout, and the ones that arrive in time don't add enough to pay for the slower page.

7:17Hybrid auctions and s2sConfig

Play from 7:18 Chapter two. What actually changes when you move bidders to Prebid Server? First the architecture, then the one config block that switches it on, line by line.

Play from 7:31 Client-side, the browser talks to every bidder itself. Six bidders, six domains, six round trips from a phone.

Play from 7:41 Server-side, the browser sends one request to Prebid Server.

Play from 7:45 Prebid Server then calls the bidders from a data centre, in parallel, over fast and stable connections.

Play from 7:53 Prebid Server ships with hundreds of bidder adapters, counting aliases, so most of the partners you use client-side have a server-side version too. Check each one before you plan a move.

Play from 8:06 In Prebid.js, one block switches this on: s2sConfig. Your Prebid.js build also needs the Prebid Server bid adapter module.

Play from 8:32 Here's a complete, working shape. We'll take it a few lines at a time.

Play from 8:45 ``js pbjs.setConfig({ bidderTimeout: 1000, s2sConfig: { accountId: '1001', enabled: true, bidders: ['sovrn', 'ix'], endpoint: 'https://pbs.example.com/openrtb2/auction', syncEndpoint: 'https://pbs.example.com/cookie_sync', timeout: 700 } }); ``

Play from 9:00 accountId is your account on the Prebid Server host. The host gives it to you. Prebid.js also writes it into the request as the publisher ID, unless you've set one yourself.

Play from 9:13 enabled, true. It defaults to false, so a block without it does nothing at all.

Play from 9:20 bidders lists which bidders run on the server. Anything not in this list stays in the browser. Here, sovrn and ix go to the server; the other bidders in your ad units stay client-side.

Play from 9:36 endpoint is the server's auction URL, ending in slash openrtb2 slash auction.

Play from 9:44 syncEndpoint is its cookie sync URL, ending in slash cookie underscore sync. Chapter four is all about that one.

Play from 9:53 Both can also be an object with two URLs: p1Consent, for readers who gave consent to store information on their device, and noP1Consent, for readers who didn't. That matters for European traffic. If you use the object form, define both. If one is missing, requests for that group of readers aren't sent at all.

Play from 10:18 And timeout is how long the server-side auction may run. Let's work it through. These timings are illustrative.

Play from 10:26 Your Prebid.js bidder timeout is the outer deadline: one thousand milliseconds.

Play from 10:32 The server-side auction must finish inside it. Here it gets seven hundred. Prebid.js sends that number to Prebid Server as tmax.

Play from 10:43 The gap, three hundred milliseconds, is your network budget: time for the request to reach Prebid Server and the bids to come back. The Prebid docs suggest leaving two to three hundred.

Play from 10:55 If you leave timeout out, Prebid.js uses seventy-five per cent of the bidder timeout: here, seven hundred and fifty. That default also has a ceiling, called maxTimeout. In the Prebid.js 11 code it's fifteen hundred milliseconds; some documentation still says seven fifty. With timeouts under a second, it's the seventy-five per cent that bites.

Play from 11:22 In practice, most web set-ups are hybrid.

Play from 11:25 Your ad unit still lists every bidder, with its params.

Play from 11:29 Bidders named in s2sConfig go to Prebid Server together, in one request. Prebid.js forwards their params, so their client-side adapters aren't needed in the build.

Play from 11:41 The rest are called from the browser, as before.

Play from 11:45 Both sets of bids land in the same Prebid.js auction. Highest price wins, wherever it came from.

Play from 11:52 You can define several Prebid Server configs, as long as each bidder appears in only one.

Play from 12:00 Four mistakes we see with s2sConfig.

Play from 12:04 One: no enabled, true. The block is ignored, and every bidder quietly stays client-side.

Play from 12:12 Two: a server timeout equal to, or bigger than, the client timeout. There's no network budget left, so server bids arrive after Prebid.js has stopped waiting.

Play from 12:23 Three: a build without the Prebid Server bid adapter module. The config is there, but nothing can act on it.

Play from 12:31 Four: removing a bidder's client-side adapter, then wanting it back in the browser as a fallback. Plan the build and the config together.

Play from 12:42 Here's The Monsoon Times with eight bidders, all in the browser. Watch the network panel. Each bidder gets its own request, to its own domain.

Play from 12:52 A few seconds later, here come the user syncs: more requests, after the auction. The console summary is what the reader's phone sent for one ad slot.

Play from 13:08 Same page, same eight bidders. This time six are listed in s2sConfig and go to our local Prebid Server. One auction call, carrying all six, and one cookie sync call. Some sync pixels still run, because this browser is new to Prebid Server; on the next page, it won't ask again. Even so, the total is well down.

Play from 13:24 And it's still one auction. Prebid.js records each bidder's path: client for the two in the browser, s2s for the six on the server. Fewer requests from the device, and the same Prebid.js picking the highest price.

Play from 13:40 Quick check. Pause the video if you want to think.

Play from 13:49 Your Prebid.js bidder timeout is one thousand milliseconds, and s2sConfig has no timeout. How long does the server-side auction get, and how much network budget is left?

Play from 13:58 Seven hundred and fifty milliseconds: seventy-five per cent of one thousand. That leaves two hundred and fifty for the trip to Prebid Server and back.

14:09Inside one /openrtb2/auction call

Play from 14:10 Chapter three. Prebid Server isn't a black box. Every server-side auction is one HTTP request in and one response out, and both are plain OpenRTB JSON you can read. Let's read them.

Play from 14:27 Here's the shape of the request Prebid.js posts to slash openrtb2 slash auction. Four parts.

Play from 14:35 imp: one entry per ad unit, with the sizes and each server bidder's params.

Play from 14:41 site and device: the page, the publisher and the reader's device.

Play from 14:46 regs and user: the privacy signals, and any user IDs.

Play from 14:51 And the top-level controls: an id, tmax, and a block called ext dot prebid, with instructions just for Prebid Server.

Play from 15:02 Here's the imp for our article's one slot. Values are illustrative.

Play from 15:18 ``json "imp": [{ "id": "div-mpu", "banner": { "format": [{ "w": 300, "h": 250 }] }, "ext": { "prebid": { "adunitcode": "div-mpu", "bidder": { "sovrn": { "tagid": "403370" }, "ix": { "siteId": "300", "size": [300, 250] } } } } }] ``

Play from 15:35 The id is the ad unit code. That's how bids find their way back to the right slot.

Play from 15:41 banner dot format carries the sizes from mediaTypes.

Play from 15:45 And ext dot prebid dot bidder holds each server-side bidder's params, exactly the params from your ad unit. Prebid Server hands each bidder only its own block.

Play from 15:58 site carries the page URL, the domain, and the publisher, with your account ID.

Play from 16:05 device carries what the browser can tell: the user agent, screen size and language.

Play from 16:11 regs and user carry your consent signals, such as GDPR, US privacy and GPP strings. Prebid Server reads them before it calls anyone.

Play from 16:24 And user is also where user IDs ride. That matters in chapter five.

Play from 16:31 The top-level controls.

Play from 16:41 ``json "tmax": 700, "ext": { "prebid": { "targeting": { "includewinners": true, "includebidderkeys": false }, "channel": { "name": "pbjs", "version": "11.49.0" }, "debug": true } } ``

Play from 16:52 tmax: seven hundred, straight from your s2sConfig timeout.

Play from 16:57 targeting asks Prebid Server to attach the hb key-values to the winning bid, but not a full set per bidder. Prebid.js still makes the final call, so it doesn't need them.

Play from 17:09 channel says where the request came from: Prebid.js, and which version.

Play from 17:15 And debug, true, appears when you load the page with pbjs underscore debug equals true. It asks Prebid Server to include extra detail in the response.

Play from 17:27 Here's what happens between request and response.

Play from 17:31 It reads the request and your account settings, and merges in any stored configuration. That's Module 4.

Play from 17:39 It applies privacy rules from the consent signals. That can mean removing IDs or skipping bidders.

Play from 17:46 It looks up each bidder's user ID in its own cookie, on its own domain. Hold that thought for chapter four.

Play from 17:54 It fans out to each bidder's server-side adapter, in parallel. Each adapter turns the request into that bidder's own format.

Play from 18:03 It waits up to tmax, less a safety margin, then collects bids, converts currency and sets targeting.

Play from 18:12 Now the response. Values are illustrative.

Play from 18:34 ``json "seatbid": [{ "seat": "sovrn", "bid": [{ "impid": "div-mpu", "price": 1.90, "adm": "…creative…", "crid": "cr-881", "w": 300, "h": 250, "adomain": ["example-advertiser.com"], "ext": { "prebid": { "type": "banner", "targeting": { "hb_pb": "1.90", "hb_bidder": "sovrn", "hb_size": "300x250" } } } }] }] ``

Play from 18:55 Each seat is one bidder. Bidders that didn't bid simply don't appear.

Play from 19:00 impid ties the bid back to the slot. price is the CPM.

Play from 19:05 adm is the creative markup, and adomain is the advertiser's domain, which you'll use when you check blocked advertisers.

Play from 19:15 Inside the bid's ext, Prebid Server has already set key-values: hb_pb, hb_bidder and hb_size. Only the winning bid for each slot gets them, because the request asked for winners only.

Play from 19:33 Prebid.js reads these into the bid. Then it runs its own auction across client and server bids, and sets the final targeting for Ad Manager, just as in Module 2.

Play from 19:45 For formats that need it, the response can also carry a cache ID. That's Prebid Cache, the first chapter of Module 4.

Play from 19:55 The last block is the one ops teams should read most often.

Play from 20:05 ``json "ext": { "responsetimemillis": { "sovrn": 212, "ix": 655 }, "errors": { "ix": [{ "code": 1, "message": "timeout" }] } } ``

Play from 20:14 responsetimemillis gives each bidder's response time, measured on the server. ix took six hundred and fifty-five milliseconds. Against a tmax of seven hundred, that's cutting it close.

Play from 20:27 errors lists problems per bidder. Code one means a timeout. Code two means bad input, often a wrong or missing param.

Play from 20:36 So when a server bidder goes quiet, you don't have to guess. The response tells you whether it timed out, failed, or just didn't bid.

Play from 20:46 Every server bid becomes an ordinary Prebid.js bid, with one extra marker: its source is s2s instead of client.

Play from 20:57 It goes through the same price buckets, the same currency rules and the same highest-price-wins logic.

Play from 21:03 And if Prebid Server's answer arrives after the bidder timeout, its bids are too late, exactly like a slow client-side bidder.

Play from 21:14 Three mistakes we see when teams read server traffic.

Play from 21:18 One: judging a server bidder only from Ad Manager reports. Check the response's errors and response times first. A param error looks like "no demand" in a report.

Play from 21:31 Two: leaving test switched on in production. Test equals one tells bidders the request is a test, and test requests aren't meant to be billed.

Play from 21:41 Three: looking for server bidders in the browser's network panel. There's only one request to Prebid Server. Read that one.

Play from 21:51 Here's the article in hybrid mode: two bidders in the browser, two on our local Prebid Server. Let's open the one request that went to the server.

Play from 22:01 The imp's id is the ad unit code, div dash mpu. Under ext dot prebid dot bidder, only the two server bidders, sovrn and ix, with their params. tmax is seven hundred, our s2sConfig timeout. And channel says this came from Prebid.js 11.49.

Play from 22:23 Now the response. One seat, sovrn, bidding one ninety. Prebid Server has already put hb_pb, hb_bidder and hb_size on it, because it's the winner on the server side. Here are the response times per bidder. And here's why ix has no bid: error code one, a timeout. It ran out of time on the server.

Play from 22:46 Back in the console, three bids for the slot. Two say client, one says s2s. And the winner overall is rediads at two dollars, from the browser. Prebid Server's best bid competed, and lost, in the same auction.

Play from 23:03 Halfway. Pause the video if you like.

Play from 23:09 A server-side bidder never wins, and Ad Manager reports show it with almost no impressions. Where do you look first?

Play from 23:15 The Prebid Server response for a few page views: ext dot errors and ext dot responsetimemillis. If it's code one, it's timing out on the server. If it's code two, its params are wrong. If neither, it's bidding, just lower than the others.

23:34Identity and cookie sync

Play from 23:35 Chapter four, and the biggest trade-off of going server-side: identity.

Play from 23:42 Here's the problem.

Play from 23:43 Client-side, the bid request goes from the browser straight to the bidder's domain. Where the browser allows it, it attaches that bidder's own cookie, so the bidder knows who it's bidding on.

Play from 23:55 Server-side, the request goes to Prebid Server's domain instead. The browser only sends the cookies that belong to that domain.

Play from 24:04 So when Prebid Server calls the bidder, the bidder's cookie isn't there. Every user looks brand new. And unrecognised users usually attract lower bids.

Play from 24:16 How much lower? These numbers are illustrative.

Play from 24:20 Say a bidder pays two dollars CPM on readers it recognises, and one dollar twenty on readers it doesn't.

Play from 24:28 Client-side, in a browser that allows third-party cookies, it recognises seventy per cent of readers. Its average bid is about one seventy-six.

Play from 24:38 Move it server-side with no sync at all, and it recognises almost no one. Its average bid falls towards one twenty.

Play from 24:47 That's why server-side bidders need a way back to the user. The classic one is cookie syncing.

Play from 24:55 Cookie syncing takes five steps, between three parties: the browser, Prebid Server, and each bidder.

Play from 25:03 Step one. On the first auction of the page, Prebid.js posts to slash cookie underscore sync. The body lists the server-side bidders, your account, and the consent strings.

Play from 25:18 ``json { "bidders": ["sovrn", "ix"], "account": "1001", "gdpr": 0 } ``

Play from 25:26 It sends this alongside the first auction request, not before it. Keep that in mind; it matters for timing.

Play from 25:34 Step two. Prebid Server reads its own cookie, called uids, to see which bidders it already has an ID for. Then it replies with a sync URL for each bidder that still needs one.

Play from 25:52 ``json { "status": "ok", "bidder_status": [{ "bidder": "sovrn", "no_cookie": true, "usersync": { "url": "https://sync.bidder.example/u?redir=…", "type": "redirect" } }] } ``

Play from 26:10 type says how to call it. Redirect means load it as an image pixel. Iframe means load it in a hidden iframe.

Play from 26:20 Step three. Prebid.js loads those URLs one after another, in the order Prebid Server sent them.

Play from 26:28 Each one is a request to the bidder's own domain, so the browser attaches the bidder's own cookie, where it's allowed to.

Play from 26:36 Each sync gets up to a second to load by default. That's the syncTimeout setting in s2sConfig.

Play from 26:45 Step four. The bidder reads its cookie, or creates a new ID if there isn't one, and redirects the browser back to Prebid Server's slash setuid endpoint.

Play from 26:57 The redirect carries two things: which bidder this is, and that bidder's ID for this reader. Consent strings travel with it too.

Play from 27:08 Step five. Prebid Server checks the privacy rules again. If it's allowed to, it saves the bidder's ID in its uids cookie, on its own domain.

Play from 27:19 If the rules don't allow it, nothing is saved. The setuid call answers, but the cookie isn't written.

Play from 27:26 So after one round of syncing, that one cookie holds a short list: this bidder knows the reader as this ID.

Play from 27:36 On the next auction, that work pays off.

Play from 27:39 The browser sends the uids cookie with the auction request, because the cookie belongs to Prebid Server's domain.

Play from 27:47 Prebid Server reads each bidder's ID from it, and puts it into that bidder's request as user dot buyeruid. Now the bidder recognises the reader again.

Play from 27:59 But notice the catch. The uids cookie lives on Prebid Server's domain. On your page, that's a third-party cookie.

Play from 28:09 Let's put the timing together for a brand-new reader.

Play from 28:12 Page one. The cookie sync call and the first auction go out together. The auction can't wait for syncs, so server bidders see an unknown reader.

Play from 28:23 Meanwhile, the sync pixels run and the uids cookie fills up.

Play from 28:27 Page two. The auction request carries the uids cookie, and matched bidders get a buyeruid.

Play from 28:35 So syncing helps from the second page view onwards. Sites with lots of one-page visits feel this most.

Play from 28:43 Now, which browsers allow any of this?

Play from 28:47 Safari and Firefox block or partition third-party cookies by default, so the uids cookie can't work there.

Play from 28:55 Since Prebid.js 11.20, Prebid.js skips the cookie sync call in Safari, Firefox and Chrome on iOS, and when cookies are disabled or denied.

Play from 29:08 Chrome on desktop and Android still allows third-party cookies by default. In April 2025, Google dropped its plan to change that.

Play from 29:18 For honesty's sake: in Safari and Firefox, client-side bidders lose their third-party cookies too. The gap between client and server matching is mostly a Chrome story.

Play from 29:32 Three settings change how syncing behaves.

Play from 29:35 userSyncLimit caps how many sync URLs Prebid Server returns per call. With twelve server bidders and a limit of four, a new reader takes several page views to sync everyone.

Play from 29:48 coopSync, on by default, lets Prebid Server also sync bidders that aren't on your page. Publishers on the same server help each other's match rates.

Play from 29:59 And your Prebid.js user sync filter settings, for example whether iframes are allowed, are passed along, so Prebid Server only returns sync types you permit.

Play from 30:12 Three cookie sync mistakes we see.

Play from 30:14 One: testing in Safari and reporting that cookie sync is broken. In Prebid.js 11.20 and later, the call is skipped there by design. Test in desktop Chrome.

Play from 30:28 Two: judging a newly moved bidder on its first day. Match rates build up as readers return. Give it a couple of weeks before you decide.

Play from 30:38 Three: a syncEndpoint that points at a different Prebid Server host from your auction endpoint. The IDs land in one host's cookie, and the auctions run on another.

Play from 30:51 This is a brand-new reader: a fresh browser with no cookies at all. Here's the first call to the cookie sync endpoint. Prebid.js lists the two server bidders. And Prebid Server answers with a sync URL for each, because it knows neither of them yet.

Play from 31:09 Now the browser loads those URLs. Each goes to the bidder's own sync domain. And each bidder redirects straight back to Prebid Server's setuid, with its ID for this reader in the URL. That's where Prebid Server writes them into its uids cookie.

Play from 31:34 But look at this page's auction. With debug on, Prebid Server shows us the exact request it sent to sovrn. There's no buyeruid. The sync ran alongside the auction, so this page view was still anonymous.

Play from 31:47 Let's reload, as if the reader opened a second article. The cookie sync answer is now empty: nothing left to sync. And in the request to sovrn, there it is: user dot buyeruid, the bidder's own ID. The first page paid for the sync. The second page gets the benefit.

Play from 32:01 Quick check. Pause the video if you want to think.

Play from 32:08 You move a strong bidder from client-side to server-side. In desktop Chrome, its bids drop for the first week, then slowly recover. What's going on?

Play from 32:15 Match rate. On the server, the bidder can't read its own cookie, so it needs cookie syncs, and those only pay off from a reader's next page view. As returning readers get synced, the bidder recognises more of them, and its bids recover.

32:33IDs in the request, and where each bidder runs

Play from 32:33 Last chapter. Cookie syncing only works where third-party cookies do. So what's the longer-term answer, and how do you decide which bidders to move?

Play from 32:46 The longer-term answer doesn't rely on third-party cookies at all.

Play from 32:51 User ID modules in Prebid.js, like SharedID, create or read identifiers in first-party storage on your own domain, where consent allows.

Play from 33:02 Prebid.js adds them to the server request as extended IDs, called eids, alongside the other user data.

Play from 33:10 Prebid Server passes them on to the bidders that are allowed to receive them.

Play from 33:15 No sync, and no third-party cookie: the ID travels inside the request. In practice you'll run both: cookie syncing where it works, and ID modules everywhere, set up in the Module 2 order, consent first.

Play from 33:32 Here's how that tends to play out. These numbers are illustrative.

Play from 33:36 In desktop Chrome, with syncing and IDs, a server bidder might recognise most returning readers. In Safari and Firefox, it relies on the first-party IDs it accepts, so match rates are lower on both paths. And a brand-new reader's first page is mostly unmatched anywhere.

Play from 33:56 So one bidder can look strong on one slice and weak on another. Split results by browser before you judge a move.

Play from 34:06 So which bidders go where? Here's the honest trade-off.

Play from 34:10 Server-side wins on page weight and device work: one request instead of many, and room for more bidders without slowing the page.

Play from 34:20 Client-side wins on matching in Chrome, because each bidder reads its own cookie. It also wins on transparency: every request is visible in the browser.

Play from 34:31 A common pattern keeps a few top partners client-side, where their match rates matter most, and moves the long tail to the server. Then you test, one bidder at a time.

Play from 34:44 Here's what one test looks like. All numbers are illustrative.

Play from 34:49 Pick one mid-sized bidder. Split page views fifty-fifty: half keep it client-side, half send it through s2sConfig. Run for at least two weeks, so returning readers have time to sync.

Play from 35:03 Measure revenue per thousand sessions, not the bidder's own CPM. Say the control earns four dollars twenty, and the test earns four dollars twenty-nine.

Play from 35:13 Then look underneath. The moved bidder's own average bid fell by about ten per cent in Chrome. But the page got lighter, so more of the other bidders answered inside the timeout.

Play from 35:26 Split it by browser too. Chrome is roughly flat, and Safari is slightly up, because there was little matching to lose there.

Play from 35:36 So is that a win?

Play from 35:37 A two per cent lift is small. Check that it holds day by day, not just in the total, before you call it.

Play from 35:45 Check page speed as well. If your Core Web Vitals improved, that's value beyond this test's revenue.

Play from 35:51 If it holds, keep the move and test the next bidder. If revenue per thousand sessions drops, move the bidder back. Nothing is lost but two weeks.

Play from 36:03 Three mistakes we see when teams go hybrid.

Play from 36:07 One: moving every bidder to the server in one release. When revenue moves, you can't tell which bidder caused it.

Play from 36:15 Two: judging the move by the bidder's own CPM. A lower CPM with a faster page can still mean more revenue overall.

Play from 36:25 Three: skipping user ID modules because cookie syncing seems to work in Chrome. Your Safari and Firefox readers are a real share of traffic, and syncing does nothing for them.

Play from 36:39 Before we wrap up, three myths about Prebid Server.

Play from 36:43 Myth one: server-side is always faster. The page does less work, but the round trip and the server timeout still count. A distant, overloaded server can lose to a lean client-side set-up.

Play from 36:58 Myth two: moving bidders server-side is free money. Lower match rates can mean lower bids. Move one at a time, and measure.

Play from 37:08 Myth three: Prebid Server replaces Prebid.js. On the web, it doesn't. Prebid.js still runs the ad units, the final auction and the ad server call. Prebid Server is simply where some bidders live.

Play from 37:25 Let's recap Module 3.

Play from 37:27 The browser has a ceiling: every bidder costs network, code, processing and syncs, and phones pay the most.

Play from 37:37 s2sConfig hands the bidders you choose to Prebid Server, with a server timeout inside the client timeout.

Play from 37:45 One OpenRTB request goes to slash openrtb2 slash auction, and one response comes back. Read its errors and response times before you judge a bidder.

Play from 37:57 Server-side bidders lose their cookies. Cookie syncing wins some back from the next page view, where browsers allow it. User IDs travel inside the request, everywhere.

Play from 38:10 And you move bidders one at a time, measured by revenue per thousand sessions.

Play from 38:17 That's Module 3. You know why the browser runs out of room, how a hybrid auction works, what one Prebid Server call looks like, and what going server-side costs in identity.

Play from 38:35 In Module 4, we run Prebid Server in production: Prebid Cache, stored requests, AMP and apps, cost and capacity, and whether to host it yourself.

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

Play from 38:49 See you in Module 4.