Client Side vs Server Side Ad Requests

Client Side vs Server Side Ad Requests

I worked with advertisement domain industry for a long time, and now again I got the opportunity to research on the same topic for one of my current project POC (Proof of concept ) after a couple of years gap in this domain. I came across some interesting facts which I would like to share with you guys. Hope this article helps you to understand the two major approaches for serving ads.

Recently we observed, we were losing ad impressions due to ad blockers which are enabled from user machine, as we are using client side ad serving approach and we were also looking towards providing better user experience for video viewers. We started investigating the best approaches to solving this issues and doing some research on client side vs server side approaches.

Here we are going to discuss the client-side vs server-side ad serving approaches in detail, let's start with the research documents references first.

What does research say?

Now, in 2017, the tide has shifted once again towards server-side as a result of two trends:

  1. The increasing prevalence of ad blockers, and
  2. The near ubiquity of Apple’s HLS format.

We’ve seen research that suggests almost 28% web users have a blocker turned on. That’s a lot of lost impressions. Fetching ads server-side skips over ad blockers, which is one of the big reasons why server-side is having a resurgence. However, using this advertising approach is cost-effective only if there’s a server-side playlist format with a very wide reach. If there isn’t one, you’re spending all your time building clients for the playlist format. In the last few years, HLS has gained traction as an almost universal playlist format. Almost every new platform and device in today’s video-enabled, the internet-connected universe has added native support for HLS (thePlatform has also encouraged this trend by adding support for HLS in the Player Development Kit and App Development Kit).

Based on the research Moz consumer survey, by 2017, 80 percent of all internet traffic will be online video traffic. and the increased demand for online video content has online video advertisers racing to get ahead. while doing research I read out almost all blogs, articles to understand the ads trend in the industry, this is just a summary of all my research.

Why is server-side ad insertion getting popularity nowadays?

Today, video content is typically served from the content delivery network (CDN), whereas ads are usually served from third-party ad servers. These two delivery methods are only combined at the browser level when viewers start watching videos. Ad blockers take advantage of this fragmented delivery by preventing ad-serving domains from delivering content, but still allowing viewers to access publisher content.

By contrast, server-side ad insertion, also called ad stitching, attaches targeted ad content to video content much earlier -- at the content management system (CMS) level rather than at the browser level. It bypasses ad blockers by serving both pieces of content in one package, making it impossible to separate the two. But it also has several other advantages that benefit viewers, advertisers and content creators alike. Here are just a few:

  1. According to viewer experience point of view

If there’s one surefire way to put off a consumer, it’s buffering. Waiting forever for a video to load, or worse still, watching an ad with no video afterward is one of the biggest buzzkills around. As a matter of fact, 64 percent of consumers cite slow load times as a key reason for enabling ad blockers.

Linking an ad to a video before it’s served, rather than on the fly, is the best way to eliminate buffering. Because the ads and video are part of the same content package, they’re optimized to match each other in performance, quality, and specs. The video player doesn’t need extra time between them to readjust. The result is a more TV-like experience that gives servers, users, and advertisers the expected content without the hassle of buffering.

2. According to ads delivery point of view

If you thought buffering made users angry, just see what happens when the page crashes after they sit through the pre-roll, forcing them to reload the page and watch the pre-roll again. Client-side advertising requires a lot of per-platform code, especially when the user is watching video through an app. This doesn’t just mean higher development costs for the one implementing the page or app; it also means a fragile playback experience for the user. A 100% server-side ad solution is far less complex to build and manage, and is also less likely to crash, no matter the environment.

3. According to personalization approach point of view

The main objective of any advertiser is not just to have an ad delivered, but to have it seen. No one wants to create and pay for delivery of an ad only to have it blocked just before it is seen, a real possibility in a world where viewing rates hover around 54 percent. Yet only linking ads with content at the server end isn’t the answer either; ads stitching alone makes it difficult to measure who’s watching ads and who isn’t. Luckily, there is a solution: ad stitching can be combined with lightweight client-side validation to see impressions. This blended approach offers the advantages of ad stitching while ensuring ad spend isn’t wasted on blocked ads.

Server-side ad insertion is a vast improvement over existing ad-blocking systems. Better content delivery means more engagement, less pushback from viewers, and ultimately a more productive relationship between advertisers, publishers, and consumers. And in the end, stronger relationships are what all of us are after.

Let's get into more details now, how it works.

How do ads serving works?

Typically, Ad Request made from either client (website/ app) or ad server, If ad request correctly served then it's doesn't matter for the advertiser from where adRequest served, but if because of any reason ads not served correctly this matter a lot and it can negatively impact the fill rate. For this reason, many advertisers create their own API's.

The most common error when making ad requests from the server is sending the IP Address and User Agent (UA) of the server instead of the IP and UA of the client who made the ad request. If the server credentials are being passed then the advertiser will see requests from the same IP and UA over and over and will most likely not fill many if any of the requests.

The server side ad request should use the same values passed in by the client to ensure the proper request is being made. The server should be configured to forward the client headers to make sure the proper data is being passed to the advertiser.

Some advertiser’s APIs require that the client headers be forwarded but also require you to pass along the client IP and User Agent through parameters to make sure they receiving the correct values. When making ad requests through an API, the chances of sending incorrect data (server data instead of client data) is less likely due to the inclusion of specific data points and advertiser provided documentation to guide you. The chances of errors occurring are much higher when making a server side request to an advertiser without the aid of an API.

Advertisers want to limit the number of invalid ad requests they receive, and for this reason, they discourage server side ad request accept through a properly exposed API. If done properly, an advertiser should see little difference between an ad request from the client or the server, but it is best to communicate with the advertiser how you are requesting ads from them so they can make you aware of any special requirements they have and to help you investigate any problems should they arise.

Technical details how ads serving works, refer below article for more details

https://www.adopsinsider.com/ad-serving/how-does-ad-serving-work/

Conclusion

Today, OTT multiscreen has become the inescapable part of our everyday lives. A well-designed server-side ad insertion system overcomes the limitation of client side insertion by performing appropriate integration with the broadcaster to ensure the integrity of the live broadcast. So if you want to create a unified viewing and advertising experience for your viewers then go for server-side ad insertion platforms.

My POC (proof of concept) is still in progress, I will keep posting further details with some few interesting facts. Please keep in touch.

Ajay Bodhe

Engineering Leader

8 年

Nice one Buddy..Stitching is there in vast 4.o rt?

Pankaj Parkar

Principal Application Developer | GDE | ex-MVP

8 年

Very well written, Thanks for sharing :)

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

Imran Shaikh的更多文章

社区洞察

其他会员也浏览了