Creative Specifications (Video)

Content Standardization Rules

• Sponsor of the advertising message must be clearly identified
• Landing pages must match the offer being made in the advertisement
• Product claims, warranties, guarantees or other assurances must comply with applicable laws and regulations
• Ad unit and landing page must have detailed disclosures as appropriate; in particular, full terms and conditions of the offer must be easily accessible on the landing page
• Quantcast reserves the right to request additional changes to submitted ads that do not comply with content standards. For any ads that are not in compliance with content standard and not revised, Quantcast reserves the right to reject the creative execution.
• Quantcast requires all clients to provide SSL compliant tags and assets.

3rd Party Tag Vendors:

The Quantcast Platform accepts third party VAST 2.0 tags from all major ad servers. These include, but are not limited to the following vendors: 

Common Errors

In addition to following the creative specifications above, a validation error may surface in the UI that prevents you from saving the creative if there is an issue with a particular creative. Here are the most common errors related to video creative and how to fix them. 

The Vast XML tag is fetched and the metadata (not the video itself) must satisfy the following:

• The XML tag must have a click through URL defined.
  
• The XML tag must have a duration defined that is greater than zero. This duplicates the below validation.
  
• The XML tag must declare whether the video is skippable or not.
  
• The XML tag must have video assets/media files declared with one or more mime types. This supplements validation in the below - the below checks that there are more than one media files, but each media file should have a mime type.

• Each URL must looks like a URL, in that it must have the standard RFC 3986 format:
  

   scheme:[//authority]path[?query][#fragment]

• Each URL’s scheme must be http or https.
• The authority/domain, path, query string and fragment must be valid.

The Vast URL must not be empty, and must be valid according to these conditions:

• Each URL must looks like a URL, in that it must have the standard RFC 3986 format:
  

   scheme:[//authority]path[?query][#fragment]

• Each URL's scheme must be http or https.
  
• The authority/domain, path, query string and fragment must be valid.

More detailed validation of the Vast XML (or Vast tag) itself is then performed and must not raise any other errors. The errors this process can produce are:

• The duration must either be given in an HH:MM:SS format, an HH:MM:SS.mmm format or it must be given in seconds. The error message is: "Duration format is invalid. Expected HH:MM:SS or HH:MM:SS.mmm, got {duration from vast tag}"
  
• The Vast version is an unsupported version - we only support Vast versions 2.0 and 2.0.1 in the XML. The error message is: "Expected VAST version: 2.0, got {version from vast tag}"
  
• The XML parser throws an exception while trying to parse the vast tag XML. This is only likely to occur if the vast URL provided does not point to an XML document at all. Given the message from our XML parser, the error message is: "Unable to process XML: {error from XML parser}"
  
• The XML document/Vast tag must have a root level <VAST /> element in the file. The error message is: "Tag <VAST> has not been found in the XML"
  
• The duration provided in the Vast tag must be non-zero. The error message is: "Duration should be longer than 0"
  
• The Vast tag must specify at least one media file. These media files are .mp4 video files, JavaScript files or whatever else. The error message is "No Media Files found in VAST file"