Evolution of Digital Ad Serving - Part I

Evolution of Digital Ad Serving - Part I

In the early days when there were no AdServers to show dynamic ads, publishers used to embed ads statically along with their contents. So to display a new ad in a given slot, the publisher has to change their contents every time to embed the new ad. Moreover every user will see the same ad at a given instant of time.

No alt text provided for this image


With the growing trend to start utilizing digital space for advertising, it becomes more obvious to utilize the power of digital world for advertisement, as it gives more control over the way ads can be displayed. It is easier to get measurable direct feedback that can be utilized to optimize campaigns, which is very difficult with other mediums of advertisement (Print, TV, and Radio), even today. Therefore one needs to have an intelligent system that could dynamically consider this feedback and decide which ad to serve for a given user at runtime. This is where AdServer comes into the picture. In early days publishers were using ad servers like DART Enterprise (by DoubleClick now acquired by Google Inc, at present, there are more companies that provide publisher AdServers DFP ( DART for Publishers), AdZerk etc. ). AdServer enables publishers to manage advertisers' campaigns to show ads dynamically on their portals. In this case, publishers have their own channels to get direct ads.

To integrate with AdServer in place of direct static ad, the publisher now uses Ad-Tag provided by AdServer. This Ad-Tag fetches ads from AdServer dynamically in real-time.

No alt text provided for this image

 

With the introduction of AdServer in the market, publishers were dynamically able to show different ads from different campaigns. With time they started facing problems of not having sufficient demand (Advertiser Campaigns) to show ads round the clock and fill all the ad slots. As many publishers started facing this issue, it gave way for mediators to rise between publishers and advertisers, which we know as Ad Network. To integrate with Ad Network, publisher AdServer provides a mechanism called pass back / Default Ad-Tag. Publishers need to register with Ad Network to get their Ad-Tag for an Ad slot and configure the same Ad-Tag as pass back / default tag in publisher Ad Server. This way in the event a publisher AdServer doesn't have any ad/campaign to serve through the direct channel, it passes this opportunity to Ad Network to serve the ad. In this situation even Ad Network doesn't have any ad to serve, publishers can pass on the opportunity to another AdNetwork using a similar mechanism. This way publishers can create a chain of Ad Networks and monetize unsold/blank ad requests through other networks. Though the price will be much lower than the ads that the publisher gets through direct channels. 

No alt text provided for this image


With the presence of multiple Ad Networks in this space, publishers have different revenue models with different Ad Networks. Each Ad Network pays different pricing for a given ad request, so if a Publisher wants to generate more revenue they must pass the very first opportunity to an Ad Network which will pay more. However, challenge publishers started facing is that one Ad Network consistently was not able to provide higher revenue. Dynamics changes with time, as well as demand (Advertiser campaigns) an Ad Network has at a given time. These parameters keep on changing over the period of time, which results in a situation where at one time "Ad Network 1” pays more and the other time “Ad Network 2”, and some other time any other “Ad Network” will pay more. In order to maximize revenue, a publisher had to keep on monitoring the revenue being generated through different Ad Networks and keep on changing the pass back chaining to provide the first opportunity to an “Ad Network” which pays more for a given duration. This way Publishers have to apply a good amount of human resources to do all this manually.

What if this process of manual work is automated? This new automated system will process the historical and current data of revenue generated through different Ad Networks and dynamically decide which Ad Network will get an opportunity to serve the first ad or subsequent ads. This system is nothing but SSP (Supply Side Platform) like PubMatic, Rubicon Project, and Ad Meld. SSP acts as a Revenue optimizer for Publishers by dynamically predicting which Ad Network will pay more for the given ad request. To integrate with SSP, publisher registers with the SSP and then they will provide Ad-Tag for given Ad Slot. Publishers configure this Ad-Tag as pass back Ad-Tag in their Publisher Ad Server in place of Ad Network ad tag. SSP gets an opportunity in the event Publisher Ad Server doesn't have any direct ads to serve. SSP will select an Ad Network which will pay more as per their prediction, and hence lift publisher's revenue.

No alt text provided for this image


Now the revenue optimization problem of Publisher becomes the problem statement for the SSP and they started exploring more ways through which revenue of publishers can be lifted. Meanwhile, RTB (Real-Time Bidding) in Digital Advertising was taking traction in Ad Exchanges (Will talk about Ad Exchange in Separate article). SSP’s also introduced RTB features in their platform which in turn started providing additional revenue lifts to the publishers.

No alt text provided for this image


Matthew Longley

Founder at Forestry.com - Marketplace and education for the forestry industry.

9 年

So what is Agnie's role in all of this? Does Agnie primarily act as the ad server or can the software also act as an SSP? I have been looking for a good SSP software solution

回复
Chaitanya K.

Data Integration | Test Management | Program Management | Automation Consulting

9 年

Very informative.

回复

Good overview, Pandurang! Keep these type of articles flowing.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了