How to monetise World Cup football

Posted on

By Paul Davies, Marketing & Communications, Yospace

This month sees the kick-off of the 2019 FIFA Women’s World Cup in France in what promises to be the highest-profile edition of the tournament yet.  It will also see the finals of the inaugural UEFA Nations League, so we’re set for an eventful summer of high profile football that will garner significant monetisation opportunities for rights-holders worldwide.

I’ve picked three matches from the 2018 FIFA World Cup to illustrate some of the challenges to consider when looking to monetise major tournament football using server-side ad insertion (SSAI).  These examples highlight the need to implement the most reliable ad-tech and the most dynamic, too, in order to maximise the significant addressable revenue opportunities.

South Korea 2-0 Germany

The German team was the holder of the trophy going into the tournament and as such was among the most streamed during the World Cup based on data from Akamai, driving an average of 18.18Tbps average peak traffic during its matches.  Yet the team’s fate took an unexpected turn in the group stages, when the four-time champions were unexpectedly knocked out.

An earlier loss to Mexico suddenly heaped pressure on the German team for their final group match against South Korea match: 90 minutes which was previously expected to be insignificant, ended up drawing huge global interest.  In fact, this match – plus Mexico v Sweden, which took place at the same time – drove Akamai’s biggest traffic of the entire tournament.

This presented an opportunity for advertisers that would not have been planned before the tournament began, with a great many more viewers tuned in, engaged, and on the edge of their seats throughout.  Pressure wouldn’t just have been on Germany, but on broadcasters’ ad servers (ADS) which would have had to cope with an unpredicted swell in traffic.

Many ADS’s will have slowed at this point.  Adopting SSAI architecture with prefetch is the only way of monetising a broadcast-grade user experience at scale.

Croatia 1-1 Denmark

A match top-and-tailed with drama, this quarter-final game highlighted the need for an SSAI platform that is not only capable of delivering at scale, but is capable of doing so rapidly, and with very little fore-warning.

Two early goals in the match’s opening were followed by a slow 120 minutes, during which time many neutral viewers switched off due to the lack of action. Then, penalties – a situation that fans with a vested interest dread but a neutral supporter loves.  Whichever side you’re on, a penalty shoot-out is highly engaging for all viewers. Rights-holders had reason to cheer, too, with an unscheduled and lucrative ad break falling just before the most viewed moment of the match.

Unlike VoD, highly valuable ad breaks occur at exactly the same time for millions of viewers, requiring simultaneous ad calls to the ADS within a matter of seconds.  An SSAI platform must therefore support fluctuations in demand, and rapid, unpredictable variations in the number of concurrent streamers.

Brazil 1-2 Belgium

This quarter-final match between two of the tournament’s favourites featured global superstars including Neymar for Brazil and de Bruyne and Hazard for Belgium.  At half time the Belgians were leading 2-0, which prompted a greater surge in interest at the prospect of a goal-laden second half as the Brazilians mounted their fight back.

And the popularity of streaming wasn’t restricted to football’s traditional heartlands; Brazil vs Belgium was the most streamed event ever for America’s Fox Sports.

This was also a testing point for ad technology, with SSAI platforms tasked with the complex feat of making millions of simultaneous ad calls across the world, all with addressability enabled.  The ad break which fell just before play resumed in the second half may well have been the most valuable across the entire tournament, so advertisers and broadcasters had a lot to gain – and a lot to lose if their ad tech wasn’t able to respond as planned.

In this type of scenario a robust pre-fetch system is critical.  Yospace’s SSAI platform integrates with the broadcast automation systems – which hold all the information on programme and ad break timings – in order to look ahead to determine the length of the next ad break.  This allows it to pace calls to the ad server (ADS) over a prolonged period of time, which a) prevents the ADS being overloaded with simultaneous requests, and b) ensures the highest fill rates by allowing the ADS adequate time to respond.

With the right technology in place, broadcasters can realise the full value of live streaming while delivering consistent quality for the viewer, making sure that everyone is a winner.

Subscribe to Yospace’s mailing list for monthly news and insights

Best practice for monetising VoD with server-side ad insertion

Posted on

By David Springall, Founder & CTO at Yospace

The amount of video accessed online, particularly by mobile devices, is expanding exponentially.  As a result, there is a need to maximise the monetisation opportunities by delivering ads across multiple devices and platforms in the most efficient way possible.  In this post I discuss why applying SSAI across all content is the most logical way forward.

Server-Side Ad Insertion (SSAI, or dynamic ad insertion) can deliver a consistent experience akin to TV while opening up addressable advertising opportunities. Consistency comes in part from the ‘ad copy normalisation’ which is the process of transcoding ad content with the same bitrates, frame rates and audio levels as the underlying stream, ensuring a smooth transition between programme and ad and vice versa (with the same CDN being loaded for both content and ads).

SSAI technology is already being used successfully by broadcasters for live streaming.  However, the principal monetisation technique for VoD remains Client-Side Ad Insertion (CSAI), where, at the start of every ad break, the primary player is stopped and an ad player put on top, with the primary player having to be resumed at the end of the break.

For a broadcaster with both Live and VoD, it makes sense for a single advertising workflow to be applied across all content.  

It is possible for broadcasters to deliver a near-seamless experience using the CSAI model for VoD, by pre-loading the ad player and buffer in the background and swapping the players over at the exact moments when an ad break starts and ends. However, there is always the risk of playback issues caused by inconsistent encoding of the ad copy.  Also, considerable effort is required in terms of implementation, with code having to be continuously duplicated from one device type to another, and from one environment to another, with the inevitable testing and maintenance overhead to achieve this result consistently across devices.

Many of those broadcasters of VoD streams who have a working CSAI solution in place are finding it increasingly hard to maintain, so we’re seeing a growing interest in the SSAI approach.  This is partly driven by positive experiences of SSAI for live (where CSAI is not an option owing to the strict requirements around ad break timings). But there are a number of other reasons why SSAI should appeal to broadcasters over CSAI:

  • Implementation. The code is decoupled from the ad server, with the work on stitching and interfacing to the ad server being performed by the backend SSAI platform, giving an overall flexibility in that the inventory and decisioning engine is abstracted from the actual delivery. SDKs have also been developed, which means that there is effectively a middleware layer, with the SDKs talking to the backend, and the backend talking to the ad server, making it possible to swap out the ad server without changes to the SDKs.
  • Control. There can be a single point for all ad insertion calls across Live and VoD, a single interface providing access to a single set of Broadcast Streams, Promotions and VoD assets, and a single API providing real-time analytics.
  • Interactivity.The aforementioned SDKs can support the use of clickable linear content and dynamic overlays, and also allow broadcasters to customise the instances when skipping, seeking and pausing are allowed.
  • Ad blockers. The stitching used by SSAI mean that ad blockers are unable to decipher where the call to the server is being made, and so cannot differentiate between an ad and the content itself, making SSAI highly resistant to ad blocking.

Besides being able to deliver SSAI at scale and to provide all of the existing benefits of configurable user interactivity, SSAI has enormous security benefits, which cannot be totally covered in this article. In brief:

  • With SSAI, the aforementioned middleware layer affords control over the systems with which viewers are interacting. By contrast, with CSAI, the viewer’s device is touching the ad server and presenting its IP address (and potentially other information). The first party ad server might, in turn, involve the use of multiple third party servers and expose the same viewers to being tracked by unknown companies, to the possible detriment of a broadcaster’s commercial model.

With the correct deployment, there is no logical reason why broadcasters should not consider SSAI when deploying VoD streams. As OTT audiences for Live and VoD continue to thrive, providers are increasingly likely to seek a joined-up SSAI strategy, and by so doing, not only safeguard their current ad revenues, but also enhance them.

Read more on server-side ad insertion for live and VoD streams here.

Subscribe to Yospace’s mailing list for monthly news and insights

NAB 2019: Viewer Experience

Posted on

Three days down and less than one to go.  The voice is hoarse and the legs are tired but it’s been great to catch up with so many customers, prospects, partners and friends.  There’s a real change in the depth of detail of our conversations compared to previous years and it’s reassuring to hear people talk so highly of Yospace for server-side ad insertion, especially in a field where there is increasing competition.

I was very pleased to hear someone say today: “yes they do SSAI but they’re no Yospace.”  

For the last day we’re focussing our attention on some of the customer projects that have helped us earn our strong reputation…

Reducing ad load

The rise of OTT has seen many broadcasters urgently need to monetise online, and the challenge of retaining an audience has meant that a number of broadcasters have moved to reduce advertising with longer term benefits in mind. This is exactly what our customer Medialaan did on its live streams. The innovative European broadcaster allowed viewers on its Stievie service were able to rewind a live stream then receive shorter ad breaks to allow them to catch up with the live programming sooner.

The result was more engaged viewers, longer viewing sessions, and ultimately more ad breaks viewed.  Read about this more in our Medialaan case study.

Enhanced player support

The challenge of scaling live sports and their unpredictability demands any advertising system employed by a broadcaster to be both robust and versatile. Typically up to 90% of viewers tune into a football game within five minutes of kick-off, and it’s in situations like this that our pre-fetch system is crucial (read more about this in our Day One blog).

In addition to this, our SSAI enabled the broadcaster to monetise streams within an enhanced player and deliver on its ambitions to put the viewer front and centre of the action. Read more here.

Seven case study

Australian broadcaster Seven live streamed all 16 courts of the Australian Open.  Thanks to Yospace’s ability to feed back live telemetry data, Seven was able to prioritise the advertising based on the state of play of each court at any one time.

Find out more about this project in our Seven case study.

Subscribe to Yospace’s mailing list for monthly news and insights

NAB 2019: MPEG-DASH and CMAF

Posted on

Two days down and my colleague tells me we’re now exactly 54.8% of the way through the show.  Being at an event full of engineers I shouldn’t be surprised that someone’s actually developed an app for that.  Despite tired legs and croaking voice, there’s a buzz about NAB that makes me look forward to day three.  The speed with which conversations on concepts turn into new technologies means a show like NAB is always interesting.

Our main theme for tomorrow is SSAI support for MPEG-DASH and CMAF – two areas that have developed significantly in the last twelve months.

SSAI for MPEG-DASH

There’s been a lot of talk in the industry about MPEG-DASH.  Yospace was the first vendor to announce server-side ad insertion (SSAI) support for MPEG-DASH and isone of the only vendors today that has live customer services using it, so we’re in a strong position to talk from a point of experience.

The ecosystem for supporting MPEG-DASH is still relatively immature in terms of players, encoders and packagers.  Behind this is the fact that the specification for MPEG-DASH doesn’t specify exactly how an MPD should be expressed to support SSAI.  Read the thoughts of our Founder & CTO in this blog post.

CMAF

At 3.30pm our Founder & CTO David Springall will be presenting on the Bitmovin booth.  He’ll be discussing our integration points as well as server-side ad insertion for CMAF.  There’ll be an accompanying blog post – so check our Twitter and LinkedIn profiles to access it.

Subscribe to Yospace’s mailing list for monthly news and insights

NAB 2019: Server-Side Ad Insertion for VoD

Posted on

Day one, tick.  The show got off to a great start and we’ve had some really good discussions on scaling SSAI and maximising the potential of programmatic for live streams.  It’s a far cry from just a few years ago when most meetings would start with: “so what is server-side ad insertion??”

It’s pleasing now that most people we meet already know the answer to this question and are keen to get into the details of the technology.  We’re finding that discussions around consistency of viewer experience, measurement and data security are becoming more and more popular.

Harnessing the power of SSAI for VoD is our focus for day two at NAB.  Over the past year, we’ve seen a considerable increase in operators and MVPDs implementing SSAI for VoD to deliver viewing experience consistency throughout their device platforms.

Why is there a move towards Server-Side Ad Insertion for VoD?

In this article for TV Technology, Yospace’s Founder & CTO David Springall discusses why SSAI technology, which has been a staple of live monetisation for a number of years, is also proving to be a popular way of monetising VoD due to factors such as viewer experience, ease of maintenance and data security.

Data security is an especially important topic.  As operators and MVPDs increasingly rely on their first-party data to maximize ad revenues, having an effective middleware layer (SSAI) between the client and the ad server is crucial in protecting user data and preventing them from being re-targeted.

Total Video for TV4 pays dividends

Swedish innovator TV4 is an example of a broadcaster that’s making the most of a joined up live and VoD monetization strategy.  The broadcaster has recently agreed an extension with us to provide server-side ad insertion (SSAI) across its TV Everywhere service, TV4Play.

Mathias Berg, COO at TV4 Group said: “For the last couple of years TV4 has relentlessly been driving our business from a traditional linear ad model to a truly platform agnostic experience for both users and advertisers.  Part of this journey has been to enable us to capture and monetise on our digital inventory in all potential channels using all data available. As a result of a successful implementation of this strategy TV4 delivered its best financial result in terms of turnover and profitability in the history of the company in 2018.”

As a leader in the broadcast space that’s continued to reinvent itself, TV4 was one of the first broadcasters that recognised the value in using SSAI to monetize VoD.  Read this blog post to learn more about the company’s digital journey with SSAI.

Subscribe to Yospace’s mailing list for monthly news and insights

NAB 2019: Scaling programmatic for live events

Posted on

By Paul Davies, Marketing & Communications at Yospace

Welcome to Las Vegas.  Despite being home to a hundred resorts and 150,000 hotel rooms, it feels like I know everyone here during NAB week – whether it’s bumping into a customer in the cab queue or taking a table next to a tech partner – the broadcast engineering industry seems to take over the city during the event.

Our focus for the first day of NAB is scaling programmatic for major live events.  In order to maximise ad revenues, programmatic systems need adequate time to respond in a major live event set up, and this need is especially apparent in a low latency environment.

Programmatic vs. Low Latency

The ability to scale live SSAI and to plan for future scale, in an environment where all viewers see an ad break at the same time, is really important but is made more complex as there are two opposing forces at play:

  1. The need to allow programmatic platforms the time they need to respond to fully realise the value of the ad inventory
  2. Low latency support, which shortens the time available to the programmatic ecosystem

To maximise the revenue opportunity, it’s necessary to make ad decisioning calls in an orderly fashion way ahead of the actual break taking place.  Our prefetch system allows ad calls to be made early, allowing the time needed to return a full pod of ads for each viewer, and this is a crucial element of our offering that we’ve been sharing with visitors to our booth at the show.

You can read more in this blog post.

For a more in-depth explanation read our white paper.

Prebidding

Once you have prefetch in place you can plan for advanced programmatic; the next opportunity to explore is prebidding.  Prebidding replicates the benefits of web header bidding for video.  By calling all supply-side platforms simultaneously, we can inform the ad server of the responses to help it make an informed decision on which ads to place and ensure the highest available CPM can be secured.

Read more in this blog post.

Subscribe to Yospace’s mailing list for monthly news and insights

Partnering with a pioneer – a history of innovation with TV4

Posted on

By Paul Davies, Marketing & Communications at Yospace

Swedish broadcaster TV4 has long been a leader in the broadcast space, from going digital in the noughties and its early adoption of server-side ad insertion (SSAI) technology, to forming key partnerships with broadcasters and operators to grow its audience and boost ad revenue.

TV4’s innovative approach is paying off, too.  In the press release that announced the renewal of its contract with Yospace, the company’s COO Mathias Berg revealed that the company achieved its highest ever revenue in 2018.  He credited the ability to provide a platform-agnostic experience for advertisers across all video as a key factor, an experience that is enabled by SSAI.

TV4’s record earnings, at SEK 1,382 million (€112,537,903), were up 35.2% on 2017, making it one of the most successful broadcasters on the continent.

How did the broadcaster achieve these heights?  And how did it use SSAI to carve out its route to a profitable future – for TV4, for advertisers, and for its audience?

Digital ad stitching

TV4’s forward-thinking approach was apparent when it became the first broadcaster in Sweden to implement SSAI, notably adopting the technology for both live and on demand content to deliver a  consistent TV quality viewing experience, with one to one addressability and ad measurement.

SSAI has allowed TV4 to unlock new revenue opportunities by allowing for consistent monetisation of all its content across all connected devices, and for viewer data to be harnessed to inform and deliver addressable advertising.  This is a sector which shows no signs of slowing, with addressable TV ad spend forecast to exceed $3 billion by the close of this year.

Reinvention and investment

TV4’s CEO Casten Almqvist recognised back in 2012 that in order to outstrip the competition in Sweden’s TV market, the network must “continue to reinvent” itself, investing in its digital service TV4Play, while continuing to focus on “breadth, diversity and quality” and producing “engaging TV for the whole country”.

This prompted TV4 to turn to SSAI soon after, which in turn paved the way for another innovative move last year.  A first in Sweden, TV4 collaborated with Telia, Discovery Networks and Modern Times Group (MTG) in March 2018 to launch a targeted advertising initiative on Telia’s Play service.  This delivers tailored advertising based on an individual’s location, the channel they’re watching, the kind of screen and the type of device they’re using to stream content.

Later the same year, TV4’s adoption of SSAI allowed it to secure distribution deals with other major distributors including Com Hem.

TV4 is clearly a pioneer, with a data-driven, viewer-first approach to growing its business and monetising content for the long-term, an approach that has been enabled by SSAI.  In fact, TV4 has precisely pinpointed its adoption of SSAI for helping it achieve that aforementioned record 2018, with Mathias Berg, COO at TV4 Group commenting that, “as a result of a successful implementation of this strategy TV4 delivered its best financial result in terms of turnover and profitability in the history of the company.”

And with the broadcaster continuing to innovate, then long may this continue.

Subscribe to Yospace’s mailing list for monthly news and insights

Introduction to Prebidding for live streams

Posted on

By David Springall, Founder & CTO of Yospace.

In a previous post I discussed the concept of “prefetch” for live streams.  In this post I’m discussing “prebidding” which is an add-on to prefetch, so if you haven’t read the prefetch post yet I suggest you go through that first – you can find it here.

“Prebidding” is analogous to the concept of “h​eader bidding”, an approach to selecting advertising demand that has become very popular because of its ability to optimise advertising revenues on websites.  Header bidding allows advertisers to participate in an online auction for placement on the page while the page is being loaded.

In practical terms, individual advertisers do not participate in the auction, but instead bids are aggregated by systems called Supply-Side Platforms (SSPs) which in turn solicit bids from Demand-Side Platforms (DSPs).  It is with the DSP, that the advertiser (or their buying agent) establishes the commercial contract for payment on placement.

Until the concept of header bidding came along, a webpage would get advertisements from a first-party ad server (for example, DoubleClick for Publishers) which would be set-up to define a ‘pecking order’ of SSPs or DSPs that would be given the opportunity to place an ad.  If an SSP or DSP couldn’t place an ad, the next SSP/DSP in line would be given the opportunity.

There were a number of problems with this approach.  The first was that this cascade could simply take a long time to execute.  The second was that it didn’t reflect the fact that the best price could come back from any of the SSPs in the chain – only the first price above the publisher’s bid floor was used, not the best price.  And finally, the further down the pecking order an SSP/DSP would be the less insight into how many placement opportunities a given publisher was able to supply.

Having an accurate idea of how many placement opportunities a given publisher is making available is critical to optimising the bid responses.  Header bidding allows all SSPs or DSPs to be treated equally by calling to them simultaneously, rather than in a cascade, meaning the best price across all SSPs can be seen and everyone gets to see the placement opportunities and, importantly for the user experience, it’s faster.

Prebidding takes this concept of header bidding to video advertising inserted into a live broadcast stream.  In live streaming multiple ad breaks can be viewed by the same user during a single streaming session. This new logic exists inside the Yospace system that is responsible for delivering the stream to the user rather than the header of a web page, hence why the feature is named “prebidding” and not “header bidding”.

The system also solves another issue for the broadcaste, which is the separation of advertising by industry type.  If, for example, the first ad in an ad pod (ad break) is a first-party sold automotive ad, prebidding allows the ad server to ensure that no other automotive ad is included in that pod.  In addition, if an automotive ad comes back from the SSPs at a higher CPM than the first-party sold ad then the ad server could swap out the first-party sold ad, if the broadcaster configured it to do so.  Obviously, there are many nuances to where a broadcaster would want to prioritise higher-priced third party advertising over their own sold ads, but the technology would let them do this.

Until now a typical workflow for server-side ad insertion (SSAI) for live streams has looked like the first workflow here (1. Typical SSAI ad calls):

As you can see from the diagram, the ADS has not had visibility in advance of the SSP decisions.  It decides which ad in the pod are to be programmatic but without the foresight to know the CPM or content type of the programmatic ads that are to be stitched into the stream.

In the second diagram (2. Typical prebidding SSAI ad calls), prebidding allows the ADS to see the CPMs and ad types returned by SSPs in the ad call from the SSAI system (Yospace).  As a result the ADS is able to make a fully informed decision on which ads to place, resulting in realising the maximum value of the ad pod while ensuring an advertisers message is not diluted.

Subscribe to Yospace’s mailing list for monthly news and insights

Server-Side Ad Insertion for MPEG-DASH

Posted on

By Olivier Cortambert, Product Manager at Yospace.

There’s been a lot of talk in the industry about MPEG-DASH and we’re finding that a number of our customers are turning to this protocol, and of those a number are looking to it as a means of implementing multi-platform DRM.

Yospace was the first vendor to announce server-side ad insertion (SSAI) support for MPEG-DASH and are one of the only vendors today that can boast live services.

The ecosystem for supporting MPEG-DASH is still relatively immature in terms of players, encoders and packagers.  Behind this is the fact that the specification for MPEG-DASH doesn’t specify exactly how an MPD should be expressed to support SSAI, while the DASH-IF has only made a recommendation which is not universally followed.

Compared to HLS, which provides a simple list of segments in its manifest files, MPEG-DASH lists a much more complex set of information which includes the exact presentation time of each segment.  This complexity and precision makes replacing segments a much more involved task.

In a traditional linear television environment ad breaks are usually pretty precise, but in digital this is not always the case.  The SSAI system may receive four 30-second ads from the ad server to fill a two minute ad break but find they are not actually 30 seconds to frame, meaning there may be a slight under run over overrun at the end of the break.  HLS handles these discrepancies in a much simpler manner than MPEG-DASH through the use of a simple holding slate.

To avoid gaps between period in MPEG-DASH (which would lead to a break/buffer of the playback experience) it is necessary to adjust the timing of every period (content and ad breaks).  MPEG-DASH requires that all levels must be expressed on every manifest update, and the XML format of the MPD is quite wordy, so the CPU required to support a manifest update in MPEG-DASH is greater and more bandwidth is required.  HLS, by contrast, uses a more terse expression syntax and the player only grabs the levels it is actually playing, ultimately making server-side ad insertion more expensive for MPEG-DASH than it is for HLS.

It’s also harder to match audio and video when the programming is time-shifted in this way due to the fact that they are digitised in different ways: audio is usually divided in 44000 or 48000 samples per second whereas video is divided into 25 or 50 frames per second.

While MPEG-DASH throws up some complexities for applying SSAI, they are by no means insurmountable and Yospace has proved this over the last 12 months.  We were the first SSAI vendor to announce support for MPEG-DASH, in March 2018, and the first to implement it in a live customer environment later that year.  Today we have several customers using MPEG-DASH with SSAI.

There does remain more expertise in supporting SSAI for HLS though, and we are seeing broadcasters start to explore the alternative of using HLS with CMAF, the Common Media Access Format.  HLS with CMAF maintains the simplicity of HLS (especially for SSAI) while many of the advantages provided by MPEG-DASH. I would actively encourage broadcasters to consider harmonising to CMAF fragments as they are now supported on Apple devices, and use MPEG-DASH as and when it is required.

Where there are devices that can support both MPEG-DASH and HLS+CMAF, careful consideration should be given as to what format is most suited to their in-house expertise.

Subscribe to Yospace’s mailing list for monthly news and insights