In order to decide which ad to serve when, our ad server uses the tiers and weights assigned to ads as in relation to each other in addition to any targets and limits assigned to each ad specifically. The ad server then sends the client an ordered list of ads to display. This list is ordered as follows:
- The ad server determines whether an ad is eligible to serve based on the targets and limits assigned to that ad. For example, if an ad is geo-targeted to be US only, it is ineligible to serve to a user in Canada. Likewise, an ad set to serve only on weekdays between 11 am and 4 pm Pacific is ineligible to serve on a Saturday.
- Ads that are eligible to serve are grouped by tiers by ascending tier number. That means that all ads in Tier 1 must fail to load before the SDK will attempt to load an ad in Tier 2.
- Ads within a tier are sorted based on their weights using a pseudorandom number generator. For example, consider the case of having two ads in a tier. Ad A has a weight of 100 while ad B has a weight of 50. Ad A will be the first to be attempted to load 66% of the time (100 / 150) while ad B will be the first in line 33% of the time (50 / 150).
Once this ordered list of ads is constructed, our ad server looks to see if any ads will always load (i.e. they are not third-party SDK ads. House ads and server-side feed ads always serve). If our ad server finds these, it truncates the ordered list sent to the client at the first occurrence of one of these ads.
It’s important to note that our SDK requests ads from partners only when ads are needed. We do not keep requesting ads from ad networks/exchanges in the background or request ads from partners unless the ads requested are to be shown to a user. This ensures that your CTR is not artificially lowered by requesting ads that are not going to be seen by a user.