Debugging header bidding

0:00Welcome, outcomes and key terms

Play from 0:00 It's Thursday, a little after lunch. Sales forwards an advertiser's screenshot: the half-page slot on your article pages is blank.

Play from 0:16 And your yield lead asks why Prebid revenue there is down a third this week. Illustrative numbers.

Play from 0:24 Someone wants to raise the timeout. This module gives you a better way: a routine you run the same way every time, with tools already in your browser.

Play from 0:28 Welcome to Module 7 of the RediAds Academy Header Bidding Masterclass: debugging header bidding.

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

Play from 0:37 Use pbjs_debug, the console and the Publisher Console to see what really happened on one page view.

Play from 0:46 Run a six-step debug routine that tells you which layer is broken.

Play from 0:51 Use Prebid's Debugging module to fake bids, no-bids and slow bidders on your own page.

Play from 0:57 And solve four common cases: bids that never win, a timeout storm, a price bucket mismatch and a blank ad.

Play from 1:09 Eight terms first.

Play from 1:10 pbjs_debug is a URL parameter that makes Prebid explain itself in the console. The Debugging module is a Prebid module that replaces real bids with test bids you define. An intercept rule says: when a request looks like this, answer like that. The event log is Prebid's own record of every step of every auction on the page.

Play from 1:37 The Publisher Console is Google's on-page view of what Ad Manager did with each slot. A no-bid is a bidder answering in time with nothing to offer. A late bid is a real bid that arrived after Prebid stopped waiting. And a render failure is a winning bid that never displayed.

Play from 1:59 Modules 1 to 6 built the auction: in the browser, on Prebid Server and in Ad Manager. Module 7 is about finding out where it breaks. Module 8 deals with the numbers that come out the other end.

2:15Your debugging toolkit

Play from 2:16 Chapter one. Before you open a single report, open the page. A report tells you that something changed. Only the page tells you why.

Play from 2:28 Reports are averages over millions of page views. A bug usually lives in one specific situation: one template, one slot, one device.

Play from 2:39 So your first job is to load one page, in the same conditions as the reader who saw the problem.

Play from 2:46 Same page template. Same device type, so use your browser's device mode for mobile. Same consent choice. And with your ad blocker switched off for this site.

Play from 2:57 Then you watch one auction from start to finish. Everything in this module starts here.

Play from 3:05 Start with one small change. Add pbjs_debug equals true to the end of the page's address, then reload.

Play from 3:15 Now open the console in your developer tools. Prebid prints what it's doing, step by step: the auction starting, requests going out, bids and no-bids coming back.

Play from 3:27 Debug mode also stops Prebid hiding JavaScript errors, so silent problems become visible.

Play from 3:35 It only changes your view of the page, not your readers'. And the wording of these messages changes between versions, so read them for meaning.

Play from 3:45 With the page loaded, you can ask Prebid direct questions. Seven commands answer most of them.

Play from 3:51 pbjs dot version tells you which Prebid build is on the page. pbjs dot adUnits lists the ad units, their sizes and their bidders.

Play from 4:02 getBidResponses shows every bid received, including the losers. getNoBids shows which bidders answered with nothing.

Play from 4:12 getAdserverTargeting shows the key-values Prebid wants to send to Ad Manager. getConfig shows live settings, such as the timeout and price granularity.

Play from 4:22 And getEvents returns the event log. That one deserves its own slide.

Play from 4:29 pbjs dot getEvents tells the story of each auction in order. Illustrative timings.

Play from 4:37 auctionInit: the auction starts. bidRequested: a request goes to each bidder. bidResponse or noBid: each bidder answers. auctionEnd and setTargeting: Prebid stops waiting, picks its best bids and writes the key-values. bidWon and adRenderSucceeded: a Prebid bid won in Ad Manager and displayed.

Play from 5:01 Two more events point straight at trouble. bidTimeout or auctionTimeout means someone was still being waited for when time ran out. And adRenderFailed means a winning bid didn't display.

Play from 5:10 When something goes wrong, look for the step that's missing.

Play from 5:19 The console tells you what Prebid thinks happened. The Network tab tells you what actually left the browser.

Play from 5:26 Filter the list by a bidder's domain, and you'll see each bid request, its status and how long it took. Illustrative timings.

Play from 5:36 A request that took longer than your timeout is a bid that never had a chance, however good its price.

Play from 5:43 Then filter for the ad request that GPT sends to Ad Manager. If it leaves before your bidders have answered, you've found an ordering problem.

Play from 5:50 The key-values travel inside that ad request too, but there's an easier way to read them.

Play from 6:00 Google's Publisher Console shows the ad server's side of the story, right on the page.

Play from 6:05 Open it by adding google underscore console equals one to the page address, or by typing googletag dot openConsole in the console.

Play from 6:16 The Ad Slots tab has a card for each slot: its ad unit path, its div ID, and the key-value targeting GPT sent for it.

Play from 6:25 When a reservation line item serves, the card also shows the line item ID and creative ID. That tells you whether a Prebid line item won.

Play from 6:36 The Page Request tab has a timeline of every slot, from creation to render, with any warnings.

Play from 6:44 If you'd rather not type commands, Prebid.org publishes a free Chrome extension called Professor Prebid.

Play from 6:52 It detects Prebid on the page and lists each ad unit with its bidders, their bids and the winner.

Play from 6:59 Its timeline shows each bidder's response time against your timeout.

Play from 7:04 And it shows your config: price granularity, consent and identity modules.

Play from 7:11 Extensions don't appear in our recordings, so we'll use the console. It answers the same questions.

Play from 7:18 This is a healthy page, on purpose. You need to know what normal looks like first.

Play from 7:42 The debug log is already streaming. Filter it for the auction, and you can see it start and end. That's all we need from it.

Play from 7:53 Now the console. pbjs dot version first, so we know which build we're on. Then the live timeout: one thousand milliseconds. And the price granularity: medium. These are the values the page really uses, not what someone remembers setting.

Play from 7:59 Next, the first real check. Prebid's ad unit code is div-mpu. And the GPT slot sits in a div called div-mpu. They match, so Prebid has a slot to attach its bids to.

Play from 8:05 Here are the bids, with each bidder's price and response time. Four bidders, all well inside the timeout. Test bids answer in milliseconds; real ones take hundreds.

Play from 8:19 Now the most useful check of all. Instead of asking Prebid what it wants to send, we ask the GPT slot what it actually carries. hb_pb is two point zero zero. So the key-values reached the slot before the ad request left.

Play from 8:34 The event log confirms the order: init, requests, responses, auction end, then targeting.

Play from 8:41 And finally, the Publisher Console shows the same slot from Ad Manager's side, with its targeting and its timeline.

Play from 8:48 That's the healthy baseline. In the next chapters, we'll break this page on purpose.

Play from 8:56 Three mistakes we see with these tools.

Play from 8:58 Debugging in a browser that isn't like your readers'. An ad blocker, a logged-in subscriber account or a declined consent banner can each change the auction completely.

Play from 9:11 Checking only the first auction. Pages that refresh or lazy-load slots run more auctions later, and the event log covers those too.

Play from 9:20 And treating one page view as the whole truth. The browser shows you the mechanism. Module 8 shows you how to check how often it happens.

9:31A six-step routine

Play from 9:32 Chapter two. You have the tools. Now you need an order to use them in.

Play from 9:39 When a slot breaks, the temptation is to change something straight away. Raise the timeout. Remove a bidder.

Play from 9:46 Each change might help, or might hide the real fault. Change two things at once, and you'll never know which one worked.

Play from 9:55 A routine fixes that. You ask the same questions in the same order, and the first "no" tells you which layer is broken.

Play from 10:03 It also makes the work shareable. A teammate can see exactly where you stopped.

Play from 10:10 Here's the routine. Six steps, in order.

Play from 10:13 One: reproduce and scope. Two: did the auction run? Three: did bids come back in time? Four: did the targeting reach the ad server? Five: did a line item match and win? Six: did it render?

Play from 10:31 Steps two to six follow the bid from the page to the screen. Each depends on the one before, so there's no point checking line items if the targeting never arrived.

Play from 10:43 Step one is about the question, not the code. Write down five things.

Play from 10:49 Where: which page template, which slot. Who: which device, browser, country and consent state. Since when: the first day the numbers moved. How much: all traffic or a slice. And what changed around that date: a deployment, a new bidder, a line item upload, a Prebid upgrade.

Play from 11:12 Then reproduce it once in your own browser, with pbjs_debug on. If you can't, narrow the scope. Most "random" problems turn out to be one template or one device type.

Play from 11:27 Step two. Did Prebid run an auction for this slot at all?

Play from 11:32 Check pbjs dot adUnits. Is the slot there, with the right sizes and bidders?

Play from 11:38 Then compare its code with the GPT slot. When Prebid sets targeting for GPT, it matches each ad unit code to a slot's ad unit path, or failing that, to the slot's div ID.

Play from 11:52 If neither matches, the auction can run perfectly and the bids can be real, but there's no slot to attach them to.

Play from 12:00 And check the event log has an auctionInit for this page view. If it doesn't, Prebid itself didn't load, or loaded too late.

Play from 12:10 Step three. Did any bidder answer, and in time?

Play from 12:15 getBidResponses shows real bids and their timeToRespond. Compare that with your live timeout from getConfig.

Play from 12:24 getNoBids shows bidders that answered with nothing. That's a demand question, not a bug in your page.

Play from 12:31 A timeout event means at least one bidder was still being waited for when the timer ran out.

Play from 12:38 And a bidRejected event means a bid arrived but Prebid refused it, for example because it was under a floor. Three different outcomes. Keep them apart.

Play from 12:51 Step four. Did the key-values reach Ad Manager?

Play from 12:55 Don't stop at getAdserverTargeting. It tells you what Prebid would send if you asked it now. Late bids that arrived after the auction can show up there.

Play from 13:06 Instead, ask the GPT slot what it actually carries. Get the slot from googletag dot pubads dot getSlots, then call getConfig with the word targeting.

Play from 13:18 Or open the Publisher Console, and read the targeting on the slot's card.

Play from 13:23 If the hb keys are missing, GPT asked for the ad too early, or the codes didn't match in step two.

Play from 13:32 Step five. The key-values arrived. Did a Prebid line item match them, and win?

Play from 13:39 Read hb_pb on the slot, character for character. Then compare it with the targeting on your Prebid line items. Ad Manager matches key-values as text, so one point eight zero and one point eight are different values.

Play from 13:57 Check the order and the line item are active, and cover this size and this bucket.

Play from 14:03 Then look at the Publisher Console. If it shows a line item ID that isn't one of your Prebid line items, something else won. That's the auction working, not a bug.

Play from 14:16 Step six. The Prebid line item won. Did the ad actually display?

Play from 14:22 In the event log, look for bidWon followed by adRenderSucceeded.

Play from 14:28 If you see adRenderFailed instead, its reason field tells you which part failed.

Play from 14:34 And GPT has its own event, slotRenderEnded. Its isEmpty flag says whether Ad Manager returned an ad at all, and lineItemId says which reservation line item served.

Play from 14:43 We'll use both in the blank ad case at the end of this module.

Play from 14:53 When a step fails, you've found the layer. Now close the loop properly.

Play from 14:58 Make one change. Only one.

Play from 15:02 Verify it on the page, with the same steps that found the problem.

Play from 15:06 Then write it down in a short debug log: the symptom, the scope, the step that failed, the evidence, the fix and the date you verified it.

Play from 15:17 When the same symptom comes back in six months, that log turns an afternoon into five minutes.

Play from 15:25 Three mistakes we see with the routine.

Play from 15:27 Skipping step one. Without a scope, you test the homepage on a laptop while the bug lives in article pages on mobile.

Play from 15:36 Starting at step five because "it's always the line items". Sometimes it is. Run steps two to four anyway. They take two minutes.

Play from 15:46 And testing on staging when staging runs a different Prebid build. Compare pbjs dot version on both.

15:56Case: bids but never win

Play from 15:56 Chapter three. Let's run the routine on a real-feeling case. It's the complaint we hear most often: Prebid is bidding, but it never wins.

Play from 16:08 Here's the case. Illustrative numbers.

Play from 16:11 Your analytics show healthy bids on the article page half-page slot: four bidders, an average bid around a dollar ninety.

Play from 16:20 In Ad Manager, the Prebid line items for that slot show zero impressions since Tuesday.

Play from 16:26 Your homepage slots, on the same Prebid set-up, are fine.

Play from 16:32 Step one: scope. Article pages only, all devices, since Tuesday. And on Tuesday, the article template was redesigned.

Play from 16:43 Step two: did the auction run? pbjs dot adUnits shows the slot, with the code div-hp-article.

Play from 16:53 Now the GPT slot. getSlots shows its div ID is div-halfpage-article.

Play from 17:01 The redesign renamed the div. Nobody told the Prebid configuration. The ad unit code matches neither the slot's ad unit path nor its div ID.

Play from 17:13 Two quick commands confirm it.

Play from 17:15 getAdserverTargeting has a full set of hb keys, filed under div-hp-article.

Play from 17:22 But the GPT slot's own targeting has no hb keys at all.

Play from 17:26 The auction is perfect. The bids are real. They're simply addressed to a slot that doesn't exist on this page any more. Raising the timeout or adding bidders would change nothing.

Play from 17:40 The fix is one line: change the Prebid ad unit code to match the new div ID.

Play from 17:47 Then verify, with the same steps. Codes match. The slot now carries hb_pb. The Publisher Console shows a Prebid line item winning some of the time.

Play from 18:00 And the prevention: add a check to your release process. Any template change that touches ad slots gets a two-minute pbjs_debug check before it ships.

Play from 18:11 Step two, two commands, case closed.

Play from 18:16 Three mistakes we see with ad unit codes.

Play from 18:20 Renaming slot divs in a redesign, without touching the Prebid configuration.

Play from 18:25 Defining a lazy-loaded slot after Prebid has already set its targeting. At that moment, there was no slot to match.

Play from 18:34 And copying ad unit settings from another site or template, codes and all.

Play from 18:41 One problem remains. How do you test the fix on a staging page, where real bidders rarely bid at all? With Prebid's Debugging module.

Play from 18:51 It lets you replace real bids with test bids that you define, on your own page.

Play from 18:57 Intercepted requests never reach the real bidder. Prebid answers them itself, with whatever you asked for.

Play from 19:05 So you can reproduce a problem on demand. A bidder that never bids. A bidder that's always late. A bid at exactly one dollar eighty-three.

Play from 19:14 That means you can test a fix before you ship it, instead of waiting for the bug to happen again.

Play from 19:24 You switch it on with pbjs dot setConfig, using a debugging object with enabled set to true and a list of intercept rules.

Play from 19:33 Each rule has a "when" part: which requests to catch, for example every request to the bidder called openx.

Play from 19:42 A "then" part: what to answer, for example a CPM of two dollars forty. Set "then" to null, and the answer is a no-bid.

Play from 19:51 And an optional delay, in milliseconds, under options. That's how you fake a slow bidder.

Play from 19:58 One warning. The settings are saved in the tab's session storage, so they survive a reload. Switch debugging off, or close the tab, when you're done. Otherwise you'll be debugging your own test bids.

Play from 20:13 Pause and answer.

Play from 20:22 Bids arrive in time, and getAdserverTargeting shows hb_pb for the slot. But the GPT slot's own targeting has no hb keys. Which step has failed, and what are the two most likely causes?

Play from 20:31 Step four: the targeting didn't reach the ad server. Either the ad unit code doesn't match the slot, so Prebid had nowhere to put its keys, or GPT requested the ad before Prebid set them. Check the codes first. It takes seconds.

20:50Case: the timeout storm

Play from 20:50 Chapter four. A different case, and a different layer: time.

Play from 20:57 Monday morning, your dashboard shows something odd. Illustrative numbers.

Play from 21:02 Across all bidders, the timeout rate has jumped from about six per cent to thirty-eight per cent.

Play from 21:09 Prebid's share of impressions has dropped, and revenue per thousand page views is down eighteen per cent.

Play from 21:16 No bidder changed anything, as far as anyone knows. So is it the bidders, or is it you?

Play from 21:24 First, be precise about words, because dashboards often blur them.

Play from 21:29 A no-bid is an answer in time, with nothing in it. That's demand.

Play from 21:35 A late bid is a real bid that arrived after Prebid stopped waiting. That's latency.

Play from 21:42 A rejected bid arrived in time but Prebid refused it, for example below a floor or in a currency it couldn't convert. That's configuration.

Play from 21:52 A timeout storm is a sudden rise in late bids. Your fix depends on which of the three you're actually looking at.

Play from 22:02 Step one, scope. The most useful question in a timeout storm is: is it every bidder, or just one?

Play from 22:11 If one bidder is suddenly slow and the others aren't, the problem is probably on their side. Send them evidence.

Play from 22:19 If every bidder is late at the same time, the problem is almost certainly on your page. Bidders don't coordinate their bad days.

Play from 22:29 Here, all four bidders got worse on the same day. So we look at the page.

Play from 22:36 Now read the timeline, in Professor Prebid or in your browser's Performance panel. Illustrative timings.

Play from 22:44 On the network, the bidders answer in about the same time as last week: three to six hundred milliseconds.

Play from 22:52 But this week, a single long task of about nine hundred milliseconds starts just after the auction does. While it runs, the browser can't do anything else.

Play from 23:03 So answers that came back in time sit in a queue, and Prebid handles them after its timer has run out.

Play from 23:11 And the release notes for Sunday show a new video player script, added high in the page head and started straight away.

Play from 23:20 Timeout storms usually have one of four causes.

Play from 23:24 Heavy scripts running during the auction, so the browser can't process answers. Fix: find the long task in the Performance panel, and run that script after the page loads.

Play from 23:37 Too many requests at once, from many bidders on many slots. Fix: trim bidders that rarely win, as in Module 2.

Play from 23:46 One slow partner. Fix: talk to them with evidence, and consider a server-side connection, as in Modules 3 and 4.

Play from 23:55 Or a timeout that was always too tight for mobile. Fix: run the timeout test from Module 2, on mobile traffic.

Play from 24:04 The Debugging module lets us stage both problems on a quiet page, so we can see exactly what each one looks like.

Play from 24:25 First, a page where three bidders say no. Only one bid comes back. And getNoBids names the other three. They answered, in time, with nothing. That's demand, not a bug, and no timeout setting will change it.

Play from 24:35 Now the timeout storm. Same page, same thousand-millisecond timeout. Here are the bids with their response times. Look at openx: two dollars forty, the best price on the page. And it answered after about thirteen hundred milliseconds. Sovrn and ix are late too.

Play from 24:45 The event log shows the auction timing out, and the targeting being set straight after.

Play from 25:00 So what did Ad Manager actually get? Ask the slot. The winner it carries is rediads, at two dollars. Now ask getAdserverTargeting the same question. It says openx. That's not what was sent. It's what Prebid would send if the auction ran now, with the late bid included. If you'd checked only this command, you'd think the best bid made it.

Play from 25:14 And when you're done, switch the Debugging module off, so the next person to load this tab sees real bids.

Play from 25:22 Back to our storm.

Play from 25:24 The new video player script was set to start after the page loads, instead of during the auction. The long task moved out of the auction window. Illustrative numbers.

Play from 25:35 The timeout rate fell back to its usual level within a day.

Play from 25:40 And the mistake we see most in this situation: raising the timeout site-wide to three seconds. It hides the symptom, slows every auction, and the real cause stays on the page.

25:54Case: the bucket mismatch

Play from 25:54 Chapter five. This one is quiet. Nothing is blank, nothing errors, and money still leaks away.

Play from 26:04 Here's the case. Illustrative numbers.

Play from 26:07 The site uses Prebid's auto price granularity. Below five dollars, that's five-cent buckets.

Play from 26:14 Last week, the team rebuilt the Prebid line items between one dollar and two dollars fifty, using a spreadsheet upload.

Play from 26:22 Since then, Prebid impressions in that price band have roughly halved. Nothing else changed.

Play from 26:30 Run the routine.

Play from 26:31 Step two passes. The codes match. Step three passes. Bids arrive in time. Step four passes. The slot carries hb_pb of one point eight zero.

Play from 26:46 Step five fails. The Publisher Console shows a non-Prebid line item winning, even when the Prebid bid was the highest price on offer.

Play from 26:55 So the Prebid bid reached Ad Manager, and nothing picked it up.

Play from 27:01 Now look at the pattern, not one page view. Split Prebid line item impressions by hb_pb value. Illustrative numbers.

Play from 27:12 One point seven five: healthy. One point eight zero: zero. One point eight five: healthy. One point nine zero: zero. Two point zero zero: zero.

Play from 27:25 Every missing bucket ends in zero. That's not a demand pattern. Demand doesn't avoid round numbers. That's a formatting pattern.

Play from 27:36 Here's what happened.

Play from 27:37 The spreadsheet treated the price column as numbers. One point eight zero became one point eight. Two point zero zero became two.

Play from 27:47 Prebid always sends hb_pb as text with two decimal places.

Play from 27:53 Ad Manager matches key-values as text, character for character. So one point eight zero never matches one point eight.

Play from 28:02 Half the buckets in the band had no line item that could match. Bids in those buckets simply couldn't compete.

Play from 28:11 The fix has two parts.

Play from 28:13 First, correct the targeting values on the affected line items, and format that spreadsheet column as text before any future upload.

Play from 28:23 Second, audit. Generate the full list of hb_pb values your granularity can produce. Export the values your Prebid line items actually target. Then list the differences.

Play from 28:37 Any value in the first list that's missing from the second is a bid that can't compete. Run that audit after every line item change, not just when revenue drops.

Play from 28:49 Two mismatches. Both look fine at a glance, and both cost real money.

Play from 29:12 First, the wrong code. Prebid's ad unit is called div-mpu-top. The GPT slot lives in div-mpu. So Prebid's targeting is filed under div-mpu-top, and the slot itself carries no hb keys at all. Every bid on this page is wasted, and nothing on screen tells you.

Play from 29:23 Now the bucket mismatch. This page uses auto granularity. The top bid is one dollar eighty-three. Prebid rounds it down to the one-eighty bucket, and the slot carries hb_pb as the text one point eight zero.

Play from 29:34 On screen is an illustrative list of the values our line items target, as they looked after the spreadsheet upload. Does it contain one point eight zero? False. One point eight? True. Same number to you and me, different text to Ad Manager.

Play from 29:50 Now the audit, in one line. The page has a small helper that lists every bucket auto granularity can produce. Filter out the ones our line items cover, and what's left is the gap. Every missing value ends in a zero. That's your fix list.

Play from 30:07 Three mistakes we see with price buckets.

Play from 30:11 Uploading line items from a spreadsheet without formatting the price column as text.

Play from 30:16 Changing price granularity in Prebid without rebuilding the line items to match. Old line items, new buckets, silent losses.

Play from 30:27 And testing only one price. One bucket working tells you nothing about all the others. Audit the whole list.

30:36Case: the blank ad

Play from 30:37 Final chapter. Back to the screenshot from the cold open: a blank half-page on article pages.

Play from 30:46 Here's what we know. Illustrative numbers.

Play from 30:49 The slot is blank for some readers, not all.

Play from 30:53 Ad Manager reports impressions for the Prebid line items on that slot.

Play from 30:58 Prebid's own analytics show the render rate on that slot has fallen from about ninety-five per cent to about seventy.

Play from 31:06 A blank slot isn't one problem. It's at least three, and they live in different layers.

Play from 31:13 Kind one: Ad Manager returned nothing. No line item matched. GPT reports the slot as empty.

Play from 31:21 Kind two: Ad Manager served a Prebid line item, but the Prebid creative failed to fetch or display the winning ad.

Play from 31:29 Kind three: Ad Manager served a creative from some other line item, and that creative itself is broken.

Play from 31:37 Two events tell them apart in seconds.

Play from 31:41 The first event is GPT's slotRenderEnded. Listen for it with googletag dot pubads dot addEventListener.

Play from 31:50 If isEmpty is true, Ad Manager returned no ad. That's kind one, so go back to steps four and five.

Play from 31:58 GPT also reports a failed ad request as an empty slot, so a network problem can look like kind one too.

Play from 32:06 If isEmpty is false, read lineItemId. Is it one of your Prebid line items? Then it's kind two. Another line item? Then it's kind three, and it belongs to whoever trafficked that creative.

Play from 32:22 For kind two, Prebid's event log takes over.

Play from 32:25 A healthy Prebid render shows bidWon, then adRenderSucceeded.

Play from 32:30 A failed render shows adRenderFailed, with a reason.

Play from 32:34 cannotFindAd means the creative asked for an ad ID that Prebid on this page doesn't have. That usually points to the creative in Ad Manager: a broken hb_adid macro, or a hard-coded ID.

Play from 32:50 exception means something threw an error while rendering. Look at the creative's markup, and at anything on the page that interferes with ad frames.

Play from 33:00 In our case, slotRenderEnded showed isEmpty false, and a Prebid line item ID. So: kind two.

Play from 33:10 The event log showed adRenderFailed with cannotFindAd, only on the half-page slot.

Play from 33:16 The cause: a new half-page creative had been copied from an old test, with an ad ID typed in by hand instead of the hb_adid macro.

Play from 33:27 One creative fixed, and the render rate went back up the next day. You'll see a render failure live in Module 8, when we turn these events into monitoring.

Play from 33:39 Three mistakes we see with blank ads.

Play from 33:42 Treating every blank as one problem. Read isEmpty first. It halves the search in one step.

Play from 33:50 Fixing the Prebid creative when the line item was never Prebid's. Check lineItemId before you edit anything.

Play from 33:58 And watching only Ad Manager impressions. A served impression that never rendered still counts there. Render rate is how you see it.

34:09Recap and quick checks

Play from 34:09 Before we recap, three myths about debugging.

Play from 34:13 Myth one: raising the timeout fixes "Prebid never wins". Usually it's a code, targeting or line item problem, and the routine finds it faster.

Play from 34:25 Myth two: if getAdserverTargeting shows the keys, Ad Manager got them. It shows what Prebid would send now. Ask the slot.

Play from 34:35 Myth three: you need production traffic to reproduce a bug. With the Debugging module, you can stage no-bids, late bids and exact prices on your own page.

Play from 34:48 Let's recap Module 7.

Play from 34:51 Start with one real page view, in your reader's conditions, with pbjs_debug on.

Play from 34:58 Run the six steps in order: reproduce and scope, auction, bids in time, targeting on the slot, line item match, render.

Play from 35:09 Use the Debugging module to stage the problem, and switch it off afterwards.

Play from 35:13 No-bids, late bids and rejected bids are three different things.

Play from 35:19 Compare hb_pb as text, and audit buckets after every line item change.

Play from 35:25 And for a blank ad, read isEmpty and lineItemId first, then adRenderFailed.

Play from 35:33 You can now find out why one page view went wrong.

Play from 35:52 In Module 8, the final module, we zoom out from one page view to millions. Why do your partner's report and Ad Manager disagree? How do you reconcile them line by line? Which alerts catch the next storm on day one? And how does everything from all eight modules fit together as one system?

Play from 36:01 And when you want a partner for any of this, the RediAds team is at rediads dot com.

Play from 36:05 Take the Module 7 quiz first. See you in Module 8.