THEO Blog

Monetise your content with THEOplayer and Google DFP DAI pre-integration

At a time when the popularity of online video surges, so do online video ads. Advertisers found in video a new source of monetisation. But in parallel with an increasing amount of video ads, more and more ad blockers get installed. In a previous article we already discussed the current state of online video advertisement, showing the differences among client-side ad insertion standards (VMAP, VPAID and VAST) and how THEOplayer supports them. With the increased popularity of ad blocking software, the online video market needs new strategies to be able to monetise its content. For this reason THEOplayer added support for the DoubleClick For Publishers’ (DFP) Dynamic Ad Insertion solution.


What exactly is DFP DAI?

DoubleClick For Publishers is an ad network owned by Google. It offers a wide range of advertisements, which were traditionally dynamically inserted on the client side. This means that the advertisement is added after the page has loaded based on the visitors interests. Recently, DoubleClick for publishers added support for Server Side Ad Insertion (also known as Dynamic Ad Insertion).

To understand what server side ad insertion is, it helps to consider what client side ad insertion is, what its limitations are and where they both fit in the advertisement realm.


Where we come from: client side ad insertion

Client side ad insertion, currently, is the most common way of showing featured content to gain revenue from free online video content. The content and the ad are typically strictly separated: the video player will load the main content and the advertisement independent of each other. Client side ad insertion is empowered by industry-wide specifications (VAST, VMAP and VPAID), which ensures that a video-player can easily play advertisements from any compliant network. This reduces the set-up cost and makes it easier to migrate from one provider to another.

Client Side Ad Insertion Workflow
Client Side Ad Insertion Workflow

Client side ad insertion, however, comes with technical limitations:

Ad Blockers: As the content and ads are independent from each other, it becomes easier for an ad blocker to target just the sponsored content. A fight back strategy is to block the content if advertisements were blocked, but fact remains that a video player cannot cancel the effects of an ad blocker.

User experience: In practice, the encoded qualities of the ads and the content might differ, triggering a small quality change. The user might also experience a small delay for setting up the advertisement. While this can be reduced by using preload, not all advertisements (e.g. VPAID) can be preloaded.

Inserting video ads in a live-stream: When a video player plays a video ad (linear ad), it typically pauses the main content. This is not ideal for live streams because of its continuously moving timeline. When a video advertisement is shown, the viewer will be N seconds behind when the content resumes. The player is then forced to make a decision, where neither option is ideal:

  • Stay behind the live point: the viewer will not see the latest and might possibly experience a less smooth playback if the live stream only has a very short live window.
  • Jump to the live point: the viewer will miss content, which they might never see again.

When you use client side and live streams, we recommend to only show a video advertisement before the content starts and only use banner ads during the live stream.


Where server side ad insertion fits in

Server side ad insertion tries to solve the limitations of client side ad insertion by inserting all advertisements directly in the stream.

Server Side Ad Insertion (SSAI)
Server Side Ad Insertion Workflow

Server side ad insertion has multiple advantages compared to client side ad insertion:

  • Ads are harder to block: they become part of the stream, which makes it difficult for an ad blocker to filter the ad without blocking the main content as well.
  • Better user experience: as the ads are part of the stream, the viewer will experience no changes in quality and no buffering between content and ads
  • Better solution for inserting advertisements in live content: the content creator can precisely indicate when it is appropriate to insert an advertisement. The player will not get behind the live point by showing this sponsored video content.
  • All advertisements can be personalized to the individual, which gives server side ad insertion a big edge over traditional television.

As the advertisements are put in the live stream, - in theory - any video player should be able to show the advertisements without prior pre-integration.

The reality is more nuanced: end-users, advertisers, integrators and other stakeholders have high expectations, which results in additional requirements:

  • End-users are typically interested in the remaining duration of the ad break. They might be interested in the sponsored content and click through to the advertisers landing page.
  • Advertisers want to measure how their campaigns are performing and demand tracking of the advertisements. This is also key for monetization, as some ad network business models are built around this premise.
  • Player integrators might be interested in the advertisement metadata, so they can implement a custom experience that fits their customer needs.

To satisfy these demands, a video-player needs metadata. Currently, there is no industry-wide adopted standard that describes how this information should be exchanged from the ad insertion server to the player. This is why every solution takes a slightly different approach, which implies that a video player needs to create a unique integration.


Limitations of server side ad insertion

Ads inserted at the server side can be as interactive as client side VPAID advertisements, by adding a JS script to execute, although nobody has implemented it. Yet. VPAID advertisements are self-executing ad units that load their own logic to build a custom experience for the viewer. Server side ad insertion, compared to client side, is harder and more expensive to set up than its client side counterpart. To make this process easier, THEOplayer added support for DoubleClick For Publishers’ server side ad insertion solution.


THEOplayer and Google DFP DAI Integration

Google DFP wants to solve challenges such as intrusiveness or video content not playing after an ad break with its Dynamic Ad Insertion (DAI) solution. THEOplayer is now pre-integrated with Google DFP DAI, allowing you to deliver the most enjoyable viewer experience.

The broadcaster makes its content available to the Google DFP SSAI service, including cues to indicate what parts of the content can be replaced by ads.

THEOplayer and Google DFP

After THEOplayer requests the HLS manifest from the Google DFP SSAI servers, the server starts a personal session, preparing the content that should be delivered to the end-user. The process for searching ad opportunities starts and if it finds any, the service will request sufficient personalized ads to fill the ad slot. The advertisements are now combined in the stream and the content can be transcoded to a stream manifest. This will then be delivered to THEOplayer, which plays the stream and forwards all ID3 cues it detects to Google DAI, a client-side Google library. Google DAI will then track the ad progress and will update the player by forwarding metadata. Check our demo here.

SSAI THEOplayer Google DFP
THEOplayer Integration with Google DFP DAI. Note: this is a simplified presentation.



Subscribe by email