> For the complete documentation index, see [llms.txt](https://docs.relevant-digital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.relevant-digital.com/hb-manager/setup/bidding-types-in-hb-manager.md). # 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](broken://pages/fad823c07ee3bcbe5f1070f3392bd2a94b669970) ![](/files/f7fadbc93a0a43b738340f10b3b6efef0afbb170) Before activating server or parallel side please contact your account manager or support to verify the setup to avoid any issues. {% stepper %} {% step %} ## 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 {% endstep %} {% step %} ## 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](https://docs.prebid.org/dev-docs/bidders.html) 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](https://github.com/prebid/prebid-server/tree/master/adapters). ![](/files/dc8b0b93ebe950080071cb3356b5a4c8e2db2696) {% endstep %} {% step %} ## 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: {% stepper %} {% step %} Creating a new analytics report, navigate to the report settings. {% endstep %} {% step %} Locate the "Other options" drop-down menu on the right-hand side of the settings. {% endstep %} {% step %} Select the " **Split by auction runner**" option from the drop-down menu. {% endstep %} {% endstepper %} 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. ![](/files/d2b3d3ed23dfdec9e971d58848fb3f1ac88fe7ff) In the reports, the single bidder will then appear as two. One for client side and another for server side (S2S) ![](/files/f992678c00781816493ca35247da0ae4a57bfa21) ### 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. {% endstep %} {% endstepper %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.relevant-digital.com/hb-manager/setup/bidding-types-in-hb-manager.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.