Posted on Feb 7, 2022

Using Support Tools to Enhance Traffic Flow and Control Dropped Requests & Responses

8 reviews

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? 

Start Your Profitable White-Label Ad Exchange With SmartHub!
We’re ready to help! get consulted with our specialists at no chance
Contact us

Dropped Request Report for Incoming Traffic 

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):

  • No matching demand. This means that while checking a request for DSP filters, the system did not find demand from the allowed list that corresponds with this request. 
  • Important request information is missing. There are mandatory parameters of the requests. For instance the IP address. In case it is not sent in the request or the partner sends IPv6 (which is not supported), such request is getting dropped. The same happens when the bundle or the domain of the website is missing.  
  • The ad format is not allowed by SSP settings. This means the request contains an ad format object that you didn’t allow in the SSP endpoint. 
  • The bid floor is too high. If the bid floor in the request is higher than $50 it’s unlikely that DSPs will bid on such an impression, that’s why the request is getting dropped. 
  • Domain/Bundle is not in the SSP white list. This means that SSP has a whitelist, and some domains/ bundles the SSP is sending to SmartHub are not included in the whitelist. 
  • Invalid types of requests. In order to be processed correctly, the request should contain only the right symbols and data, otherwise, the system recognizes them as invalid. 

Finding the Problem Where it Occurs

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.

SmartHub's Features Have No Limits!
Get a Consultation For Free
Contact us

Checking Outgoing Traffic

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):

  • The request is blocked by the filter list manager. Often the request is blocked simply because the domain or bundle is in the blacklist (or is not in the whitelist) of this DSP. Sometimes it happens that Inventory is added to the Inventory Blacklist in the DSP Settings or DSP is blocked in inventory settings. In all cases, you will see the reason in the report. 
  • The ad format is not allowed. This means the DSP endpoint settings do not allow the ad format contained in the request. 
  • Unauthorized traffic size. This means that the placement size contained in the request is not allowed in the DSP settings.
  • Invalid billing type. SSP endpoint has Nurl (as impression tracking method) and for the DSP it’s disabled (and is counted by adm). In this case requests from this SSP won’t be sent to this DSP to avoid discrepancy.
  • IFA is missing. IFA ( Identifier for Advertisers) was not passed in the request.
  • QPS limit is reached. The maximum number of requests per second for the DSP has been reached.

Finding the Issues in Outgoing Traffic Overview

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.

Start Your Profitable White-Label Ad Exchange With SmartHub!
Get a Consultation For Free
Contact us

Checking Bid Responses  

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):

  • DSP is timeouting. If the DSP does not send its bid responses within the tmax, it is getting dropped. 
  • The bid price is missing. The bid price is a mandatory parameter without which the bid response won’t go through. The same applies to the cases when ADM and other important parameters are missing. 
  • DSP endpoint is not available. In other words, the DSP is not responding – no bids, no errors, no response at all.
  • The bid price is less than bid floor. The price DSP bids with is less or equal to the price specified in the request.
  • CRID is blocked. The CRID (creative id) sent in the response is in the blacklist created via Filter list manager.
  • The response is blocked by the filter list manager. The CRID sent in the response is simply in the blacklist or not in the whitelist for the certain DSP.

Finding the Issues in Bid Responses Overview

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.

Looking For Detailed Case Studies?
Explore How Our Partners Have Grown With Us

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. 

Enjoyed the article?
Here you can rate it or share via your favourite social media!

5/5 (8 reviews)

You May Also Like

Want to Learn More?