Smarthub Specification

1. Specification overview

SmartHub platform is an Ad Exchange White Label Solution (WLS) by SmartyAds Inc. that supports openRTB integration with SSPs, DSPs and other Ad Exchanges via openRTB connection. IAB openRTB protocol v.2.4 is supported, older versions are supported by default as well. We also partly support openRTB protocol v.2.5, please see p.3 for details. Native specs 1.0/1.1 are supported. Integrations with other SSPs or DSPs, as well as integrations with direct publishers and advertisers by tags, API, SDK, etc. are not supported on SmartHub.

SmartHub Specification is created to describe how integrations are done on SmartHub, how bid requests and responses are processed on the platform, and to simplify process of integration with new partners for you. Due to this, we did not include full description of each object or attribute in requests and responses here. You can find detailed information (data that should be included into objects and attributes in requests and responses, the format of data in objects and attributes, etc) in openRTB spec v.2.4.

2. Servers

2.1 Servers plans and locations

On SmartHub, you can choose to connect SSPs and DSPs and run openRTB auctions in the following regions:

  • US East (New Jersey)
  • US West (Santa Clara)
  • Europe (Amsterdam)
  • Singapore

You define the number of nodes connected to your WLS and the nodes region(s) when you choose the server plan during the initial setup, or change it with your Account Manager. In case you need to change the server plan, or add a node in a region different from those listed above, please contact your Account Manager.

2.2 Maximum server load

2.2.1 Incoming traffic volume

Each node you have allows processing 10k incoming QPS. If the maximum load on the node is exceeded, the server can get overloaded, which will lead to data loss, discrepancies with your SSPs and DSPs, and eventually to revenue loss. 

Neither you nor SmartyAds can directly control the volume of traffic your SSPs are sending to you. Due to this, please pay attention to the following:

  • You need to agree with your SSPs on the maximum traffic volume they send you and prohibit sending to the endpoints you shared more traffic than you can receive. Most SSPs are able to set QPS limits per endpoint.
  • Disabling SSP’s company or endpoint on your side does not decrease the load on the server. When you turn off endpoints on SmartHub, you stop sending SSP’s requests to DSPs, but the server still receives all requests.

As SSPs sometimes can suddenly increase the volume of traffic they are sending to you, we have added two protection mechanisms:

  • The system checks the incoming traffic volume each 10 minutes. Once the volume of incoming traffic exceeds your limit, all users that have permission access ‘Edit’ on your WLS, receive email notifications. Red alerts are also shown on SmartHub UI.
  • Once the system notices that incoming traffic volume is exceeded, the system stops processing extra requests (i.e. they are not parsed and not sent to DSPs). This mechanism allows you to decrease the load, but it cannot prevent the server from overload completely, therefore once you receive an alert, please reach out to your SSPs. 

2.2.2 Outgoing traffic volume

The volume of traffic you are sending is regulated according to the server plan you have. You need to set total QPS limits for your DSPs according to your plan.

If QPS limits for your DSPs in total exceed your plan, system will stop sending extra traffic. If some of your DSPs is not receiving traffic, please check if the QPS limits you set for DSPs do not exceed your plan.

3. General integration guidelines

SmartHub supports only openRTB integration by protocol v2.4, older versions are supported as well. Protocol v2.5 is supported only in part: you can call BURLs of your DSPs, any other v2.5 features are not supported, including sending your BURLs to SSPs. Native specs 1.0 and 1.1 are supported.

Before integrating a new SSP/DSP, please make sure the following statements are true:

  1. New SSP/DSP and you have servers in the same region.
  2. New SSP/DSP works by openRTB v2.4 or older.
  3. If your DSP works by openRTB v2.5, they only expect you to call their BURLs.

We strongly recommend that before integrating with new partners, you send them samples of your requests and responses of each format and ask them to confirm they can work with your requests and responses. You can find samples of requests and responses in SSP and DSP endpoints settings. In case your SSP/DSP has any specific requirements, please forward the following information to your Account Manager:

  1. Your SSP/DSP request and response samples.
  2. Your SSP/DSP specification file.
  3. Detailed information about the changes that have to be made on SmartHub side. 

Your Account Manager will review the requirements with SmartHub tech team and inform you about the result.

 

3.1 Integrating with SSPs

3.1.1 Integration recommendations

In order to prevent any issues with SSPs you connect and make it possible to scale up with your SSPs fast, we recommend that you take the following steps each time you integrate a new SSP:

  1. Make sure SSP runs openRTB activity 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.
  4. Send your bid request requirements for each format to your SSP. Please find the lists of requirements in 4.1.
  5. Create endpoints for your SSP and share them. Ask your SSP to send 100 QPS maximum in the first day or two.
  6. In several hours after you start the test, check the following:
  7. Check in the DSP/SSP Statistics tab if there are any errors on the endpoints you shared with your SSP.
  8. Check if bid requests contain all necessary data according to 4.2.
  9. Next day, check if statistics you recorded coincides with SSP’s statistics.

 

3.1.2 SSP integration common issues

Below is a table with common issues you can experience when integrating a new SSP. Please try the suggested solutions first, as they cover most common cases.

 

Issue

Actions

1.

Your SSP says it is sending traffic to your endpoint, but you do not see incoming traffic.

Check if SSP’s endpoints are enabled on your side.

Wait for at least 30 minutes. System may require time to start processing traffic.

Ask SSP to send you your endpoints they have set up in their system. Compare them to the ones you have on SmartHub. If SSP set up wrong endpoints, send them the correct ones.

Ask the SSP to send you hourly stats of bid requests. If they are sending less than 5 QPS (15k requests per hour), ask them to increase the traffic volume.

If you still see no traffic, ask the SSP to send you the following:

1. Hourly requests statistics they have.

2. Sample of SSP’s bid request with header. 

3. Response codes they receive.

Send this data to your Account Manager.

2.

Your SSP is sending traffic, but you are not bidding.

Check if SSP’s traffic is open to DSPs (for example, if you have SSPs whitelists in DSP endpoints settings).

Check if there are errors in SSP’s requests and if any of SSP’s requests are sent to DSPs in DSP/SSP Statistics tab. 

Check if SSP bid request samples contain all required fields.

If there are no issues with bid request format, check if the bid floors in SSP bid request samples are adequate. For instance, if your SSP is sending you banner requests with bid floor $5, it is possible that you do not bid, because you do not have demand with such prices.

3.

Your SSP is sending traffic, you bid, but SSP does not see your bid responses.

Ask SSP if they see timeouts from you. If there are timeouts, see p.4 in this table.

Ask SSP to send you a sample of bid response they would like to receive with header. Send the sample to your Account Manager.

4 Your SSP reports high timeouts percentage from you.

Check the bid request samples in SSP endpoint settings. You need your SSP to send you tmax minimum 60 ms. 

1. If SSP sends tmax lower than 60 ms, ask them to change the setting on their side.

2. If SSP doesn’t send tmax, ask SSP to send it. If this is not possible, ask SSP within which time the SSP expects you to respond (in ms). Put this time minus 10 ms into ‘Default tmax’ field in SSP endpoint settings. This should be done to leave extra time for your Ad Exchange to send DSPs’ responses to your SSP.

 

For example, your SSP tells you they expect you to respond within 200 ms – you need to put 190 ms into ‘Default tmax’ field. 

If tmax SSP sends is higher than 60 ms, ask SSP within which time they expect you to respond. Compare their answer with tmax they are sending. 

If SSP sends you tmax higher than needed, this is the reason of timeouts. Ask the SSP to send you correct tmax.

 

For example, your SSP tells you they expect you to respond within 200 ms, but in SSP’s requests you see tmax 250 ms, 300 ms, etc.

Ask SSP to ping your endpoint and send you the latency. Send the data to your Account Manager.
5 You have discrepancy with your SSP – SSP counts more than you.

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

1. Domain/bundle, impressions, spend

2. Publisher ID, impressions, spend

Compare data with yours. If you see domains/bundles or publishers that cause the discrepancy, ask SSP to block them.

Ask the SSP what is their impression expiry window. If it is more than 20 minutes, consult your Account Manager. 
Ask the SSP if they replace price macro in your ADM. If they can replace only macro in NURL, turn on setting ‘Price by NURL’ in SSP endpoint settings.
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 Account Manager.
6 You have discrepancy with your SSP – SSP counts less than you.

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

1. Domain/bundle, impressions, spend

2. Publisher ID, impressions, spend

Compare data with yours. If you see domains/bundles or publishers that cause the discrepancy, ask SSP to block them.

Ask the SSP what is their impression expiry window. If it is less than 5 minutes, consult your Account Manager.
Ask the SSP if they replace price macro in your ADM. If they can replace only macro in NURL, turn on setting ‘Price by NURL’ in SSP endpoint settings.
Ask the SSP if they filter out impressions on post-bid.
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 Account Manager.
 

 

3.2 Integrating with DSPs

3.2.1 Integration recommendations

In order to prevent any issues with DSPs you connect and make it possible to scale up with your DSPs fast, we recommend that you take the following steps each time you integrate a new DSP:

  1. Make sure DSP runs openRTB activity 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.

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

  5. Register your DSP’s endpoints on your platform. Open maximum 100 QPS per endpoint.

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

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

  8. Check if bid responses contain all necessary data according to 4.2.

  9. Next day, check if statistics you recorded coincides with DSP’s statistics.

 

3.2.2 DSP integration common issues

Below is a table with common issues you can experience when integrating a new DSP. Please try the suggested solutions first, as they cover most common cases.

 

Issue

Actions

1.

You opened traffic and DSP doesn’t receive requests.

Wait for at least 20 minutes after you opened traffic. System may need time to start sending traffic.

Check the DSP/SSP Statistics tab. If there is high timeouts percentage, check p.4 in this table.

Increase the traffic limit to 500 QPS and in 20 minutes ask the DSP if they started seeing requests. Some DSPs need higher traffic volume to start processing it.

Ask the DSP to send you a sample of request the would like to receive with header. Send this data to your Account Manager.

2.

You opened traffic, DSP receives it, but does not bid.

Ask DSP to check your bid requests and let you know what is the issue. If DSP has some specific requirements to requests, collect the following info from your DSP:

1. Sample of request DSP wants to receive and sample of response they will send to you.

2. Your SSP/DSP specification file.

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

Send all the data to your Account manager.

3.

You opened traffic, your DSP bids to it, but there are no impressions.

Check DSP/SSP Statistics tab.

1. If there are timeouts, check p.4 in this table. 

2. If there are errors in DSP responses, inform your DSP about them. 

Check if DSP’s bid response samples comply with your minimum requirements.

If there are no timeouts, errors or other issues with responses, check the valid responses quantity. If there are few valid responses (less than 1.5k per hour), ask DSP to increase their bid rate. 

If there are no timeouts, errors, and bid rate is high (at least 1 bid per second), consult your Account Manager.

4 You see high timeouts percentage from DSP. Inform the DSP about timeouts. Ask them if they can fix the issue.

If DSP cannot fix this, ask DSP to tell you the minimum time they need to respond to your requests (in ms). Set this value as ‘Min tmax’ in DSP endpoint settings. Wait for a couple of hours and check timeouts percentage.

 

Please note, that setting min tmax decreases the volume of traffic available for your DSP. We do not recommend setting min tmax higher than 350 ms. 

If your DSP cannot fix timeouts, and you see a high timeouts percentage, send the DSP’s endpoint to your Account Manager and ask to ping the endpoint.
5 You have discrepancy with your DSP – DSP counts more than you. 

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

1. Domain/bundle, impressions, spend

2. Publisher ID, impressions, spend

Compare data with yours. If you see domains/bundles or publishers that cause the discrepancy, block the sources for DSP.

Ask the DSP what is their impression expiry window. If it is more than 20 minutes, consult your Account Manager. 
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 Account Manager.
6 You have discrepancy with your DSP – DSP counts less than you.

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

1. Domain/bundle, impressions, spend

2. Publisher ID, impressions, spend

Compare data with yours. If you see domains/bundles or publishers that cause the discrepancy, block the sources for DSP.

Ask the DSP what is their impression expiry window. If it is less than 5 minutes, consult your Account Manager.
Ask the DSP if they filter out impressions on post-bid.
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 Account Manager.
 

 

4. Traffic and demand processing

4.1 Bid request processing

4.1.1 Flowchart

Flowchart 1. Processing bid requests

 

4.1.2 Bid request basic validation

When system receives a bid request, it validates the format and content. The requests should be sent via POST and be in JSON format. 

System checks if all required objects and parameters are present in the request. If some of the fields are missing, the request is considered invalid and is filtered out. The structure of requests should comply with structure of bid requests described in IAB openRTB spec 2.4, i.e. objects and parameters should be named and positioned accordingly. For instance, parameter ‘devicetype’ should be in object ‘device’ in openRTB spec v.2.4 – so if SSP sends it as ‘device_type’ or includes the parameter to a different object, it will not be validated by the system.

Below you can find lists of all objects and parameters that are required, recommended and ignored when you receive a request. All the other data that is present in requests is just passed to DSPs without changes. 

4.1.2.1 Objects and parameters required in banner requests
  • Object BidRequest – default:
    - id
  • Object Banner in object Imp:
    - w and h OR object array Format
  • Object array Format in object Banner – if height and width are absent in object Banner:
    - w and h
  • Object Site – for desktop and mobile web:
    - domain OR page
  • Object App – for in-app:
    - bundle
  • Object Device:
    - ua
    - ip OR ipv6
4.1.2.2 Objects and parameters required in native and push requests
  • Object BidRequest – default:
    - id
  • Object Native in object Imp:
    - request
  • Object Site – for desktop and mobile web:
    - domain OR page
  • Object App – for in-app:
    - bundle OR domain
  • Object Device:
    - ua
    - ip OR ipv6
4.1.2.3 Objects and parameters required in video requests
  • Object BidRequest – default:
    - id
  • Object Video in object Imp
    - only object is required
  • Object Site – for desktop and mobile web:
    - domain OR page
  • Object App – for in-app:
    - bundle OR domain
  • Object Device:
    - ua
    - ip OR ipv6
4.1.2.4 Objects and parameters required in pop requests
  • Object BidRequest – default:
    - id
  • Object Site – for desktop and mobile web:
    - domain OR page
  • Object App – for in-app:
    - bundle OR domain
  • Object Device:
    - ua
    - ip OR ipv6

4.1.3 Recommended objects and parameters

The more information is sent in request, the more chances there are that some DSP will respond to the request. The list of basic required objects and parameters covers only a small part of information about placement. 

There are three parameters that are highly recommended:

  • Tmax
  • Bidfloor
  • Secure

If your SSP is not sending you tmax, you will respond to it randomly, and there will be timeouts. You can ask your SSP how fast it expects you to respond and set default tmax in settings. However, the best solution will be if your SSP starts sending this parameter in requests, as at some point your SSP can change the value on its side and you will start timeouting.

If your SSP is not sending you bidfloor, you can ask SSP what their average bidfloor is, and set it as default bidfloor. This is not the best solution – the bidfloors always vary for different sources, geos, traffic types, etc. Therefore, it’s always better if SSP sends the parameter in bid requests.

If your SSP is not sending if the app/domain is secure, you can have discrepancies with your SSP/DSPs.

4.1.4 Peculiarities of processing some objects and parameters

4.1.4.1 Currency

Currency is always USD by default. If your SSP works with some other currency, processing such requests will require custom set up on backend.

4.1.4.2 Battr, bcat and any other blacklists

These fields are passed to DSPs, but are not taken into account by default when you bid to requests. We will enable filtering upon your request. Please note that this filter decreases bid rate multiple times.

4.1.4.3 Banner sizes

SmartHub supports only strict sizes for banner traffic – w and h.

4.1.5 Ignored objects and parameters

The following is ignored in requests:

  • Test parameter – SmartHub supports only live traffic and demand
  • Coppa related info – the info is passed to DSP but responses are not filtered based on it
  • Gdpr related info – the info is passed to DSP but responses are not filtered based on it

4.1.6 Additional validation

System checks the bid requests by the following parameters before sending them to DSPs:

  • Tmax value
    If tmax is less than 60 ms, the request will be filtered out.
  • Bidfloor presence and value
    If bidfloor is absent, you need to set default bidfloor is SSP settings. The bidfloor format is also validated – it should be float.
  • Compliance with DSPs’ targeting
    All targeting is taken into account – domains and bundles whitelists/blacklists, SSP whitelists/blacklists, geos, sizes, OS, carrier, etc.
  • Compliance with scanners data
    if you use scanners for a DSP, system checks if a request can be sent to this DSP according to scanners blacklists
  • Compliance with global blacklists you set on the platform

4.1.7 Repacking bid requests

When you send the bid request to DSP, it is repacked – certain parameters values are changed, and some parameters are added.

Here is the list of changes that are made to a request when you send it to DSP:

  1. The id of request is changed (string id in object BidRequest).

  2. Markup you set in EP settings is added to bidfloor.

  3. Up to 30 ms are deducted from tmax you received from SSP (the smaller tmax is, the less is deducted). This is done to leave additional time for SmartHub to respond to SSP when you get the response from DSP.

  4. USD is set as currency.

  5. Parameter at is set to 2 if it was missing in request (2nd auction type).

  6. Publisher id is added if it is missing in request (generated on backend). This is done because most SSPs do not bid if there is no publisher ID.

  7. Parameter test is removed.

  8. Geo object is added if it was missing in initial request (based on IP/IPv6).

4.1.8 Custom changes to bid requests

SmartHub is an Ad Exchange platform, this means that you do not have any info about traffic you receive but for the info you receive in bid requests from your SSPs.

This means that if your SSP doesn’t send you some real data about placement in the request (like size, duration of video, etc), it cannot be added on Ad Exchange side. For example, if your SSP doesn’t send you parameter “skippable” in a video request, you cannot know if the video is skippable or not - only the SSP that has the publisher connected directly can add this info.

If you need some info in requests for DSPs, and you do not receive it from SSPs – firstly please ask SSPs to send this info. If SSPs cannot add it, please reach out to your Account Manager, he will check if it can be added on SmartHub.

As Ad Exchange acts as a mediator between SSPs and DSPs, it’s also not possible to modify the placements from SmartHub side, and to customize the way ads are shown on web pages/in apps – as this should happen on side of SSP that has the publisher connected directly.

4.1.9 No bid

When you have no response to send to SSP, you respond with 204 No bid according to IAB openRTB specification: HTTP 204 “No Content” from the bidder.

 4.2 Bid response processing

4.2.1 Flowchart


 

Flowchart 2. Processing incoming bid responses

 

4.2.2 Bid response basic validation

When system receives a bid response, it validates the format and content. The responses should be sent via POST and be in JSON format. 

System checks if all required objects and parameters are present in the response. If some of the fields are missing, the response is considered invalid and is filtered out. The structure of responses should comply with structure of bid responses described in IAB openRTB spec 2.4, i.e. objects and parameters should be named and positioned accordingly. For instance, parameter ‘crid’ should be in object ‘bid’ in openRTB spec v.2.4 – so if DSP sends it as ‘creative_id’ or includes the parameter to a different object, it will not be validated by the system.

Below you can find lists of all objects and parameters that are required, recommended and ignored when you receive a response. All the other data that is present in responses is just passed to SSPs without changes. 

4.2.2.1. Objects and parameters required in banner and video responses
  • Object BidResponse – default:
    - id
  • Object Bid in object SeatBid:
    - price
    - crid
    - adm
4.2.2.2 Objects and parameters required in native and push responses
  • Object BidResponse – default:
    - id
  • Object Bid in object SeatBid:
    - price
    - crid
    - adm – should contain ‘native’
4.2.2.4 Objects and parameters required in pop responses
  • Object BidResponse – default:
    - id

  • Object Bid in object SeatBid:
    - price
    - crid
    - adm OR ‘ext’: URL

4.2.3 Recommended objects and parameters

It is recommended that DSP sends adomain and sizes for banner traffic.

4.2.4 Peculiarities of processing some objects and parameters

4.2.4.1 ADM

Once you receive ADM, you add your pixel to it before sending the response to SSP. The ad itself that is included into ADM by DSP is not validated on SmartHub side. Adding verification and parsing of each ADM you receive from DSPs on Ad Exchange level will increase the time you need to respond to SSPs several times, which will eventually cause high timeouts percentage. 

If your SSPs have any issues with ADMs you are sending, please reach out to your DSPs and ask them to fix the issue.

4.2.4.2 Ad size for banner, video, native and push

The ads are not validated, therefore SmartHub filters out ads with incorrect sizes, if sizes are indicated in bid responses.

This doesn’t concern native and push responses – they should always contain assets in ‘native’ in ADM, and the sizes of native are therefore always validated. (Again, only based on the information in the bid response – not on the physical properties of the ad unit).

4.2.5 Ignored objects and parameters

Currency is ignored in bid responses. It is always USD by default.

4.2.6 Additional validation

System checks the following parameters in bid responses:

  • Price
    Price should be higher than your bid floor

  • Crid
    System checks if you have blacklisted crid for SSP

  • Compliance with scanners data
    System checks if response can be sent according to scanners blacklists

  • Assets
    For native and push – system compares assets (size) of native and push you send in a request with assets in response

  • Size
    For banner and video, system validates the sizes in response – if they are sent by DSPs.

4.2.7 Repacking bid responses

When you send the bid response to SSP, it is repacked – certain parameters values are changed, and some parameters are added.

Here is the list of changes that are made to a request when you send it to DSP:

  1. Crid and cid are changed – your company name and custom ID are added before the actual crid, for example:
    crid 12345 -> crid yourcompany_987|12345

  2. Markup you set in EP settings is deducted from price.

  3. Bid ID is changed.

  4. USD is set as currency.

  5. Adomain is added if it’s missing in response (taken from data base). It’s better if your DSP sends it.

  6. Your pixel is added to ADM.

  7. DSP’s NURL is replaced with yours. You always send NURL to SSPs.

  8. DSP seat ID is changed to yours (ID of EP on backend).

4.2.8 Custom changes to bid responses

Please discuss any custom changes you need with your Account Manager.

4.2.9 No bid

Your DSPs can send you any No bid codes when they do not have a response to send you. 

4.3 Counting impressions/wins/clicks

SmartHub supports only counting impressions. Wins and clicks, as well as any other conversions are not counted.

4.3.1 Impression expiry window

Your impression expiry window is 20 minutes for all traffic formats and types. This value can be changed, but we strongly recommend not to. 20 minutes is the optimal time to wait for impressions on any traffic format without having discrepancies with most of SSPs and DSPs.

In case you decide to change your impression expiry window, setting general expiry window is supported – it will be the same for all your SSPs and DSPs. Setting a custom expiry window for one partner is not supported at this moment, as it will lead to discrepancies with other partners. 

4.3.2 Counting impressions for banner

You count impressions by ADM (ad markup, ‘ADM’ is a field in bid response). When you send a bid response to your SSP, you add your pixel to the end of ADM. Once the ad is loaded to the web page or to the application, your pixel is fired, and you count an impression. 

For SSPs:

Your SSPs can call your NURLs, or not call them – this will not affect your impressions count. 

For DSPs:

  • Your DSP counts impressions by ADM
    You do not need to change anything on your side.

  • Your DSP counts impressions by NURL
    Turn setting ‘Call DSP’s NURL’ in DSP EP settings. You will call DSP’s NURLs when your pixel is fired.

  • Your DSP count impressions by BURL
    Turn setting ‘Call DSP’s BURL” in DSP EP settings. You will call DSP’s BURLs when your pixel is fired.

4.3.3 Counting impressions for native and push

You count impressions for native and push by tracking pixel in ADM. The logic is the same as for banner traffic.

4.3.4 Counting impressions for video

You count impressions for video by ADM. You count an impression when video ad is loaded. The logic is the same as for banner traffic.

4.3.5 Counting impressions for pop

There are 2 options how you send pop responses:

  • with URL in extension,

  • with pixel in ADM

In first case – you will count an impression when your SSP calls the URL. 

In second case – you will count an impression when the pixel in ADM is fired on web page / in app.

4.4 Counting spend

For SSPs:

You need your SSPs to replace macro ‘${AUCTION_PRICE}’ in ADM with the winning price. If your SSP cannot replace macro in ADM, and can only replace it in NURL, turn setting ‘Price by NURL’ in SSP EP settings.

System does not recognize if you work with your SSP by 1st price auction type, or by 2nd price auction type, no setting needs to be made if you work by different auction types with your SSPs.

When you record ‘SSP spend’ (the cost you will pay to your SSPs), you take the value that SSP passed you by replacing ${AUCTION_PRICE} macro.

For DSPs:

You replace ${AUCTION_PRICE} macro both in NURL and in ADM your DSP sends you. When sending the price to your DSP, you add the markup % which is set by you in the SSP and DSP endpoints settings.

By default, you work by 2nd price auction type with your DSPs.

 

5. Traffic types and formats support

SmartHub supports working with the following traffic types:

  • Desktop

  • Mobile web

  • In-app

The following formats are supported:

  • Banner

  • Native

  • Push

  • Video

  • Pop

Ad Exchange acts as a mediator between SSPs and DSPs, so when it comes to types and formats above, you can work with inventory and ads of any sizes and with any properties as long as 2 conditions are met:

  1. Bid requests and bid responses you receive comply with openRTB spec and with SmartHub basic requirements
    OR
    You have agreed on custom format with your partner, and SmartHub tech team added necessary changes on your side

  2. Your SSPs and DSPs support working with according inventory/ads.

For example, all versions of VAST, VPAID, MRAID, all MIME types, etc are supported – as you pass the data between SSPs and DSPs.

6. Miscellaneous

6.1 GZIP compression

Receiving compressed requests from SSPs and compressed responses from DSPs is supported by default. Sending compressed requests and responses is not supported by default at this point, please contact your Account Manager if this feature is needed.

6.2 Cookie Sync

Possibility to sync desktop and mobile web traffic with SSPs and DSPs can be added to your platform, please contact your Account Manager for details.

6.3 Encryption

Data is not encrypted on the platform. 

6.4 Throttling system

You have in-built throttling system which analyses your DSPs’ bid responses. It monitors to which kind of traffic your DSP bids and sends more of such traffic. System takes into account such fields as domain/bundle, geo, size, carrier, OS, connection type, etc.

Traffic to which DSP doesn’t bid, is also sent to DSP – but the volume is small. It is just enough for DSPs to start bidding to traffic to which they didn’t bid before.