Bidding types in HB Manager
In Relevant Yield’s HB Manager, there are three primary bidding types: Client-Side Bidding Server-Side Bidding, and Parallel-Side Bidding. Understanding these options will help you choose the best approach for your ad monetization
Activating different bidding types
You can change the bidding type within the " Prebid parameters" settings.
This can be done on different levels (global/publisher/site) or used in for A/B testing (configuration level) purposes. Read about how to manage your prebid parameters HERE

Before activating server or parallel side please contact your account manager or support to verify the setup to avoid any issues.
Client-Side Bidding
What is Client-Side Bidding?
Client-side bidding (or browser-side bidding) occurs directly in the user’s browser. The HB Manager makes requests to multiple demand sources (SSPs, ad exchanges, and DSPs), collects bids, and returns them in real time before sending the winning bid to the ad server.
Benefits
Higher transparency and control over bid requests
Stronger competition among bidders, increasing revenue potential
Direct interaction with demand partners, allowing for granular optimizations
Challenges
Increased page latency due to multiple bid requests being processed in the browser
Limited by browser concurrency and network constraints
Best Practices
Optimize timeout settings to balance bid competition and page load speed
Implement lazy loading to reduce unnecessary requests
Use a limited number of high-performing bidders to avoid excessive latency
Server-Side Bidding
What is Server-Side Bidding?
Server-side bidding moves the auction process from the user’s browser to an external ad server (e.g., Prebid Server). Instead of handling all bid requests in the browser, they are sent to a central server, which aggregates bids and returns the highest one.
Benefits
Reduced page latency and improved user experience
Greater scalability by allowing more demand partners without overloading the browser
Better handling of identity solutions and user data
Challenges
Reduced transparency as bid data processing happens on the server
Potential loss of cookies and user data, leading to lower bid values
Best Practices
Use a hybrid approach by combining Client Side Bidding and Server Side Bidding for optimal results
Leverage first-party data and alternative identity solutions to improve targeting
Monitor discrepancies between bid responses and actual revenue to optimize setup
Prebid server support
Not all SSPs (bidders) are supporting server side bidding type.
You can always reach out to your SSP representatives, to make sure they do support prebid server.
You can have look at the bidder specific features from the official prebid documentation
If you don't want to wait on the SSP to respond, maybe the most reliable source to make sure bidder supports PBS is directly from the source code.

Parallel Side Bidding (Client & Server)
What is Parallel-Side Bidding?
Parallel-side bidding combines the strengths of both Client Side Bidding and Server Side Bidding by running auctions simultaneously in both the client and server environments. The winning bid form both sides is then compared and the higher bid wins.
Benefits
Optimized revenue potential by leveraging both client-side and server-side demand
Balanced latency, as the browser and server work in parallel
Improved fill rate by increasing demand competition
Challenges
More complex implementation and configuration
Potential bid duplication if not properly managed
Best Practices
Implement deduplication logic to prevent duplicate bids from appearing in the auction
Use dynamic timeout settings to adapt to bid response times
Regularly analyze performance data to optimize bidder allocations
Report on the parallel bidding in analytics, follow these steps:
Creating a new analytics report, navigate to the report settings.
Locate the "Other options" drop-down menu on the right-hand side of the settings.
Select the " Split by auction runner" option from the drop-down menu.
By choosing this option, the analytics report will separate the client and server bidder data. This separation allows you to view and compare the individual metrics from both client-side and server-side bidding.
Analyzing the data in this way provides insights into the performance of each bidding method, helping you optimize your header bidding setup for maximum revenue and efficiency.

In the reports, the single bidder will then appear as two. One for client side and another for server side (S2S)

Performance Metrics to Monitor
Regardless of the bidding type, tracking key performance indicators (KPIs) will help optimize your setup:
Bid Response Rate: Measures how often a bid request results in a bid response
Fill Rate: The percentage of ad requests that result in an ad being served
Latency: The time it takes for bids to be received and processed
Revenue Per Thousand Impressions (RPM): The revenue generated per 1,000 ad impressions
Timeout Rate: Percentage of bid responses that exceed the set timeout threshold
Choosing the Right Bidding Type
If transparency and control are your top priorities, Client-Side Bidding is the best choice.
If reducing latency and scalability are critical, consider Server-Side Bidding.
If you want the best of both worlds, Parallel-Side Bidding offers an optimized solution.
Was this helpful?