by Roman Vrublivskyi
Did you know that in order to ensure high relevance and quality of traffic in your marketplace, SmartHub automatically validates all incoming requests from SSPs before they reach DSPs? The same logic also works for DSP responses. This procedure is like real-time filtering that helps you to exclude invalid requests and responses so that traffic in your ad exchange could always meet quality requirements. So what kind of requests and responses are getting filtered and how to find out statistics about those?
Every time SmartHub receives the request from the publisher/SSP, it validates it according to different criteria. If the request doesn’t meet requirements of the oRTB specification or settings of your platform, it is getting dropped so that it doesn’t reach DSPs. So, what kind of incoming requests may be blocked by your system. There is a list of reasons for that. Some of them include (but are not limited to):
There could be various reasons why the requests are not getting accepted by your platform. That’s why it is very important to check the statistics from time to time and timely pinpoint the most common reason why the requests are dropped – before such a situation turns into a trend. With such an overview, you can investigate the problem at the endpoint level and find out if you need to contact some of your supply partners if the problem persists.
In order to find out what kind of request issues are happening in your ad exchange, go to the ‘Outgoing Traffic Overview’ – the system will display the number of requests that were not sent from the particular SSP to the particular DSP and the reasons for that.
After you are familiarized with the issue you can take action and subsequently optimize your marketplace. For example, you notice that requests from certain SSP are regularly missing such attributes as site or domain. In this case, it will be important to notify such partners about this problem on their side. As well, you can use Activity Samples Logger to verify what exactly is wrong with requests marked as invalid. If the reason is not obvious you can also contact the SmartHub support team for help.
As soon as incoming publisher’s/SSP’s requests are confirmed as valid, the system decides which DSPs to send it to. Since you might have installed different settings for each DSP endpoint, one request can’t be equally good for all DSPs – for some of them, it won’t be fitting. In such a situation even if the request was initially qualified as valid, it might be dropped by some DSP. How to find out the reasons for that? There is a list of reasons for that. Some of them include (but are not limited to):
You may also find those reasons in the Log event column in the Support tools. Go to Request & Response Samples Logger, proceed to the Support tools, then Traffic & Bids overview. In this section find the Outgoing Traffic Overview. In the Outgoing Traffic Overview, you will see the number of requests that were not sent from the particular SSP to the particular DSP and the reasons for that.
Just like in dropped requests, sometimes it will be obvious for you how to resolve the issue. For instance, the report says that Inventory is blocked in DSP settings, then you may go to the DSP endpoint settings, open additional Info and check the inventory blacklist. In another case, it may be important for you to notify your partner or consult the SmartHub support team.
As mentioned earlier, bid responses from DSPs also go through validation according to various criteria. If the response doesn’t meet requirements of the oRTB specification or settings on our own platform, it’s dropped and not sent to any SSP. There is a list of reasons for that. Some of them include (but are not limited to):
You may see those reasons in the Log event column in the Support tools where you should find Request & Response Samples Logger. Here the system logs real incoming bid responses. If the response is not valid, the platform displays the corresponding event (reason) for that and drops it.
Please keep in mind that the system doesn’t record all invalid responses to the logger, it only records a few of them for each reason. This way, for instance, if DSP X sends 10 000 invalid responses and those responses are invalid because of 5 different reasons the system logger will reflect only several response samples for each reason.
With this tool, you will be able to get more in-depth information of invalid responses and then share it with the DSP partner so that they could fix the problem. To find out the particular number of responses that were dropped you may use Support tools. From there to the Traffic & Bids overview and then to Bid Responses Overview.
Thanks to the White-Label Ad Exchange Solution technology, SmartHub offers you to establish and manage a white-label ad exchanges effortlessly, saving your money and time. The case studies of SmartHub prove the high effectiveness of our technologies.
Thus, with SmartHub, Feeltapmedia created an ad exchange in 7 days, yielding 31% ROI and 28% revenue growth in 3 months; and Take1ads has achieved a phenomenal 585% revenue increase and an impressive 571% ROI within a mere 4 months.
Smarthub is constantly filtering the requests and responses in your marketplace as it helps to maintain the high quality of traffic and efficient, accountable media trading between partners. Moreover, with available SmartHub configurations on each endpoint level, it becomes possible to individualize the media trading for each partner so that the system could automatically select what’s good for them. However, sometimes it happens that requests or responses are not accepted for different reasons, such as errors and missing mandatory parameters. With an updated functionality you can discover the reasons for dropped requests & responses and take actions to effectively optimize your marketplace.
You May Also Like
Want to Learn More?
Want to Learn More?
We'll get back to you very soon.
