The Need to Get Everyone on the Same Page
As more video is consumed across the internet via streaming services, there is increased pressure to monetize viewers, especially as the services scale to include millions of users. One monetization model is advertisements delivered in the same manner as television broadcast—the Ad pod (before, during, and after the show). But unlike traditional TV, streaming services employ a different set of technologies to insert those ads within live and on-demand programming. These technologies, based on digital display advertising (like a banner ad on a website), were never designed to monitor video playback. And although organizations like IAB, with their VAST standard, have tried to catch up, there are so many ways that video ad measurement can go wrong across a multitude of systems all leading to one thing—the Ad fails to play. This can significantly impact tracking and measurement which undermines and compromises revenue. But not all is lost! Improvements in VAST 4.1 for capturing video ad data in a standardized way could serve as the foundation of a framework for an accepted method to measure video ads regardless of ad provider, platform, or implementation.
In this blog, we’ll summarize many of the current issues with capturing measurement data from video ad and suggest how the industry can move forward towards a standardized method of video ad analysis and reporting.
What’s Happening?
Ad breaks have long been part of the traditional TV watching experience. And as that TV experience has transitioned to streaming, broadcasters and video distributors have migrated their business models online as well (i.e., Advertising-sponsored content).
To support the transition of traditional broadcast to streaming, the video distribution workflow has changed, including the systems responsible for Ad insertion—how they are delivered, scheduled, prepared, and audited. Instead of building new systems, though, many video advertising platforms have harnessed the same technology and methods found in digital display advertising (i.e., Web-based banner ads, clicks, and impressions). By applying those same technologies to the video Ad environment, TV services and Ad buyers have gained access to new features and targeting abilities that didn’t exist within the traditional broadcast advertising environment. But those digital display technologies, when applied to video, also introduced fragmented methods which created challenges to operating an Ad-supported streaming video service. The fundamental problem, it seems, is the number of third-parties that exist between the Ad buyer and the user which provide different aspects of the delivery chain, such as tracking impressions. For example:
- An Ad buyer who buys Ad-space directly from a TV service,
- An Ad buyer who uses a third-party to buy the Ad-space,
- A TV service that also sells Ad-space on their online video platform, and
- A TV service that sells Ad-space on other online video platforms that are not their own.
By having multiple parties responsible for different aspects of the value chain across Ad delivery in an online video, troubleshooting in the event of a fault or other error becomes problematic.
The Need for a Standard Way to Report Ad Errors
In the current digital video Ad ecosystem, there are dozens of different platforms, servers, and services all operating independently from one another. For example, Freewheel, an Ad campaign manager, reports Ad serving errors differently than Google DoubleClick. This can be problematic for publishers who utilize multiple Ad distributors (for example, both Freewheel and DoubleClick) to get a clear picture of all errors across their entire network of Ads. But it’s also problematic for the Ad distributors—without a clear way to report on Ad-error rates to potential Ad buyers, advertisers could see a decrease in their inventory as well as adding risk to the fulfillment of specific campaigns or partnership commitments.
The way to solve this might be a standardized method for Ad-error reporting which can help all sides to manage their business more effectively. This blog post looks at how that standardized approach could happen.
Sample Use Case
While publishers have enough metrics to describe the pacing of an Ad-delivery commitment, they are severely limited in directly measuring the consumption because the data is in a partner’s system. Where consumption rate is low, it is difficult for all parties to understand why and to address the issues. This difficulty can lead to wasted effort troubleshooting on both sides, possible finger-pointing based on assumptions made, and can ultimately put the relationship in jeopardy.
The only evidence that might assist with resolving these problems would be a clear standardized error matrix. Imagine if all the systems used in the Ad value chain recorded the correct error descriptor and made it available to all the systems and data streams across all parties, from Ad mangers to client SDKs and Payloads transmitted between systems. Suddenly, there would be clear visibility on what the issue was and who is responsible to fix it…without having to do a deep investigation.
Current State of Ad Error Reporting
IAB VAST error reporting provides a standard for all Ad tech platforms to report an event for each error along with helpful metadata to understand what happened. Additionally, each Ad platform may have their own mechanisms for error reporting outside of the VAST standard. For example, when an Ad video source URL doesn’t return a video asset (a 404), the Ad buyer, Publisher, and distribution platform try to resolve the issue. But, the 404 could be the result of several possible problems which becomes harder to diagnose when the Ad manager or player simply responds with an “error.” Thankfully, in the VAST specification, we have a lot more detail for each error.
Consider the following scenario:
- An Ad is part of an Ad pod within a player;
- An advertising break is signaled, and the Ad pod begins to play;
- One of the Ads in the pod fails to load and, instead, the viewer is shown a black screen;
- The VAST SDK in the player captures a Mediafile issue and returns the appropriate error code.
The root cause, according to the VAST specification, can be one of the following:
- 401—problem with fetching the media file (i.e., the media file is not found)
- 403—VAST response declares unsupported mime-type on the device in question
What can the Ad manager do when they receive this error? They can report the issue to the Ad buyer who can review media formats and provide the correct format for that device type.
Gaps
Although the combination of VAST and Ad-platform error reporting can sometimes meet publisher needs, there are usually gaps resulting in incomplete reporting on an Ad error. Some of these gaps include:
- Publisher’s Ad-server has limited diagnostic reporting available which limits the usefulness of errors;
- In cases where errors originate from Ads on external networks, publishers do not have enough metadata to determine the Ad’s source and, hence, cannot escalate the issue to the appropriate Ad network;
- In cases where VAST Ad error responses come back blank, the publisher is unable to determine the Ad system responsible for the error because of limited or missing information;
- Error reporting capabilities may vary by platform and integration, where the error is reported but ignored elsewhere;
- The visibility of error reporting may be limited on external inventory (i.e. the Ad publisher lacks visibility on inventory coming from a distributor platform).
Mitigation and Resolution
So long as the gaps continue to exist, Ad publishers are compromising the success of their campaigns. Without detailed information regarding the root cause of individual Ad serving errors (so that the problems can be addressed), publishers usually must deliver additional impressions to meet campaign requirements. So instead of serving 100,000 impressions of a specific Ad, they might have to serve 110,000 where 10,000 of the total number of impressions are negated because of errors. Compounding this problem to hundreds of campaigns, it’s an issue that compromises system efficiency. Without understanding the underlying issues, a 10% reduction in system efficiency can have long-term implications to cost and revenue.
To solve this problem, we believe that a standard error-reporting framework should be adopted by all Ad-serving platforms thereby standardizing report errors across all platforms.
Error-Reporting Framework
One way to mitigate the impact of the gaps explained previously is to implement an error-reporting framework that can be adopted by all Ad-serving platforms. We suggest that the VAST 4.1 specification serve as the basis for this framework. Additionally, we suggest that:
- All ad-platform client application SDKs and reporting tools incorporate the VAST 4.1 spec;
- Attempt to add some verification tools and test suites for the various Ad SDKS so that errors are reported correctly per spec. So that an Ad implementation on a device works as expected;
- Include the VAST framework output into ad-platform dashboards and logging to provide publishers with enhanced error information.
Awareness
Addressing the issue will ultimately help publishers, Ad Buyers, and Ad-serving platforms with their day to day operations. Leaving them to focus on selling and delivering Ads, rather than trying to spend time working out what went wrong. Communication of the issue to the ecosystem is key, as it’s currently viewed as an operational burden which everyone has to endure.
A starting point might be to encourage the ecosystem to implement the VAST framework end-to-end across their platforms. Once the momentum has begun, we can then look to see how other tools can be harnessed to further mitigate the issue. But, for multiple systems and tooling to work together, we need a common language to help ascertain “what went wrong.”
Next Steps: Monitoring
Instead of being reactive to issues that occur, how can we use technology to be proactive in identifying faults in an Ad campaign before they start impacting a live service? Or better yet, what can we do to report on these issues in real-time, considering that most of the interactions between services occur at the point of requesting an Ad?
Monitoring opportunities to be explored may include:
- Introducing 3rd party monitoring probes that mimic a real user, can consume a video Ad campaign, and can record any errors;
- Identify the various playout chains and identify which are the key overlaps between systems that could be monitored for faults;
- Establish an end-to-end monitoring proof of concept solution that can interface with all the keys areas and provide a single view of where the fault may lie;
- Start collecting the data in one location that can act as the “single place of truth” such as:
- Schedule for Ad campaigns,
- Client-side analytics,
- Ad placement spots,
- Backend component monitoring;
- Begin monitoring DAI (Dynamic Ad insertion) better, where placements are monitored as well as the campaigns that should have been played.
Conclusion
By exploring and implementing the above, it’s believed that we can greatly enhance the operational efficiency of Ad platforms and protect the revenue streams behind them. By exposing the key data and information encapsulated in the many systems used in an Ad playout chain, it will be possible to better identify and mitigate faulty Ad behavior.
Next Steps
Inside the Advertising working group of the Streaming Video Alliance, we are trying to determine how we can demonstrate better monitoring of Ads across the ecosystem. Our objective is to show how different monitoring tools can exchange data and potentially offer a “total view” of an Ad play. Through this work, we hope to show how a campaign owner or publisher can work with a multitude of monitoring vendors to better understand how an Ad Campaign was delivered within the video chain.
The Streaming Video Technology Alliance Advertising Working Group has one primary objective: to define and develop best practices around the integration and operational processes for ad-supported streaming services in both on-demand and live video.