Managing SSP and DSP Connections on SmartHub: Best Practices

Overview

This doc includes some general advice for an Account Manager, namely, how to integrate with your partners, which SSP and DSP activities to monitor in order to increase the revenue, how to check the stats and handle discrepancy issues.

All points here are based on SmartyAds ’Account Managers’ best practices.

Integration

Integrating with SSPs

We recommend that you take the following steps each time you integrate a new SSP:

  1. Make sure SSP runs openRTB activity (have servers) in the same region(s) as you.

  2. Make sure SSP works by openRTB protocol v2.4 or older.

  3. Send samples of your bid responses to SSP and check with them if bid responses are acceptable. You can find samples of responses in SSP endpoints settings.

  4. Send your bid request requirements for each format to your SSP. Please find the lists of requirements in the paragraph 4.1 of the SmartHub Specification.

  5. Create endpoints for your SSP and share them. Ask your SSP to send 100 QPS maximum for the first day or two. If an SSP can set a spend cap on their end, ask them to set max 10 USD/day and do the same on your end for the next 2-3 days until you make sure there is no discrepancy.

  6. In several hours after you start the test, check the following:

  • Check in the DSP/SSP Statistics tab if there are any errors on the endpoints you shared with your SSP.
  • Check if bid requests which are received from SSP contain all necessary data according to the paragraph 4.1 of the SmartHub Specification.

7. Next day, check if statistics you recorded coincides with SSP’s statistics (the amount of impressions and spend for yesterday).

In case your SSP has any specific requirements, please forward the following information to your SmartHub Account Manager:

  1. Your SSP request and response samples.

  2. Your SSP specification file.

  3. Detailed information about the changes that have to be made on SmartHub side.

Integrating with DSPs

We recommend that you take the following steps each time you integrate a new DSP:

  1. Make sure DSP runs openRTB activity (have servers) in the same region(s) as you.

  2. Make sure DSP works by openRTB protocol v2.4 or older. If it works by v2.5 – please inform the DSP in advance that you can call the DSP’s BURLs, but you do not support any other protocol v2.5 features.

  3. Send samples of your bid requests to DSP and check with them if bid requests are acceptable. You can find samples of requests in DSP endpoints settings.

  4. Send your bid response requirements for each format to your DSP. Please find the lists of requirements in the paragraph 4.2. of the SmartHub Specification.

  5. Register your DSP’s endpoints on your platform. Open maximum 100 QPS per endpoint. If a DSP can set a spend cap on their end, ask them to set max 10 USD/day and do the same on your end for the next 2-3 days until you make sure there is no discrepancy.

  6. In several hours after you start the test, check the following:

  • Check in the DSP/SSP Statistics if there are any errors on your DSP’s endpoints.

  • Check if bid responses which are sent from DSP contain all necessary data according to the paragraph 4.2. of the SmartHub Specification.

7. Next day, check if statistics you recorded coincides with DSP’s statistics (the amount of impressions and spend for yesterday).

In case your DSP has any specific requirements, please forward the following information to your SmartHub Account Manager:

  1. Your DSP request and response samples.

  2. Your DSP specification file.

  3. Detailed information about the changes that have to be made on SmartHub side.

Statistics

It’s recommended to compare your stats with all partners daily, even if they do not have a convenient way to share numbers. The effort is worth it – discrepancy can occur any time with any partner, and checking stats regularly will save you money.

Sharing Your Statistics with Partners

You have possibility to share your stats in two ways:

  1. By sharing your stats API links. Your API links are generated for each endpoint you have on SmartHub. You can find them in the endpoint settings both on supply and demand side:

 

2. By sharing access to your dashboard (‘View Statistics’ role):



 

Users with this role will be able to see only their Statistics.

Checking Your Partners’ Statistics

You have possibility to add your partners’ statistics to the Billing page. There are two options how to do this:

  1. Set up your partner’s API link in endpoint settings:

 

You can add API links both for SSP and DSP endpoints.

When you have received API link from your partner you should replace the date with a placeholder, the edited API link must look like the following sample:

http://apismarthub.smartyads.com/api/report/ssp?token=ac374fca0b77eed431ada53bdc20658d&endpoint=209&from=[%Y-m-d%]&to=[%Y-m-d%]

Once you add it, check if the link works correctly by loading yesterday’s stats of the partner via API link manually on the Billing page by pressing a button near the partner’s endpoint.

2. Then, you will see the numbers on the Billing page:

When you have partner’s statistics on the Billing page, the numbers will be highlighted either in green or in red. The color depends the discrepancy percentage – if the discrepancy is smaller than 5%, partner’s numbers will be green, if it is bigger than 5%, partner’s numbers will be red.

Note: there may be a certain percentage of discrepancy, for example, due to incorrect API settings on the partner’s side.

 

Discrepancy

Below are the suggested actions which should be taken, if you see more than 5% of discrepancy in SSP and DSP spend.

Discrepancy with SSPs

Case 1. SSP counts more than you

  1. Ask SSP to send you 2 detailed reports in UTC for the previous day:

Domain/bundle, impressions, spend

Publisher ID, impressions, spend

Compare the data with yours. If you see domains/bundles or publishers that cause the discrepancy, ask SSP to block them. And compare the stats on the next day without them.

  1. Ask the SSP what their impression expiry window is. If it is more than 20 minutes, consult your SmartHub Account Manager.

  2. Ask the SSP if they replace price macro in your ADM. If they can replace only macro in NURL, turn on the setting ‘Price by NURL’ in SSP endpoint settings.

  3. If the discrepancy is spread across all sources, ask SSP how they count impressions, and send this data together with all data that you gathered to your SmartHub Account Manager.

Case 2. SSP counts less than you

  1. Ask SSP to send you 2 detailed reports in UTC for the previous day:

Domain/bundle, impressions, spend

▪  Publisher ID, impressions, spend

Compare the data with yours. If you see domains/bundles or publishers that cause the discrepancy, ask SSP to block them. And compare the stats on the next day without them.

  1. Ask the SSP what their impression expiry window is. If it is less than 5 minutes, consult your SmartHub Account Manager.

  2. Ask the SSP if they replace price macro in your ADM. If they can replace only macro in NURL, turn on the setting ‘Price by NURL’ in SSP endpoint settings.

  3. Ask the SSP if they filter out impressions on post-bid.

  4. If the discrepancy is spread across all sources, ask SSP how they count impressions, and send this data together with all data that you gathered to your SmartHub Account Manager.

 

Discrepancy with DSPs

Case 1. DSP counts more than you

  1. Ask DSP to send you 2 detailed reports in UTC for the previous day:

  • Domain/bundle, impressions, spend

  • Publisher ID, impressions, spend

Compare the data with yours. If you see domains/bundles or publishers that cause the discrepancy, block the sources for DSP. And compare the stats on the next day without them.

  1. Ask the DSP what their impression expiry window is. If it is more than 20 minutes, consult your SmartHub Account Manager.

  2. If the discrepancy is spread across all sources, ask DSP how they count impressions, and send this data together with all data that you gathered to your SmartHub Account Manager.

Case 2. DSP counts less than you

  1. Ask DSP to send you 2 detailed reports in UTC for the previous day:

  • Domain/bundle, impressions, spend

  • Publisher ID, impressions, spend

Compare the data with yours. If you see domains/bundles or publishers that cause the discrepancy, block the sources for DSP. And compare the stats on the next day without them.

  1. Ask the DSP what their impression expiry window is. If it is less than 5 minutes, consult your SmartHub Account Manager.

  2. Ask the DSP if they filter out impressions on post-bid. If yes, agree with them to disable filtering out on post-bid on their platform as all the impressions where their pixels fired are billable.

  3. If the discrepancy is spread across all sources, and DSP does not filter impressions on post-bid, ask DSP how they count impressions, and send this data together with all data that you gathered to your SmartHub Account Manager.

 

Win Rate

Win rate equals to impressions divided by responses and multiplied by 100. It is desirable that auctions on banner, native, push and pop traffic have at least 10% win rate. For video, average win rate is usually lower.

The bigger the percentage of win rate is on supply and demand sides, the more revenue you will generate, therefore it is recommended to monitor the win rates for all endpoints regularly. Based on the win rate, you can decide how much traffic you want to receive from SSPs, and how much traffic you would like to send to DSPs. We usually consider that for banner and native traffic win rate should be at least 10%. For video win rate is usually lower and 1-2% might be all right.

You can see the win rate per endpoint on the Main page that is calculated based on data for last 6 hours:

You can also check the win rate of SSPs and DSPs in detail in Req/Res Statistics:

Please note that if you work with SSP/DSP at a low scale (traffic volume under 100 QPS and bid rate under 1 BPS), it will be more efficient to scale up first, and then check the win rate, rather than to start investigating why the win rate is low.

Your Win Rate with SSPs

It is always easier to find the reasons for low win rate on SSP’s side, because you cannot see how your responses are validated and processed in SSP’s system. Before checking anything in the system, ask your SSP if they can analyze your performance on their side and see why your win rate is low. Here is a standard list of questions to SSP that help solve the issue with low win rate:

  1. Does your SSP see high timeouts percentage from you? If yes:

    1. Make sure your data centres are located in the same region.

  2. Ask the SSP to send you the timeouts percentage they see as well as their IP for ping.

  3. Ask the SSP to send you curl that will illustrate the issue.

Having all of the above, pass this information to your SmartHub Account Manager.

  1. Does your SSP see any errors in your responses (missing fields, for example)?

If yes, please ask the SSP to share response samples that will illustrate the issue and forward them to your SmartHub Account Manager.

  1. Are your crids/domains blocked by some scanners on the SSP’s side? If yes, please ask the SSP to send you a list of crids, and block them on your end. It is also recommended to check what scanner they are using and to consider an option to on-board it on your platform too.

  2. Are the prices you send in responses too low to win?

  3. Does SSP have possibility to optimize traffic for you in order to increase your win rate? If yes, agree on the optimizations with them and check the results in 1-2 days.

 

If your SSP doesn’t see issues with your demand, and the only possible reason for low win rate is low price, analyze data in Req/Res Statistics for this SSP, for the period of one week or so. Check the win rate by two parameters:

1. Win rate with DSPs

Choose your SSP endpoint and time period. You will need to have the following columns in the table: SSP endpoint, DSP endpoint, SSP requests to DSP, DSP responses (valid), Impressions, and Win rate.

Once you generate the report, sort the data by DSP responses (valid) – descending. This report will show you which DSPs send most of bids to your SSP endpoint, and which of them have low win rate.

 

 

2. Win rate with domains/bundles

Choose your SSP endpoint and time period. You will need to leave the following columns in the table: SSP endpoint, Domain/Bundle, SSP requests to DSP, DSP responses (valid), Impressions, and Win rate.

Once you generate the report, sort the data by DSP responses (valid) – descending. This report will show to which domains/bundles of this SSP you send most of bids, and with which of them you have low win rate.

 

These two reports will give you the idea if you have low win rate all across SSP’s traffic, or with some particular sources, and if all your DSPs perform equally for this SSP.

There are three possible options of what you find after checking the reports:

Case 1. There are particular domains or bundles on which you bid and do not win

Solution: You can ask your SSP to block them. If you do not win only on particular domains/bundles, there is a small chance that there is an issue with your demand. The chances are that your SSP has demand partner that bids with higher prices on these domains or bundles.

Case 2. Some of your DSPs have low win rate with the SSP

Solution: Ask your SmartHub AM for samples of the DSP’s repacked responses. Send them to your SSP. Your SSP might identify why such responses do not work well for them.

If your SSP cannot share any insights on why your demand isn’t performing well, you can try blocking the non-performing DSPs for the SSP for some period of time, for instance for a week. As traffic and demand change on both sides rapidly, unblock the DSPs afterwards and check if the situation changed.

Case 3. All DSPs have low win rate with SSP’s traffic

Solution: Unfortunately, it is impossible to find the root cause of this on DSP’s side. Only SSP can identify on its side why your win rate is low. If your SSP cannot give any insights on this, consider decreasing the volume of traffic you receive from this SSP to minimum until your SSP finds the reason or the win rate increases over time.

 

DSPs’ Win Rate

When your DSP has low win rate, check the following data:

1. Timeouts in DSP/SSP Statistics:

 

Timeouts higher than 5% effect DSP’s performance negatively. If you see high timeouts percentage from your DSP, check the SmartHub Specification.

2. Errors and other responses in DSP/SSP statistics:

 

 

Such responses do not take part in auctions, so once you notice a big amount of errors, notify your DSP about them. Your SmartHub AM can retrieve examples of invalid responses for you.

Please note that the response “No bid” isn’t an error. In order to decrease the numbers of “No bid” responses please regularly check with your DSPs what traffic they need, collect all the info, and agree with SSPs that they send mostly relevant traffic.

If there are no timeouts and errors, check data in Req/Res Statistics by domains/bundles and by SSPs for the period of one week or so.

 

1. Win rate with SSPs

Choose your DSP endpoint and time period. You will need to leave the following columns in the table: SSP endpoint, DSP endpoint, SSP requests to DSP, DSP responses (total), DSP responses (valid), Impressions, and Win rate.

Once you generate the report, sort the data by DSP responses (valid) – descending. This report will show to which SSPs your DSP bid most, and with which of them it has low win rate.

Also, pay attention to the difference between DSP responses (total) and DSP responses (valid). If you see that the difference is big (>25-30%), and there are no errors or timeouts from this DSP, it means that this DSP loses in auction with another DSP you have connected.

 

 

In the screenshot above, it is evident that the lowest win rate is with SSP 3.

2. Win rate with domains/bundles

Choose your DSP endpoint and time period. You will need to leave the following columns in the table: DSP endpoint, Domain/ Bundle, SSP requests to DSP, DSP responses (valid), Impressions, and Win rate.

Once you generate the report, sort the data by DSP responses (valid) – descending. This report will show to which domains/bundles your DSP bids most, and with which of them it has low win rate.

 

In the screenshot above, it is evident that the lowest win rates are on the third and fifth bundles.

These two reports will give you the idea where your DSP loses in auctions. Below are possible options of what you find after checking the reports:

Case 1. There are particular domains or bundles to which your DSP bids and doesn’t win.

Solution: You can block these sources for DSP for a week or so. Unblock them later – your DSPs’ demand changes over time, so it will be better to give the DSP opportunity to bid to these sources again.

Case 2. Your DSP has low win rate with particular SSPs and wins with the rest of SSPs. Most of bids are sent to SSP, there is no big difference between DSP responses (total) and DSP responses (valid) (<10%).

Solution: Ask your SmartHub AM to retrieve several samples of repacked responses from this DSP. Your SSP might identify why such responses do not work well for them.

If your SSP cannot share any insights on why your demand isn’t performing well, you can try blocking the non-performing SSPs for this DSP for some time, for instance for a week. Afterwards, remove the DSP from the blacklist and check if anything changed.

Case 3. Your DSP has low win rate with particular SSPs and wins with the rest of SSPs. There is a big difference between DSP responses (total) and DSP responses (valid) (>10%).

Solution: In this case, your DSP loses in your internal auction, there is no sense in reaching out to SSPs. You can wait and monitor if situation changes, or block the non-performing SSPs for your DSP for a short time period.

Case 4. DSP has low win rate with all of your SSPs. Most bids are sent to SSPs, there is no big difference between DSP responses (total) and DSP responses (valid) (<10%).

Solution: Check the prices in DSP’s responses. You can see the samples in DSP endpoint settings. If the prices are too low, this can be the reason. You can see the average eCPMs you have with your SSPs in Statistics. In this case, setting a small maximum bidfloor in EP settings can help.

You can also reach out to some SSPs to which your DSP bids a lot and send them the DSP’s response sample. As your SmartHub AM for a sample of repacked response. Your SSPs can give some insights why the responses do not win in auctions.

 

Fill Rate/Bid Rate/BPS

Fill rate equals to impressions divided by requests sent to DSP and multiplied by 100. Fill rate isn’t calculated as separate metric on SmartHub platform.

Bid rate equals to responses divided by requests and multiplied by 100. Bids per second are just the quantity of responses you are sending to SSP or DSP is sending to you. Based on this information, you can decide how much traffic you want to receive from SSPs, and how much traffic you would like to send to DSPs.

Both for SSPs and DSPs, we usually consider the bid rate is sufficient if at least 1 bid response is sent for each 100 QPS (which corresponds to 1% bid rate).

On the Main page, you can see the quantity of bids per second (Bid QPS metric) in real time for all companies and endpoints, both SSPs and DSPs:

 

 

In DSP/SSP Statistics, you can see the quantity of responses for each DSP broken down by hour or by day. You also can see how many responses DSP sent in total, and how many of them were valid:

 

In Req/Res Statistics, you can see detailed info about bids from DSPs and to SSPs broken down by domains/bundles:

 

Please note that if you are receiving or sending less than 100 QPS, it will be more efficient to scale up before investigating the reasons of the low fill/bid rate.

 

Your Fill Rate/BPS with SSPs

 

If you see you do not bid much to SSP’s traffic, check the following:

1. Errors in DSP/SSP Statistics (Invalid Requests):

 

If you see more than 5% errors, notify your SSP. Your SmartHub Account Manager can share samples of invalid requests with you. The objects and parameters validated are listed for each format in SmartHub Specification. If you do not have it, contact your SmartHub Account Manager.

2. Quantity of sent requests in DSP/SSP Statistics:

 

If you see that there is a big difference between Bid requests from SSP and Bid requests sent to DSP (>15-20%), and there are no errors, it means that your SSP sends you irrelevant traffic that doesn’t match your demand. Ask your SSP what traffic they have open for you, and send them info about your current demand, so that SSP could setup targeting accordingly.

If there are no errors and requests are sent to DSPs, ask SSP if it has any possibility to optimize traffic for you on its side. A lot of SSP have throttling systems or possibility to setup traffic volume per geo/source based on information about your demand.

If SSP has no possibility to optimize traffic for you, check the sources your SSP was sending to you in Req/Res Statistics by domains/bundles for a week or so. Choose your SSP endpoint and time period. You will need to leave the following columns in the table: SSP endpoint, Domain/bundle, SSP requests to DSP, DSP responses (valid). Once you generate the report, sort the data by SSP requests to DSP – descending.

 

 

This report will show if the issue is caused by particular sources. Below are possible options of what you find after checking the reports.

Case 1. Your SSP sends you a lot traffic from domains/bundles on which you do not bid (while there are sources to which you do bid a lot)

Solution: Ask SSP to decrease traffic volume from these sources. If SSP cannot regulate traffic volume per source, ask SSP to block them for you temporarily. Your DSPs can have demand for them in some time, so there is no point in blocking the sources forever.

Case 2. Your bid rate is low on all sources your SSP sends to you

Solution: Check the samples of SSP’s requests in SSP endpoint settings, in particular – the bidfloors your SSP is sending. If the bidfloors are too high for the traffic format and type they are sending, ask SSP if it can set maximum bidfloor limit for you. (You can check the prices you have in Statistics – column DSP CPM). You can also check the tmax SSP is sending (you will not respond if the tmax is under 70 ms) and how various traffic is (if SSP is sending only several bundles or domains, the fill rate can be low if your DSPs do not have much demand for them).

If you see no issue with SSP’s bidfloors, you can reach out to SmartHub AM to check the requests from the SSP.

 

DSPs’ Fill Rate/BPS

If you see that DSP has low bid rate, check if there are timeouts in the DSP/SSP statistics page:

 

If there is no high timeouts percentage, you will need DSP’s help in identifying the reasons. It is not possible to check why your DSP has low fill/bid rate from SSP’s side. Below is the list of questions to DSP that help solve this:

  1. Has DSP opened all demand for you?

  2. What traffic does DSP have demand for?

  3. Does DSP see issues with your requests (for instance, missing fields)?

  4. Are your requests filtered out by DSP’s scanners?

  5. Are your bidfloors too high for the DSP?

Based on this information, you can set up targeting for DSP, block inappropriate traffic, set maximum bidfloor, or solve the issue with requests formatting (send the DSP’s requirements to your AM).

If your DSP cannot give any insights why they do not bid to your traffic, consider decreasing the QPS limit (to 100-200 QPS) for this DSP until DSP can share info or until you see the situation has changed over time.

 

Traffic Volume

You have a limit for receiving and sending traffic on SmartHub that depends on your plan. The system will work in the most effective way if the volumes are spread proportionally depending on your partners’ performance. Based on the metrics described above – win rate and fill rate – you can decide how much traffic you want to send and receive.

You can see real-time incoming and outgoing traffic volume in QPS for SSPs and DSPs on the Main page:

 

 

In Requests/Responses Statistics, you can check hourly/daily quantity of requests you received from SSPs and sent to DSPs:

In Req/Res Statistics, you can see detailed info about requests you sent per domain/bundle for each SSP and DSP:

 

Incoming Traffic

Agree with your SSPs that they set limit on traffic they are sending, so that your limit wasn’t exceeded. If you receive too much traffic, the server will be overloaded.

Define the volume of traffic you would like to receive from your SSP based on the performance you have with it – if your win rate and bid rate with this SSP are low, it is better to receive more traffic from other SSPs with better performance.

Outgoing Traffic

For DSPs, you need to set QPS limit for each enabled endpoint:

 

The total of all limits should not exceed your plan, otherwise the traffic will be divided into all enabled EPs randomly. It is recommended that you spread traffic volume according to the DSP’s performance. Monitor that most of traffic is sent to DSPs that bid a lot and have a good win rate, and those DSPs that have low bid rate or do not win do not receive a lot of traffic. You can update these settings daily.

 

Errors

The fewer errors you see in requests and responses you receive, the better. All requests and responses that show errors do not take part in auctions, therefore they lower your bid rate to SSPs and your DSPs’ win rate. It is recommended to monitor the errors rate regularly and minimize it.

You can see hourly and daily errors quantity and percentage in DSP/SSP Statistics for both

SSPs:

 


 

 

… and DSPs:

 

Spend Limit

You can set daily spend limits in SSP and DSP endpoint settings:

For SSPs, you can remove spend limits after integration is finished and you have made sure you do not have discrepancies.

For DSPs, it is recommended to set spend limits on each endpoint even if you do not have payment issues with the DSP, and there is no discrepancy. The spend limit should be slightly bigger than DSP’s usual spend. For instance, if your DSP usually spends around $500 per day, set spend limit $600.

Having such spend limits in place for all DSPs, you will need to monitor if the limits are reached and if they have to be increased. However, we still recommend that you set caps on each DSP endpoint. Most DSPs have more or less similar spend from day to day. If DSP suddenly starts spending more, there is a risk that there is a system error. For instance, DSP’s advert can set budget or prices incorrectly by mistake. Another case is that if your DSP counts impression by NURL, there is a risk of errors calling DSP’s NURL due to issues on DSP’s server. If this happens, DSP will not count impressions. As a result, DSP will not be able to stop bidding according to its budget limitations. If such a situation occurs, there is no guarantee your DSP will be able to pay in full, so setting spend limits will prevent payments issues.

Daily activities of Account Manager

Please see the check list of activities that Account Manager should undertake on a daily basis.

  1. SSPs:

  2. Make sure they are sending the traffic.

  3. Check if you are responding to SSP’s bid requests on all the available endpoints.

Make sure they are not sending you any irrelevant requests (Check the errors).

  • Check the win rate and solve the issue if it is less than 10% on display and/or native. Check the fill/bid rate.

  • Check on the opportunities with SSPs regularly (by having regular calls and correspondence). Make sure you work on all the available data centres, formats, geos, sizes, and you are open to their premium supply.

  1. DSPs:

  2. Make sure they are responding to bid requests on all the available endpoints.

  3. Check DSP’s win rate on the dashboard, and address the issue if it is less than 10% for native and banner.

  4. Check errors on the DSP’s end and inform partners about problems preventing them from winning on your supply, especially if there are timeouts. Make sure the problems are fixed.

  5. Update the settings regularly (at least every other week), keep track of updating the settings.

  6. Make sure you work on finding out what prevents your partner from spending more on your traffic, and eliminate these problems.

  7. Check if the DSP is not reaching its spend and/or volumes cap. If the DSP is reaching its spend cap, and there is no discrepancy, increase it. If the DSP is reaching its cap in terms of volumes, and there is no discrepancy, ask a partner if you can increase the volumes, and increase the cap.

3. Check billing report:

  • Solve discrepancy issues (if it exceeds 5%);

  • Reach out to partners that stopped working -> find out the reasons and get them

back;

  • Reach out to partners that started spending less -> find out the reasons and get their numbers back to normal;

  • Increase the spend with ‘stable’ partners.