prebid debug
When bids disappear or fail to render, changing bidder settings before locating the fault can make diagnosis harder. A prebid debug session is most useful when it shows which stage failed, from auction setup through to the ad server.
Key Takeaways
- A structured debugging session starts by identifying which stage of the auction failed, rather than by adjusting bidder settings on instinct.
- Bid disappearance and render failure usually have different causes, so tracing the fault from auction setup through to the ad server prevents unnecessary configuration changes.
- Checking where the breakdown occurs helps you form a clear hypothesis before you test anything, which keeps later measurement meaningful.
- Diagnosing before optimizing saves time because a change made without evidence can obscure the original problem.
Start by choosing the right inspection method. The URL parameter, the debug configuration and the debug module do different jobs, so treat their output as separate evidence.
What Prebid Debug Actually Is: Logging, the Debug Module and Third-Party Inspection Tools
Debug logging exposes auction activity in the browser console. The debug module intercepts bids for testing without sending them to the ad server, while Professor Prebid presents auction details in browser panels.
Use logging to follow events, the module to test a controlled auction, and an inspection tool to examine bidder and placement details. These methods reveal different parts of the process, so one cannot substitute for all the others.
| Method | What it reveals | Practical caution |
|---|---|---|
pbjs_debug URL parameter or debug configuration |
Console messages about auction events, bidder requests and responses. | Enable it only for a controlled test. Check that it is disabled before production traffic resumes. |
| Debug bid-interception module | Allows bids to be intercepted for testing without normal ad-server calls. | Use it to isolate auction behaviour, not to assess a live ad-server render. |
| Professor Prebid extension | Panels show ad units, bids, auctions, latency and related details. | Confirm the extension’s findings against the page and current Prebid documentation. |
The Prebid documentation recommends Professor Prebid for inspecting Prebid.js auctions. Keep the test scoped to a page and session, then remove temporary URL parameters or configuration changes; persistent debug output can expose operational details to ordinary visitors.
Reading the Debug Output as Evidence: Which Layer Failed Before You Change Configuration
Read the event sequence from auctionInit to auctionEnd before editing settings. Check whether the ad unit exists, a bidder request fires, a response includes CPM and creative ID, targeting reaches the ad server, and the creative renders.
As part of ongoing ad stack optimization, inspect the affected bidder and placement first, then compare them with a working placement before changing shared configuration. A bidder present in the page configuration but missing from requests points to a different fault than a request with no response. For a prebid debug review, name the failed stage rather than treating every console line as equally significant.
| Observed symptom | Layer to inspect | Next check |
|---|---|---|
| No bidder request or zero bids | Wrapper, bidder setup or consent | Confirm the bidder is attached to that ad unit, then check whether consent signals or request conditions prevent bidding. |
| Requests fire but time out | Bidder response or network | Compare response timing across placements and review the bidder’s current documented behaviour. |
| Bid has CPM and creative ID, but no ad appears | Targeting, ad server or rendering | Check winning-bid targeting and the ad-server response before changing bidder parameters. |
| Bid wins but cache eligibility is absent | Cache or creative handling | Verify whether the response requires caching and whether the cache step completed for that bid. |
Missing targeting keys after a valid response narrows the investigation to targeting transfer or ad-server setup, rather than demand quality. Cache output also matters: Prebid documentation notes that when a creative is not cached, the Prebid Server bid adapter appends the nurl to the creative in a new div, a detail that can affect rendering diagnosis.
Console, Extension or Prebid Server Logs: Choosing Your Inspection Route and Turning Findings into Decisions
Choose the inspection route that matches the unanswered question. Console commands expose page-level results, Professor Prebid organises browser auction details, and Prebid Server logs help trace server-side requests that are not fully visible in the browser.
| Inspection route | Useful for | What to check |
|---|---|---|
| Browser console | Confirming what the page passed to the ad server and which bids won. | pbjs.getAdserverTargeting() shows targeting values; pbjs.getAllWinningBids() returns winning bids for review. |
| Professor Prebid | Inspecting ad units, bidder responses and auction timing in one browser view. | Use AdUnits, Bids, Auctions and Latency panels to narrow the fault. CPM override can help test how a changed bid value affects the auction, but does not establish real demand. |
| Prebid Server logs | Tracing server-to-server requests and responses when the browser shows only part of the transaction. | Check whether the request reached the server, which bidders responded and whether the response returned to the page. |
For example, if the console shows a winning bid but no ad renders, inspect targeting first, then follow the ad-server response and creative handling. If only one placement receives no bids, compare its ad-unit and bidder details with a working placement before changing shared configuration. Professor Prebid is recommended in the Prebid documentation for browser-based inspection; verify version-sensitive behaviour in the current Prebid docs and prebid github repository before filing a ticket.
Record the evidence and the next test in the same note, so ad operations and revenue teams can act on one diagnosis rather than competing assumptions. A focused prebid debug session should leave a short, reproducible trail:
- Page, placement, bidder and test time.
- Observed request, response, CPM, targeting or rendering result.
- Likely fault layer, supporting evidence and one change to test.
- Expected effect on revenue or user experience, plus the result to measure.
Keep setup-specific steps in the relevant integration instructions rather than applying generic configuration changes. Demand Hub documentation includes the checks for confirming bidder presence, request activity, returned CPM and targeting keys when troubleshooting premium demand through Professor Prebid.
From One-Off Triage to Routine: Measurement, Consent Signals and What You Own Versus What a Managed Platform Owns
Turn individual investigations into a weekly review of auction health as part of a broader programmatic revenue optimization process. Track bidder request and response rates, timeouts, consent availability, user-sync status and render outcomes by placement, then compare them with a stable baseline.
Set thresholds that prompt investigation rather than automatic configuration changes. A sustained rise in timeouts, for example, warrants checking traffic conditions and bidder responses before changing a shared timeout that may affect every placement.
Consent and user-sync signals help explain why a request may not produce a bid. Compare affected auctions with those where signals are available, and note whether the difference appears across all bidders or only one; that distinction helps separate a consent-related pattern from a bidder-specific issue.
Keep the routine privacy-aware: use controlled tests, limit access to diagnostic data and confirm that temporary logging is disabled afterwards. Review consent behaviour against your current CMP configuration and the applicable platform requirements.
For a Demand Hub server-side setup, declare optidigital in the bidder list within s2sConfig. Verify bidder presence, request activity, returned CPM and targeting keys, and user-sync state in Professor Prebid before deciding whether the next test belongs in your Prebid configuration or the relevant demand path.
Use a short decision record to make the weekly review actionable:
- Record the date range, affected placements and any change in traffic or consent conditions.
- Note the threshold crossed and the evidence supporting the suspected fault layer.
- Choose one controlled test, name its expected revenue or user-experience effect, and set a review date.
This routine makes recurring faults easier to distinguish from normal variation and gives teams better evidence for ad revenue optimization decisions. Confirm version-sensitive behaviour in the current Prebid documentation before changing configuration.
Frequently Asked Questions
How do I turn on Prebid debug mode without shipping debug logging to production traffic?
Enable debug logging only for a controlled test on a specific page and session, using the pbjs_debug URL parameter or a temporary debug configuration. Once your diagnosis is complete, remove the parameter or configuration change before production traffic resumes, as persistent debug output can expose operational details to ordinary visitors.
Which Chrome extension should I use to inspect Prebid auctions, and what does each panel show?
Professor Prebid is the extension recommended in the Prebid documentation for inspecting Prebid.js auctions. Its panels show ad units, bids, auctions, latency and related details, so you can narrow a fault to a specific bidder, placement or timing issue. Confirm its findings against the page and current Prebid documentation.
How do I read Prebid debug output to identify which layer failed?
Read the event sequence from auctionInit to auctionEnd and check each stage in order: whether the ad unit exists, a bidder request fires, a response includes CPM and creative ID, targeting reaches the ad server, and the creative renders. Naming the failed stage keeps you from treating every console line as equally significant before changing bidder settings.
