A misconfiguration in the setup was causing a massive issue that was costing the publisher over 20K of annual revenue. In some cases, the auction was not won by the highest bidder, so the revenue was directly impacted. Thanks to its granular data, Pubstack was able to spot this issue and give a step-by-step fix to the publisher.
We first noticed that there was something wrong when we saw that on the publisher’s inventory, despite the 20 cents UPR, there were some impressions below the UPR for one specific SSP. Thanks to the bid distribution that we have within the Pubstack interface, we were able to detect that there were still some impressions at a lower CPM than the UPR.
We ran a full-scale analysis of the behavior of this SSP and noticed that some auctions were being won by the SSP despite not having the highest bid. It was printing on auctions where other SSPs had higher bid CPMs. The graph below is a representation of what was occurring. SSP1 has a bid CPM of $2.7, and SSP2 in that example has a higher bid at $5.1. But what ends up happening, is that SSP1 is actually winning the impression.
In the ad server, we see the winning bid coming from SSP1, with a $5.7 bid CPM. This CPM is not the original bid from that SSP ($2.7CPM). This was having a negative effect on the publisher’s ad revenue because SSP1 in the end is not paying the $5.7 CPM but the $2.7 CPM. Furthermore, it is preventing the highest bidder from printing, the publisher is selling the inventory at a lower price.
We looked on the publisher’s page, at what was happening in these instances. The graph below showcases what was occurring on the page when several ad units were involved. When the page had several ad units, if SSP1 was bidding at a higher price on one of the other ad units, that price would be sent to the ad server as the SSP’s bid for the first auction (which is the case in our example here. SSP1 is winning the auction on the second adunit with a $5.7 CPM and therefore that $5.7 CPM is being sent as a bid for the auction of the first ad unit as well.) On the first ad unit, in the ad server, SSP1 is competing with a targeting of $5.7 despite its $2.7 bid. Of course, it is beating other SSPs that have a higher bid CPM.
Now that we know what was causing the issue, the publisher can move forward and get in touch with the SSP and discuss with them to identify what was wrong in the setup and get to the root cause of the problem. And then of course make the necessary adjustments to fix it.
Thanks to Pubstack’s data we were able to troubleshoot the issue successfully, and once the publisher and the SSP had fixed it, we were able to make an estimation of how much revenue was being lost because of it.
On every impression that SSP1 had won, we checked if there was another SSP that had a higher CPM, and we also looked at how much higher that CPM was. The difference between the two was the revenue lost by the publisher.
The uplift was an additional 4% of the total revenue on the impacted ad units, which counts for 2k€ per month on Prebid revenue.
This is a minimum estimation because we are not counting the potential losses in AdX. It is possible that this defective targeting was also preventing some of the bids from AdX to win the auction.
If you’d like to learn more on troubleshooting your stack, learn how to solve another Prebid setup issue with this business case : How to solve bid throttling issues ?
However if you’d like to get a testimony from our customers with a similar business case, we’ve reported on The Moneytizer’s use of our solution focused around deep troubleshooting and KPI monitoring : Use case : The Moneytizer
