How are the industry’s governing bodies — namely the Media Rating Council (“MRC”) and the Interactive Advertising Bureau (“IAB”) — approaching server-side ad insertion (“SSAI”) measurement?
Per Pixalate, SSAI is used in 38% of programmatic OTT/CTV transactions. However, it’s prone to fraud: When SSAI is used in programmatic OTT/CTV, it’s invalid 26% of the time, as measured by Pixalate.
The IAB and MRC have collaborated with partners across the industry to establish best practices as they relate to SSAI. This blog, the latest in our SSAI series, explains the latest guidelines.
Want more SSAI content? Follow along with our series:
- What is SSAI, and how is it abused by ad fraudsters?
- Current solutions for SSAI
- Pixalate's approach to SSAI: How Pixalate approaches invalid SSAI measurement
- Industry standards for SSAI: How industry governing bodies are approaching SSAI
- Looking ahead (coming July 2019)
- The buyer's perspective on SSAI: What agencies, DSPs, and brands need to know about SSAI
- SSAI myths: Demystifying SSAI by reviewing what true and what's not
What the IAB’s VAST 4.0 spec says about SSAI
The IAB’s VAST 4.0 specification — released in January 2016 — offered the industry its first guidelines for dealing with SSAI, or ad stitching.
The guidelines note: "When an ad-stitching service is involved, the ad-stitching server may send tracking on the player’s behalf. This server-to-server tracking process is problematic because all the tracking is coming from one IP address. To an ad server that is receiving tracking information, the reports look similar to faked traffic fraud.”
The 4.0 guidelines note that SSAI providers can avoid being mistaken for fraud by including two headers as part of the ad request: X-Forwarded-For (a header that identifier the client IP address) and X-Device-User-Agent (a head that identifies the client’s device user agent string).
The VAST 4.0 guidelines note that the Forwarded HTTP Extension may also be used — which allows all proxy information to be disclosed in one field — but notes that most systems look for X-Forwarded-For and X-Device-User-Agent.
VAST 4.1 adds more guidelines for SSAI
The IAB’s VAST 4.1 (November 2018) specification added additional guidelines for how to best deal with SSAI, this time with more conviction and hierarchy. The guidelines say what must be included, what should be included, and what can be included.
- What “must” be included when SSAI is used:
VAST 4.1 guidelines say ad stitching providers must include the following HTTP headers to avoid being mistaken as ad fraud:
- X-Device-IP: To share the IP address of the device on whose behalf the proxy is making a request
- X-Device-User-Agent: To share the User-Agent of the client on whose behalf the proxy is making a request
- What “should” be included when SSAI is used:
VAST 4.1 guidelines say ad stitching providers should include the following HTTP headers:
- X-Device-Referer: To share the Referer header value that the client would have used in a non-proxied request
- X-Device-Accept-Language: To share the Accept-Language header value that the client would have used in a non-proxied request
- What “can” be included when SSAI is used:
VAST 4.1 guidelines say ad stitching providers may also include the following HTTP headers:
- X-Forwarded-For: For backward compatibility (See VAST 4.0 standards); XFF is now deprecated
- X-Device-*: To pass along other HTTP headers that the client would have sent itself in a non-proxied request
Importantly, the VAST 4.1 guidelines note: “The information included in these headers must match the information in the original ad request payload."
Update to MRC and IAB ‘Digital Video Ad Impression Measurement Guidelines’ addresses SSAI
Published in June 2018, the IAB/MRC’s updated Digital Video Ad Impression Measurement Guidelines (MMTF Final Draft v1) defined specific measurement criteria for Server-Side Ad Stitching and Server-to-Server measurement.
The document notes: “This server-to-server tracking process may ... be problematic because all the tracking is coming from one IP address and therefore may be susceptible to IVT filtration techniques.”
The guidelines note that a client-initiated counting methodology is still required across these integrations in a manner consistent with previous IAB/MRC guidance. The IAB’s VAST (video ad serving template) framework complements this guidance in that VAST 4.0 and VAST 4.1 have established specific protocols for self-declaring SSAI integrations.
The IAB Tech Lab’s ‘Guidelines for Identifier for Advertising (IFA) on OTT platforms’
In 2018, the IAB Tech Lab released its “Guidelines for Identifier for Advertising on OTT Platforms,” which are “recommendations on how to maintain a high-quality advertising experience within over-the-top television (OTT) environments.”
These guidelines aim to align the OTT advertising industry with best practices from the mobile ecosystem.
“Due to the wide variety of different Smart TV, Connected Device and other over the top television (OTT) platforms, it cannot be guaranteed that devices support the traditional cookie-based semi-persistent device or audience management for ad-related activities,” wrote the IAB Tech Lab. “In order to maintain a high-quality audience experience within OTT environments, it is recommended that parties manage advertising-related activities through an identifier for advertising (IFA), while respecting the user’s privacy settings.”
The IAB Tech Lab recommends passing three data fields through each step of the video delivery chain:
- IFA - in UUID (Universally Unique Identifier) format
- IFA Type (ifa_type)
- Limit Ad Tracking (lmt)
The IFA aims to serve as a Universal Unique Identifier (UUID) of a specific OTT device, such as Smart TVs, gaming consoles, streaming devices, etc. If that UUID is passed through each part of the chain, then the buyer would be better able to validate that the ad was served to a real OTT device.
While the guidelines for Identifier for Advertising do not directly address invalid SSAI, it does call for more transparency throughout the OTT video supply chain, which will help in the overall battle against ad fraud.
The Media Rating Council (MRC) has begun accrediting third-party verification companies in OTT/CTV
The MRC has begun accrediting companies for services in OTT/CTV environments, including for video served ad impressions and sophisticated invalid traffic (SIVT) detection and filtration.
As OTT/CTV becomes a bigger part of advertisers’ plans, the MRC’s guidance helps buyers, sellers, and everyone in between know who they can trust to help with measurement, verification, and ad fraud detection.
The list of companies accredited by the MRC has become the ad industry’s de facto standard of trustworthy third-party measurement companies.
The battle against ad fraud is ongoing
Scammers are highly incentivized to profit from rising OTT/CTV ad budgets, and it’s important to remember that the fraudsters are equally capable of evolving.
The industry’s growing standards around SSAI — coupled with other standards aimed at improving transparency and quality in OTT/CTV, (such as app-ads.txt) — are all steps in the right direction, and Pixalate strongly encourages their widespread adoption.
However, as programmatic OTT/CTV ad budgets rise, instances of invalid traffic and ad fraud will continue to crop up, and companies that are serious about protecting their OTT/CTV investments are encouraged to utilize advanced IVT solutions for ongoing measurement and detection.
SSAI webinar: Learn from industry experts
Pixalate, the first and currently only company accredited by the MRC for sophisticated invalid traffic (SIVT) detection and filtration in OTT/CTV, has gathered industry experts for a webinar on the use of Server-Side Ad Insertion (SSAI) in OTT/CTV advertising.
On Thursday, July 11, 2019 at 1:00pm ET, Pixalate Product Manager Chris Schwarz will host:
- Amit Shetty, Sr. Director of Video & Audio Products, IAB Tech Lab
- Ian Trider, Director of RTB Platform Operations, Centro
- Jeremy Smith, VP of Sales Engineering, Telaria
Although grounded in Pixalate’s proprietary technology and analytics (which Pixalate evaluates and updates continuously), invalid traffic (IVT) designations in this blog post represent Pixalate’s opinions (i.e., they are neither facts nor guarantees). Per the MRC, the term “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes;” and also per the MRC, “'Invalid Traffic' is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.”