> ads can be requested server side by sending the URL where the ad will be displayed through an API. The response contains the ad code, as well as the expiration date
So, while adserver waiting for an ad from the RTB waterfall, then your server would wait too. It's not best practice I guess.
Besides that, many of your points already adopted by all ad networks. Many of the ad sector's problems directly related to advertisers. They want to measure everything, everything! There is a section in VAST definition called TrackingEvents. start, firstQuartile, midpoint, thirdQuartile, complete, pause, mute, click, skip ... goes on.
Agency make plans and send Vast codes to networks (for example sizmek vast code). We have many publishers well we have to measure that actions too. Stats has to be match. Then we are putting incoming vast to our adserver and it generates new one with wrapped vast. Then we are sending to publisher and of course they want to measure these actions too. They putting our vast code to their DFP and it generates new codes and ad goes to public.
Dfp Code > Our Adserver Code > Agency code
Then user sees the ad, for example video ad then tracking starts.
Impression: [Dfp, Our adserver, Sizmek]
Ad start: [Dfp, Our adserver, Sizmek]
First Quartile: [Dfp, Our adserver, Sizmek]
Midpoint: [Dfp, Our adserver, Sizmek]
Complete: [Dfp, Our adserver, Sizmek]
Click: [Dfp, Our adserver, Sizmek]
See, list goes on. One ad and many requests and counting. I am not talking about RTB waterfalls it is something else already.
We all have to measure this stats because many of the advertisers pay based on this measurements.
(you name it the currency)
%25 == 0
%50 == 0.003
%75 == 0.0055
%100 == 0.007