When building your wrapper, you need to decide what SSPs to connect to it. Finding the best options means considering factors such as revenue and page performance. This can be difficult and requires specific data in order to make the most accurate decisions. Because there are so many SSPs today, there is an abundance of different options.
As a Publisher, when selecting your SSP, you need to make sure that you will not be going through the trouble of adding a new partner, only to realize that that partner has no demand for your inventory. What we recommend is to gather market data. By pulling data from Pubstack’s large database, we are able to see what SSPs have the best results in a given region. We do not only look at their performances in terms of revenue. This metric can be influenced by factors such as the format − but also at the SSP’s internal performance. By analyzing its bid rate and bid CPM, we collect valuable insights on whether the SSP is bidding, and at what level.
The share of voice on the requested inventory is also an important metric to look at as this lets you know how much demand the SSP fills. One thing to draw your attention to is that we choose to only consider the requested inventory. The reason is that if all inventory is taken into account, some SSPs that are only requested on a restricted number of ad units will have a very low apparent Share of Voice, but a much higher one on the ad units they’re requested on.
It is important for a Publisher to have a measure of how much value the SSP is bringing, and how much inventory it is filling. Especially when the wrapper does not contain many SSPs. The second-best option for publishers who do not have access to this data is to use a light implementation. A lot of our publishers first implement their SSPs through Open Bidding or other server-side solutions (Magnite server, PSP, TAM Wrapper,..) because it is much easier. This allows them to evaluate whether their new partner actually has demand for their inventory in their region.
To assess the value SSPs are bringing to your ad stack, you should not only consider the revenue. If you only look at the revenue, your data will be biased because there are other actors in the monetization process. Let’s take an extreme example: an SSP can have no revenue on some ad units if there is a direct campaign running on that ad unit. In that case, the revenue will be 0€, yet it is not indicative of poor performance. For that reason, it is important to consider the whole process: not only should you look at what happens in the ad server (i.e. the impression), but also analyze what happens in the Prebid auction (i.e. bid responses and winning bids).
You can also extend this measurement to assess whether your Prebid wrapper as a whole is performing well. The number of winning bids divided by auctions for example can be interesting to look at. It shows how often Prebid is participating in the competition against the ad server. If there is no winning bid coming from Prebid in the auction, Prebid is not present at all in the auction. If there are many auctions in which Prebid is not present, it is likely that there are not enough SSPs in the ad stack. Or maybe the current SSPs aren’t able to bid properly.
Once you have broken down your process horizontally like in the example above, it can also be done vertically. Of course, when looking at metrics such as bid rate and bid CPM, you shouldn’t only look at global averages. There could be some ad units where the SSPs are performing poorly, and others where it is performing very well. This is why Publishers should have the right granularity in their data. Some SSPs only bid on a single ad unit per page. If you plug them on two ad units, there will never be any bid on the second one. There will be a normal bid rate on the first one and a 0% bid rate on the second one. The example below shows a case where the global average bid rate of the SSP is about 10%, but where granularity is necessary to understand what is really going on. This SSP only bids on one ad unit with a 31.5% bid rate and practically never bids on the other ones. This is a very common trap in bid data and a lesson to remember: averages hide a lot of information.
Similar cases occur when looking at the country level, with SSPs that mostly bid on specific countries. It often happens in English-speaking countries, such as the USA and the UK, where many SSPs will only bid there and not outside of these zones. By plugging these SSPs in another region, the bid rate will considerably decrease.
A common fear for publishers who add a new SSP is to see their auction slow down. This is usually one of the biggest drawbacks of adding SSPs. Page performance tends to decrease, and having too many SSPs in a wrapper can negatively impact page speed for example. There are several aspects to consider on this topic. In order to visualize it better, we have broken down the monetization process below:
What we see here are the main events of a monetization process. Highlighted in red are the events that occur in Prebid. This red part is only a fraction of the total time as, on average, Prebid is not what takes the most time (what does is the printing of the creatives). Furthermore, what we can see is that the bid requests sent to the SSPs are sent simultaneously. They all start approximately at the same time, right after Prebid has been called. As for the Prebid auction, it only lasts for as long as the slowest SSP takes to answer or when timeout is reached. This is very important because it means that if you add a new SSP, as long as the SSP is not slower than the ones you already have, it will not add any significant latency to your auction.
In this example, SSP4 takes 1 full second longer than all the other SSPs to answer the request. Any number of SSPs that will take less than that time will not add any delay to the auction. Knowing this, publishers should evaluate which of their existing SSPs are the slowest. It requires monitoring the timeout rate of each SSP. In the example below, in the set of SSPs, we can easily identify that one of the SSPs has a high timeout rate of 42.3%. Almost one auction out of two is going to timeout when this SSP is called. That is because it is taking too much time to answer. The Publisher should ask himself whether or not it is worth keeping this SSP in the wrapper, depending on the value it is bringing. Another option is to isolate it, for example by cutting it from the ad units where it is not performing.
This entire report was done mainly thanks to our Pubstack Analytics module which gave us the data granularity needed to run this type of "deep-dive" analysis of an ad stack's performance. If you'd like to know more about the potential losses generated by your lack of proper analytics, read our article : "3 Reasons Why Ad Revenue Reporting Alone Makes You Lose Money".
When it comes to providing super granular data and clear ad stack insights to first-class publishers, Pubstack has already been working with major companies such as Highfivve (Gutefrage), the first special German marketer of programmatic advertising in the DACH region. Highfivve has been monitoring their stack’s health thanks to Pubstack’s actionable & granular data. you can read their Head of Engineering Nepomuk Seiler’s testimony right here.
We’ve actually prepared a guide to help you make the best choices given your personal situation. In a increasingly complex adtech world, we believe it is crucial to make efficient and transparent monetisation available to every publisher : How to build the optimal monetization machine.
%20(2).png)
.png)
