Follow

Ad Request Latency and Best Practices

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

 

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

 

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 (Server to Server) 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 JS (JavaScript) Tag Buyers

 

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

 

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 the an ad exists and that it satisfies the publisher's targeting requirements, so these tags are called from the ad server before sending them to the user. There is some latency involved with unwrapping each level of the VAST tag.

  

   Mediation SDK Buyers

 

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.

 

Latency-Wiki-Graphics.png

 

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 it. 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.

   

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments