Optimizing Header Bidding Integrations on Transparent Ad Marketplace

How to optimize SSP integrations on the server-side?

As publishers adopt server-to-server header bidding, there is growing interest in migrating or testing demand partners currently integrated on the page to the server, to reduce client-side calls ¹ and simplify operations. Optimizing an SSP integration to maximize revenue can be complex:at Amazon Publisher Services (APS) we have extensive experience in integrating SSPs server-side — Transparent Ad Marketplace (TAM) works with 20+ SSPs, and we have managed multiple A/B tests on behalf of publishers. We have compiled a framework that we use to optimize demand sources with TAM.

Note on A/B testing methodology: before migrating an SSP, we usually run the two integrations in parallel for a period of time and perform a rigorous A/B test. This minimizes the risk of revenue loss, allows accounting for demand seasonality, and provides a common baseline for comparing metrics such as timeouts and buyer density. The latency benefits of server-side are limited with this approach, but it allows for more effective revenue analysis. You can decide to shut off client-side bid requests immediately. This approach allows you reap the latency benefits of server-side right away, but makes troubleshooting and analysis harder if there are any gaps. This method is preferable if reducing page latency is an urgent priority.

Metrics of success

While the definition of success is different for every publisher, we monitor two key metrics to make sure we are seeing comparable volumes of supply and demand on the server side and on the client side. These metrics are (see publisher demand funnel diagram below) bid rate — total valid bids sent by the SSP to TAM (B) divided by the total bid requests sent by the page to the SSP (A); and win rate — total impressions won by the SSP in ad server (C) divided by valid bids sent to TAM (B).

Bid rates: the bid rates should be similar from the client-side and from the server-side.

Common issues —The most common case is a lower amount of valid bid requests on the server integration. Three likely reasons:

• Buyer density in the SSP: When an SSP adds a new publisher server-side, all buyers on the SSP may not immediately start buying the newly available supply as it’s represented by a new set of publisher, site, and placement IDs within the SSP. Buyers can be using internal whitelists, Ads.txt files, or placement targeting (e.g. for deals), all of which may require new IDs to be populated for the server-side integration. We request SSP UI access for all our A/B tests, using which our revenue consultants are able to perform buyer gap analysis and identify such issues.
• SSP demand routing: the SSP might have implemented filters that throttle certain traffic, especially when duplicate impressions are involved; DSP might not be passing the creative ID; or international traffic is not supported. In one case, we discovered that some ad slots, used by DSPs for targeting, were not active for server-side, and a simple change in the SSP UI unlocked the bids previously filtered.
• Match rates: bidders bid less for unmatched impressions. While TAM has similar match rates with most client-side integrations², we have ongoing deep dives with the SSPs to investigate any discrepancy with the match rates they see with DSPs, that might cause lower CPMs or lower bid rates.

Win rates: if bid rates and bid CPMs are the same, the SSP should also win a comparable amount of impressions in the server-side auction.

Common issues — Differences in win rates can be due to a number of factors:

• Timeout settings: there are three timeouts windows of decreasing lengths, from client to TAM to SSP, that need to be synchronized to prevent bids from being dropped (see diagram above). In coordination with SSPs, we optimize timeouts by measuring network round-trip times at different stages so that the maximum number of bids are able to successfully participate at each stage and ultimately reach the ad server. By helping publishers optimize timeouts on the SSP and server-side, we have seen significant increases in server-side revenue.
• Net vs gross bids: TAM runs a first-price auction among net bids, which makes sure the true highest bid always wins, without manually setting up price reductions. However, some SSPs may send gross bids to client-side wrappers and would thus be more likely to win those auctions, even if you ultimately make less revenue after their revenue share is taken out from the bid. We always verify with the SSP that they have the same auction dynamics and are sending the same bid to both integrations.
• SSP custom settings: in our experience, there are many variables that can limit win rates on the server-side, so we always check that the bidder is competing on equal grounds. By simply aligning price floor settings, a publisher was able to normalize win rates.
• Different competition: the SSP might be winning less if there is more demand density in the server-side marketplace. This is usually a good thing, as more bids usually generate higher CPMs for publishers. When it wasn’t the case, we had to dive deeper in win rates reporting in the ad server to troubleshoot the issue and optimize revenue.

Sample checklist A/B testing client-side / server-side:

• Are line items being trafficked the same way server-side as they are client-side? Check that the following are equivalent in both integrations:
  • Domains
  • Ad sizes
  • Ad formats
  • Line item prioritization
  • Price points
  • Floor prices
• Is the SSP timeout server-side comparable to the timeout being passed to DSPs (by the SSP) client-side?
• Are you making other changes to the setup that might interfere with the auction?
• Are all the ad slots available on the client-side enabled for server-side?
• Are SSP cookie match rates comparable?
• Are same features supported in both integrations? (e.g. PMPs, AMP pages, flex units, etc)
• Is the SSP accessing traffic from the same regions server-side as they were client-side?
• Do you have access to key metrics reporting from the SSP?
• Can the SSP prioritize and support your A/B test initiative?
• Can you allocate the right internal resources (ad ops, tech team, data analysts)?

1. Reduction in latency produced by ad calls often unlocks incremental revenue from new impressions of users who don’t bounce and stay engaged. Some publishers saw, for every 50% latency cut, a 10% incremental impressions monetized (https://digiday.com/media/bloomberg-speed-impressions)  other publishers saw even more dramatic improvements (https://digiday.com/media/bauer-xcel-media-increased-ad-rates-20-percent-server-side-bidding)

2. 5 Reasons Why Exchanges Are Signing Up For Amazon TAM (AdExchanger June 21 2017)