How to Add Demand Partners Through Prebid.js

How a Prebid.js auction works

Prebid.js runs an auction in the browser or app environment before the ad server call. The publisher defines ad units, including the placements and media types available, and sends bid requests to configured bidders. Each bidder can respond with an eligible offer; Prebid.js selects a result under the configured rules and passes bid information to the ad server, often Google Ad Manager (GAM), where it competes with other demand.

The exact flow depends on the publisher's setup, including whether auctions are client-side or server-side and how targeting is passed to the ad server. A bidder being present in the configuration does not guarantee that it will bid or win. Before making changes, map the current request path and confirm where the new bidder will fit.

• Document the ad units, sizes, media types, and ad-server line-item or key-value handling involved.
• Confirm which Prebid.js version and bidder adapter are currently supported in your implementation.

What adding a bidder actually involves

A bidder integration typically requires the adapter to be included in the Prebid.js build and a bidder object attached to each applicable ad unit. That object contains bidder-specific parameters, such as account, placement, or inventory identifiers. Use the demand partner's current integration documentation for the exact required fields; parameter names and requirements vary, and example values should never be copied into production as if they were your own.

Placement configuration matters as much as the adapter. Match each bidder request to the inventory it is authorized and technically able to serve, and check supported media types and sizes. Set auction and bidder timeouts in the context of the full page experience: a longer wait may allow more responses, but it can also delay the ad-server request. Validate the configuration, consent handling, and ad-server targeting with your own implementation before release.

• Keep bidder parameters scoped to the correct ad unit and environment.
• Record the timeout values and the reason for choosing them so later changes can be compared.

Test the new partner on a slice of traffic

Start with a controlled test rather than enabling a new bidder for every user and placement at once. Use a clearly defined cohort, such as a limited set of placements or a randomized share of eligible sessions, and keep a comparable control group on the existing setup. The appropriate split depends on traffic volume and the publisher's ability to isolate the change; do not assume that a small sample can answer every question.

Check that the new bidder is called only for the intended cohort and inventory. Verify request and response behavior, ad-server handoff, consent signals, and page or app health. Change one material variable at a time where possible, keep a record of the release and rollback path, and expand only after the implementation is stable and the results are understood.

What to watch in reporting

Evaluate both auction mechanics and publisher outcomes. Useful views include request volume, response rate, bid rate, timeout rate, win rate, and the share of auctions in which the bidder participates. Compare these with revenue, fill, CPM, and ad-server delivery for the same placements and time periods. Definitions can differ across reporting systems, so make sure the numerator, denominator, and currency basis are understood before comparing figures.

Segment results by placement, device or environment, and other dimensions that are consistently available. Look for unintended effects such as latency changes, fewer bids from existing partners, or shifts in delivery. A bidder's bid activity alone does not establish incremental value; use a controlled comparison and account for normal variation before deciding whether to expand, adjust, or remove it.

• Compare the test cohort with its control over the same dates and inventory conditions.
• Set a review period and decision criteria before launch, then document what you found.

Common mistakes to avoid

Adding too many bidders at once can increase auction work and make results harder to interpret. It may also add request volume without improving competition. Add partners deliberately, confirm that each has a clear role, and review the effect on latency and existing demand rather than treating bidder count as a goal.

Misconfigured placements are another frequent source of misleading results. Incorrect identifiers, unsupported sizes, wrong media types, or parameters attached to the wrong ad unit can lead to missing or irrelevant bids. robustmonetize can work alongside a publisher's existing setup as an additional demand partner, but any integration still needs to match the publisher's inventory and technical configuration. Start with a small, validated change and retain a straightforward rollback.