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.
1. 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
2. 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.
3. 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.