Standardizing ad requests in a non-bidding environment.

1. 1
Common Ad Transport Standard (CATS)
Standardizing ad requests in a non-bidding environment.

2. Why?
Is there a standard communication
protocol for non-bidded ad requests?
• NO.
Is there a common framework for
server to server ad requests?
• NO.
Can HTTP GET be used for all situations
such as VAST4 and URL macros?
• NO.
Do standards exists to facilitate
common transport standards?
• YES!
2

3. CATS?
3
‐ Simple
‐ Open
‐ Flexible
‐ Standard
‐ Future Proofing

4. What is CATS?
- Built off to AdCOM
- Aligns with OpenRTB
- Simple shim layer
- Video ad requests primary focus for v1.0.
- No response format defined in CATS v1.0
- VAST used for video requests
- AdCOM based response for future
- CATS and OpenRTB follow common
contextual layer
4

5. Rounding Up CATS Use Cases
- A publisher making an ad request to a publisher ad server
endpoint
- A publisher making an ad request for a creative resulting
from a programmatic auction
- An SSAI server making an ad request on behalf of a client
device
- A verification vendor proxying an ad request to insert
measurement
- A publisher ad server making an ad request
- A creative auditing system making an ad request to
validate the ad creatives against policies
- Any disparate system making an ad request to another
third party system
5

6. Who’s Going To Use This First?
- Video ad requests!
- Current State: VAST 4 Macros
- http://interactiveadvertisingbureau.gith
ub.io/vast/vast4macros/vast4-macros-
latest.html
- GET URLs are fickle. Size limits will be hit!
- GDPR / TCF consent strings (Huge)
- URLs for brand safety (Huge!)
- CATS v1.0 can use VAST as a response to
ease migration path
6

7. Next steps
- Public Comments This Month
- Now is the time to provide your feedback!
- Join the CATS sub-group
- Make your voice heard and steer the standard
- Video ad servers, think about supporting HTTP
POST in upcoming releases
- VAST 4.1 recommendation
- Future proofing for CATS
7