In an endless sea of content, nothing quite matches the grandeur, spectacle, and humanity of live events. No other advertising experience can replicate the impact of delivering your brand’s message alongside nail-biting moments or even captivating points in history.

It’s no wonder that publishers, SSPs, and DSPs are all clamoring for the opportunity to activate programmatic advertising on live events.

I’ve had the opportunity to sit at the bleeding edge of programmatic live-event activation, and it gives me a clear view of what’s working well and the opportunities for the ecosystem to improve. One area ripe for improvement is creating a standard way for publishers to share live event information with their ad technology partners before an event occurs.

Programmatic advertising is built upon standardization. A set of predefined protocols that tell each participant exactly how to act and what to expect when requesting ads, providing bid responses, playing back creatives, and so on.

Until recently, there was no standard for communicating live event information before an event occurred — until the Forecasting API.

What is the Forecasting API?

The Forecasting API was born out of the LEAP initiative from the IAB Tech Lab and offers a standard specification for publishers to share live event schedules, expected peak streams, and other event metadata with their ad platform partners.

The Forecasting API is one of multiple current and planned LEAP projects aimed at standardizing live event digital advertising. But what problem does it solve?

Why do we need the Forecasting API?

Live events introduce scaling, pacing, and optimization challenges for publishers, ad servers, SSPs, and DSPs that they do not face in VOD environments.

These problems lead to poor ad experiences for users or a failure to meet campaign goals for advertisers and publishers.

If the ad platforms involved in a live event only loosely understand what volume of viewers to expect, then they cannot properly prepare for the avalanche of traffic that can melt servers and throw bidding optimizations out of whack.

Publishers can email or share spreadsheets of event schedules and expected concurrency or QPS (queries/bid requests per second) with their partners, but this is time-consuming, inconsistent across publishers, and requires manual intervention.

The forecasting API aims to standardize this process and enable publishers to share schedules, event information, and expected concurrency with all their partners in a scalable way.

Preparing for live events

Understanding expected concurrency helps both the supply and demand sides ensure readiness. Not properly preparing for live events can cause many issues. Massive numbers of users streaming the same event concurrently can lead to:

• Dropped requests

• Increased timeouts and ad errors

• Inconsistent delivery and pacing

These issues can lead to dreaded slate during broadcasts (“We’ll be right back!”), which means lost opportunity for publishers.

Enabling new DSP features

DSPs also want up-to-date scheduling information so they can build features to better support their clients' ambitions for live event buying. These features include new live event targeting experiences and more intelligent pacing.

If DSPs have an automated, accurate method for fetching scheduling information, they can craft a more elegant in-platform buying experience by piping that schedule information into the platform.

Instead of a scattered deal-by-deal setup across publishers, DSPs could instead create solutions to buy across an entire league. A DSP could, in theory, allow an advertiser to simply target “NFL” or “NBA” and then orchestrate targeting across multiple publisher deals in the background.

Additionally, by parsing scheduling information, expected viewership, and ad load, the DSP could more intelligently pace campaigns. Pacing presents a unique challenge when monetizing live events today, given unpredictable inventory availability and spiky bursts of traffic.

DSPs can better tune pacing algorithms not only to handle concurrency when it's known in advance, but also to spread out their clients' budgets throughout a season or even during special events like tournaments and playoffs.

How does the Forecasting API work?

Let’s dive into the specification and take a look at how this thing is supposed to work.

Someone is expected to host an endpoint that, when called, returns schedule and event information. Just like an SSP calls a DSP ORTB endpoint for a bid, a DSP can call a Forecasting API endpoint to obtain schedule and event information.

Who owns this endpoint and populates the scheduling information? It is somewhat flexible according to the spec.

Streamers could host it themselves or enlist their SSP to build it out. In any case, there needs to be a system in place for a publisher to populate schedule information along with event metadata, and host a service to return a response to authorized consumers of that information (most likely DSPs).

Here is an example response:

{
  "version": "1.0.0",
  "timestamp": 1751205600000,
  "upcomingevent": [
    {
      "id": "content_management_system_id_game1",
      "scheduledstart": 1751044800000,
      "scheduledend": 1751059200000,
      "flexibleend": 1,
      "eventstatus": 1,
      "content": {
        "id": "content_management_system_id_game1",
        "title": "TeamA vs TeamB - Series Name - Game 1",
        "series": "Series Name 2026",
        "season": "2026",
        "gtax": "9",
        "genres": "483",
        "language": "en",
        "producer": {
          "name": "Content Name"
        },
        "network": {
          "name": "Network Name"
        },
        "len": 10800
      },
      "streamsdata": [
        {
          "country": "USA",
          "expectedpeak": 2000000
        }
      ],
      "adinventoryconfig": {
        "supportedmtype": [
          2
        ],
        "totaladdurationsec": 1400,
        "expectedpodcount": 12,
        "unplanned": 1
      },
      "lastmodifieddate": 1750958400000
    }
  ]
}

Key fields worth noting

You’ll notice the response provides:

• Scheduled start and end times (scheduledstart + scheduledend in UNIX timestamp)

• Event title (title)

• Genre (genres 483 = American Football)

• Broadcasting network (network)

• Duration (len)

The event “ID” field is also important, as it ties the event in the forecasting API to a content ID in a bid request. This would give DSPs the capability to set up targeting in advance using scheduling information and target the specific event ID they see in the content.id field in a bid request.

However, the willingness of publishers to share content ID is up for debate. Also, if they did, it would almost certainly have to be a hashed identifier so it doesn’t reflect the internal value present in a publisher’s content management system.

StreamsData

"streamsdata": [
  {
    "country": "USA",
    "expectedpeak": 2000000
  }
]

The StreamsData object provides the crucial figure of peak estimated concurrent streams during the event. This is the magic number that allows ad systems to prepare for the high concurrency of a given event.

It’s worth noting that there is a separate Concurrent Streams API that could be used to validate this number in real-time.

AdInventoryConfig

"adinventoryconfig": {
  "supportedmtype": [2],
  "totaladdurationsec": 1400,
  "expectedpodcount": 12,
  "unplanned": 1
}

The AdInventoryConfig object provides insight into the ad opportunities available in a broadcast.

In this example:

• supportedmtype = 2 indicates video

• Total ad duration is 1,400 seconds (~23 minutes)

• 12 ad pods are expected (expectedpodcount)

• Additional unplanned pods may occur like injuries or stoppages (unplanned=1)

This information can help inform pacing decisions based on available supply.

This AdInventoryConfig can help inform pacing based on availability. DSPs could use this information to help spread out delivery across individual events or even entire seasons.

It could also help inform bidding behavior by providing a sense of inventory scarcity if they know exactly how much opportunity is available during an event. However, I will note that it will not be a straightforward exercise for DSPs to use this info for bidding and pacing, as DSPs won’t know how often direct IOs and competing DSPs fill these pods.

So the AdInventoryConfig and StreamsData objects alone won’t provide all the necessary information to optimize bidding and pacing. DSPs will need to synthesize Forecasting API information with past auction bidding and delivery data to unlock the new insights it could provide.

It’s now up to publishers and ad platforms to decide if the Forecasting API provides enough value to warrant adoption and integration into existing workflows and systems.

The API offers an automated, scalable path to replace a dreadfully manual current reality and could also provide additional insight into inventory availability, unlocking more advanced DSP targeting, planning, and bidding features.

If you want to read the full proposal or ask any questions, the Forecasting API is now open for public comment.

EVENTS

Marketecture Live III

7 Days Until Marketecture Live

The agenda is set, tickets are moving fast, and The Glasshouse is filling up.