Ad Server Metadata Ingestion

Audience supports advanced advertising and viewership analysis based on static ad server metadata, such as advertiser name, ad sale type, and ad type.

Updated 2026-05-29 server, ingest, vi application, features

Audience supports advanced advertising and viewership analysis based on static ad server metadata, such as advertiser name, ad sale type, and ad type. To support advanced ad analysis, Audience ingests static customer ad server data through shared ad metadata files. The ingested ad server metadata appear in Audience as ad dimensions that can be used in session filters, viewer segments, Ads and Ad Details pages, and Analytics Workbench ad hoc visualizations and reports.

This process works only for ad metadata that is static across all ad impressions associated with an ad ID. It does not work for ad metadata that may change dynamically across ad impressions with the same ad ID. Sensor collected custom ad tags will allow for dynamic custom ad metadata. Sensor collected custom tags for ad sessions is not yet supported in VI/AM but is on the roadmap.

Ad server metadata ingestion process:

  • Conviva sensor collects ad IDs and creative IDs

  • Customer provides static ad metadata files to designated location, such as an Amazon S3 storage bucket.

  • Conviva Metadata Services ingests customer data

  • Audience matches ad data based on the ad and creative IDs and displays the ingested metadata as dimensions for use in filters, segments, and workbench reports

Plan for 2-3 weeks to initiate and complete setting up ad server metadata ingestion.

Typical Setup Process

Customer Conviva
Customer provides sample file(s) that adhere to the requirements (see Ad Server Data Requirements below). Conviva reviews sample file(s) and responds with questions and feedback.

Customer addresses feedback and provides new sample file(s) as needed.

Conviva validates sample file(s) and reports match rate (% of ad server ad IDs that match to Conviva sensor collected ad IDs) – this match rate should be close to 100% (if not close to 100%, further troubleshooting is required.)

Customer sets up a storage location (e.g. s3 bucket) for exchange of files and shares credentials with Conviva.

This storage location can be the same location used for the Conviva Connect feed.)

Customer provides a one-time historical file(s) with ad metadata for ad IDs dating back to the desired start date to present date (minus 1 or 2 days as feasible).

Customer sets up daily export of ad metadata (i.e. for the previous day or day before).

Conviva starts ingesting files and validates ingestion process.

Prerequisites

Conviva sensor collects ad ID and creative ID (as part of Ads integration) on all device platforms for the O&O properties in scope.

Ad Server Data Matching

For each ad session, the Conviva sensor collects the ad IDs and Creative IDs in the Conviva data objects. The Ad ID, Creative ID and Creative Name must be passed to the Conviva sensor. (For more details about Conviva integrations, see Integration Overview.)

After customers share their ad server data, the Conviva Metadata Service (MDS) ingests the customer-provided static metadata and matches the data associated with the collected IDs for use in Audience.

Currently, the values for the ad dimensions are limited to string values. Other data types may be supported if required.

This ad server metadata ingestion process works only for ad metadata that is static across all ad impressions associated with an ad ID. It does not work for ad metadata that may change dynamically across ad impressions with the same ad ID, such as advertiser name, sale type, and ad type.

Ad Server Metadata File Requirements

Customers can provide ad metadata from multiple ad servers in a single file or separate files in CSV or Parquet format. Additional file requirements are:

  • Ensure the ad server metadata file includes the necessary columns as presented in the table. Note that the names provided are generic, and the actual column names in the ad server may differ.
Column Name Description Notes
Ad ID ID corresponds to a unique combination of Advertiser, Campaign, and Placement/Line Item.
This is used as the match key with sensor collected Ad ID.
In FW (FreeWheel), Ad ID is required. In GAM (Google Apps Manager), Ad ID may not be required as Line Item ID mentioned below is used to match with the sensor collected Ad ID.
Advertiser ID ID of the Advertiser associated with the ad.
Advertiser Name Name of the Advertiser associated with the ad.
Campaign ID ID of the Campaign associated with the ad. In GAM, this is referred to as Order ID.
Campaign Name Name of the Campaign associated with the ad. In GAM, this is referred to as Order Name.
Placement/Line Item ID In FW, this is referred to as Placement ID. In GAM, this is referred to as Line Item ID.
Placement/Line Item Name In FW, this is referred to as Placement Name. In GAM, this is referred to as Line Item Name.
Creative ID ID of the Creative associated with the ad, determined by a combination of Advertiser, Campaign, and Placement/Line Item. Creatives can rotate for each ad.
This is used as the match key with sensor collected Ad ID.
Creative Name Name of the Creative associated with the ad. Creatives can rotate for each ad.
  • Optionally provide additional columns representing additional valuable metadata as desired. Examples include but are not limited to: Brand Name, Creative Duration, Ad Type (paid ad, promo, etc.), Sale Type (Direct Sold, Programmatic, etc.), Ad Format/Product, etc. These additional columns will be appeared as ad dimensions in Audience.

  • Each row must represent a unique Ad ID (FW) or Line Item ID (GAM), which delivered at least one impression. If possible, also include Ad IDs that are planned to start delivering in the near future (e.g. 1 or 2 days in the future).

  • The ad server metada file must contain all Ad IDs delivered to the digital O&O properties in scope.

See this sample CSV file.

Conviva supports the pull method for file ingestion:

  • Publisher uploads the files to their S3/GCS buckets and Conviva pulls the data from there.

  • Publisher needs to provide Conviva the file path and credential.

Conviva prefers customers send their file(s) daily to an S3/GCS bucket.