Overview
AerServ utilizes a simultaneous or parallel ad request technique. This means that all RTB and API (Server to Server) buyers receive the ad request at the same time from the ad server. This is different than the traditional waterfall technique where only one buyer at a time is called and buyers below the top spot in the waterfall are only called if the buyer or buyers above them do not fill the ad request. The waterfall approach can result in significant latency based on how many buyers are included within the waterfall and how many of them must be called before a filled request is received.
The simultaneous ad call technique decreases the amount of time required to find a filled ad, thus allowing AerServ to return ads quicker to the publisher. The simultaneous approach also increases CPMs since all buyers compete against each other in a single unified auction by providing their best price. In the traditional waterfall approach a buyer does not compete against other buyers, they just need to fill the ad request when sent to them and they are guaranteed to serve the ad.
In addition to sending simultaneous ad requests from the ad server, AerServ also calls the SDK Mediation buyers simultaneously from the client which also decreases latency and allows us to serve ads quicker.
Even though AerServ calls buyers simultaneously there is still some latency depending on the publisher integration setup, types of buyers called and the user's connection speed. Below is a breakdown of the potential latency associated with each ad source type.
Table of Contents
Types of Buyer Ad Sources
Direct/House ads are ones where AerServ hosts the actual ad assets (image, video, etc.), so a call to a third party is not needed to retrieve the ad, requiring much less time to process the ad request.
RTB buyers operate within the IAB (Interactive Advertising Bureau) RTB protocol which was created to expedite the ad request and ad response process, resulting in much quicker response times from buyers.
API/S2S buyers have their own custom ad request and response format which is unique to each one. S2S buyers typically take longer to respond.
Custom tag buyers provide AerServ with a JavaScript tag which is entered directly within the platform. The code is not executed until it is sent to the user's device so these types of tags can be returned very quickly.
Custom VAST tag buyers provide AerServ with a URL which must be called in order to retrieve the Video VAST XML. These types of tags are often called from the video player on the user's device, but AerServ validates ads before sending them to the publisher to ensure that an ad exists and that it satisfies the publisher's targeting requirements. These tags are called from the ad server before sending them to the user's device. There is some latency involved with unwrapping each level of the VAST tag.
These types of buyers can only be called from the AerServ SDK on the user's device. These buyers typically are the slowest to respond which is why AerServ recommends they be requested via a pre-load call so the SDK has enough time to retrieve and prepare the ad prior to the publisher wanting to display it.
Response Time by Buyer Ad Source
| Buyer Ad Source Type | Max Response Time | Who Controls Timeout Limit | Buyer Ad Source Type Availability |
|---|---|---|---|
|
Direct/House Ads
|
N/A | AerServ | AerMarket |
|
RTB Buyers
|
240 milliseconds | AerServ | Mediation & AerMarket |
|
API/S2S Buyers
|
1 second |
AerServ Publisher can increase it, but not decrease it. |
Mediation & AerMarket |
|
Custom JS Tag
|
N/A | AerServ | Mediation & AerMarket |
|
Custom VAST Tag
|
5 seconds | AerServ | Mediation & AerMarket |
|
Mediation SDK
|
6 seconds | Publisher can change default limit. | Mediation |
Breakdown of Time per Ad Request Type
In addition to the time provided for a buyer to respond to an ad request there are also other steps in the process which can add to the latency of returning an ad to the publisher.
These additional steps can include the following:
- Internet Latency
The time required to send the ad request from the user to AerServ and the time for AerServ to respond to the user with an ad. It is impacted by the user's connection speed (Cellular or Wifi), how far away from the AerServ data center the user is located and how large the ad markup is that is returned to the user.
- Budgeting & Targeting Checks
These are checks AerServ does prior to sending the ad request to buyers to ensure that the buyer only receives ad requests that meet their requirements such as from a certain geographic area, operating system, etc.
- Buyer Connection
Prior to sending an ad request to a buyer, AerServ must first establish a connection with them. AerServ allows up to 300 ms to establish a connection, but it typically happens much faster than that.
- Ad Validation
After a buyer returns an ad, AerServ validates the ad to ensure that it meets the publisher's requirements and that there is an ad. For video ads, AerServ unwraps the VAST to make sure there is an ad.
The validation checks can include making sure an ad only contains secure assets if requested, checking if the ad is MRAID or VPAID, checking how long the video ad is, etc. The time required for validation depends on how many checks must be done and if the ad is banner or video. Validation for video ads typically takes longer because the VAST may need to be unwrapped.
The following steps occur after AerServ has sent the ad to the user and before the ad can be displayed on the user's device:
- User Device Ad Processing
Once the ad is returned to the user, there is typically a small amount of time required by the device to process the response and begin displaying it.
- Download of Ad Assets
Once the user's device has processed the ad response, it must then download the ad assets in order to display them. Often these assets must be retrieved from a third party server and the time required to do so depends upon the size of the file(s) and the speed of the user's connection. Video ad files are typically much larger and require more time to download.
Response Time Examples
Banner Ad Request and Response
| Request Phase | Average Time | Max Time |
|---|---|---|
| Request from User | 20 milliseconds | 40 milliseconds |
| Budgeting & Targeting Checks | 5 milliseconds | 50 milliseconds |
| Establish Buyer Connection | 30 milliseconds | 300 milliseconds |
| Buyer Ad Response (S2S & RTB Buyers) | 130 milliseconds | 1 second |
| Ad Validation | 5 milliseconds | 50 milliseconds |
| Return Ad to User | 20 milliseconds | 40 milliseconds |
| Total | 210 milliseconds | 1,480 milliseconds (1.48 seconds) |
Video Ad Request and Response
| Request Phase | Average Time | Max Time |
|---|---|---|
| Request from User | 20 milliseconds | 40 milliseconds |
| Budgeting & Targeting Checks | 5 milliseconds | 50 milliseconds |
| Establish Buyer Connection | 30 milliseconds | 300 milliseconds |
| Buyer Ad Response (S2S & RTB Buyers) | 300 milliseconds | 1 second |
| Unwrap VAST (300 ms per VAST unwrap) | 300 milliseconds | 5 seconds |
| Ad Validation | 5 milliseconds | 50 milliseconds |
| Return Ad to User | 20 milliseconds | 40 milliseconds |
| Total | 680 milliseconds | 6,480 milliseconds (6.48 seconds) |
Video Ad Request and Response (SDK Only)
| Request Phase | Average Time | Max Time |
|---|---|---|
| Request from User | 20 milliseconds | 40 milliseconds |
| Budgeting & Targeting Checks | 300 milliseconds | 2.6 seconds |
| Establish Buyer Connection | 30 milliseconds | 300 milliseconds |
| Buyer Ad Response (S2S & RTB Buyers) | 300 milliseconds | 1 second |
| Unwrap VAST (300 ms per VAST unwrap) | 300 milliseconds | 5 seconds |
| Ad Validation | 5 milliseconds | 50 milliseconds |
| Return Ad to User | 20 milliseconds | 40 milliseconds |
| SDK Mediation Adapter Response | 3 seconds | 6 seconds |
| Total | 3,975 milliseconds (3.975 seconds) | 15,030 milliseconds (15.03 seconds) |
Best Practices
- Call Pre-Load 30 Seconds Prior
Due to the additional latency that can be added when requesting ads from a Mediation SDK, AerServ recommends calling Pre-Load 30 seconds prior to the time the publisher wants to display the ad so AerServ can ensure there is enough time for all of the buyers to respond.
- JS Pros & Cons
Although Custom JS tags require little time to respond to the request, there is no guarantee that the buyer will fill an ad since AerServ is unable to check for a filled ad on the ad server because the ads are requested from the user's device.
- Set High Limits
When configuring how many Mediation Adapters can be called simultaneously from the SDK for a Wifi connection, AerServ recommends that the publisher set the limit as high as possible without it negatively impacting the app performance and bandwidth consumption.
Comments