TAG TrustNet Member Requirements

Specific requirements apply to specific categories of Members. Please select the category that corresponds to your Member category. Depending on the scope of your activity the requirements of multiple Member categories might apply.

Advertiser/Agency Requirements
Version: 1.1

Date Updated: September 18, 2023

Required Agreements

  • TAG TrustNet Membership Agreement 
  • TAG TrustNet Licensing and Service Level Agreement 

General Requirements

  • Licensee must use their best efforts to make sure that Ad servers, Content Verification Providers and DSPs in use have received Verified by TAG (https://www.tagtoday.net/verified-by-tag) status.
  • Licensee must use their best efforts to make sure that Ad servers, Content Verification Providers and DSPs in use support log-level data product compliant with specifications set out in TAG TrustNet Requirements for respective vendor types:
  • (Optional) Licensee must use their best efforts to make sure that SSPs in use support log-level data product compliant with specifications set out in TAG TrustNet Requirements for SSP:
  • Licensee must configure all advertising tags for Ad servers and Content Verification Providers according to instructions provided by them or by TAG TrustNet to correctly populate DSP Impression ID Passthrough data fields in their log files. Failure to do so will result in limited visibility of advertising delivery data in TAG TrustNet Node Manager and Supply Chain Monitor.

Log Level Data Accessibility Requirements

  • Licensee must use your best efforts to make sure that access for Ad Servers, Content Verification Providers and DSPs log level impression data for all Licensee authorised DSP seats IDs is provided to TAG Trustnet or configured in Licensee's TAG TrustNet Node Manager within timings set out in the License Agreement.
  • (Optional) Licensee must use your best efforts to make sure that complete access for SSPs log level impression data for all Licensee authorised DSP seats IDs is provided to TAG TrustNet or configured in Licensee's TAG TrustNet Node Manager within timings set out in the License Agreement.
  • If Ad Server, Content Verification Provider, DSP or SSP provider has implemented Log Level Ingestion Automation as defined in TAG TrustNet Requirements for each respective vendor type, then Licensee can request activation of data access for Licensee's TAG TrustNet Node via a simplified process directly from vendors.
  • For every vendor, log level data files must be provided with comprehensive documentation including detailed descriptions of all data fields (typically with a data dictionary).
  • Impression events must be reported in compliance with industry guidelines, e.g., IAB begin to render:
  • For impressions where SSP log level impression data is not accessible, metrics on SSP/Exchange cost breakdown and supply path in the Supply Chain Monitor will be unavailable.
  • For vendors, who are not fully compliant with TAG TrustNet Requirements, TAG TrustNet may not work to its full capacity. TAG TrustNet will consult each Licensee on such cases.
  • If data upload to TAG TrustNet Node Amazon S3 storage bucket is used, to avoid gaps in the data ensure that every data file is successfully uploaded and retry upload if necessary following S3 error best practices:
  • https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html,
    •  

Compliance with Data Protection Laws

  • You must use your best efforts to ensure log level data provided for ingestion into TAG TrustNet does not include any Personal Data (as defined below) and falls outside of the scope of any data protection laws, including, without limitation, the GDPR and the CCPA. You must use your best efforts to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from the data set that you provide before it is ingested into the TAG TrustNet. Further, you must not use any data accessed or received by use of the TAG TrustNet to generate, infer, or otherwise Process Personal Data..
    • "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "nonpublic personal information," or other similar term under any applicable data privacy or protection laws.
    • "Process" means (a) any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means or (b) as such term (or similar term) is otherwise defined under applicable data privacy or protection laws.

Ad Server Requirements
Version: 1.1

Date Updated: September 18, 2023

Required Agreements

  • TAG TrustNet Membership Agreement 
  • TAG TrustNet Licensing and Service Level Agreement 

General Requirements

  • Ad server providers are required to receive Verified by TAG (https://www.tagtoday.net/verified-by-tag) status before applying for TAG TrustNet Membership.
  • Ad server providers are required to provide log-level data to their clients, compliant with specifications set out below, specifically the 'required' fields.

Log Level Data Accessibility Requirements

Log Level Data Ingestion Automation (Optional)

  • To simplify the activation of an ad servers log-level data in TAG TrustNet for clients, the Ad server provider may support the following mechanism:
    • Upon a client's request for a log-level data feed enablement for an owned client or account ID:
      • Start continuous upload of client or account ID log files into TAG TrustNet Node Amazon S3 storage bucket provided by TAG TrustNet; or,
      • Enable client or account ID log data in the data view shared with TAG TrustNet Snowflake account using Snowflake Data Exchange;
    • TAG TrustNet will configure a dedicated instance of TAG TrustNet Node for each Ad server, which will automatically share provided client or account log-level data with TAG TrustNet Nodes of the client;
    • Data will be protected from unauthorised access end-to-end using encryption in transit and at rest.

Compliance with Data Protection Laws

  • Log-level data provided for ingestion into TAG TrustNet shall not include any Personal Data (as defined below) and must fall outside of the scope of any data protection laws, including, without limitation, the GDPR and the CCPA. All Personal Data, and any data fields which represent pseudonymous data, must be removed from the data set that you provide before it is ingested into the TAG TrustNet. Further, you must not use any data accessed or received by use of the TAG TrustNet to generate, infer, or otherwise Process Personal Data.
    • "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "nonpublic personal information," or other similar term under any applicable data privacy or protection laws.
    • "Process" means (a) any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means or (b) as such term (or similar term) is otherwise defined under applicable data privacy or protection laws.

Log Level Data Technical Requirements

The tables below list the type of data files required, the frequency, and format.

  Log Files Data Required Frequency
Ad Server Impressions, Data Dictionaries New log file entries must become available continuously to TAG Trustnet within 24 hours

Technical Requirements

  • Ad server providers are required not to change data record contents in internal systems in a way that they will become out of sync with log-level data provided to a client. If data restatement is required, then the client or account owners and TAG TrustNet must be informed in a timely fashion so impression events can be reprocessed.
  • Impression log file records and database records provided to a client are deemed immutable in TAG TrustNet for the purpose of ad delivery audit.
  • Impression log file records must be included in the log files no later than 48 hours after the impression event. Any impression log file record delivered beyond this time limit will be ignored for the purpose of ad delivery audit in TAG TrustNet.
  • Timestamps for impression events must be determined on the server-side using an authoritative time source.
  • Timestamps must always be reported in UTC time zone.
  • If impression records are reported via database (e.g., Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.
  • As part of the Ad servers log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.
  • Ad server providers must make sure that ad server tags are installed in DSPs with passthrough of variables required to fill log-level data fields described below, especially "DSP Impression ID Passthrough".

Required and Recommended Data Fields

The following table details the 'required' and 'recommended' fields for impression events, with references to the OpenRTB specs where appropriate.

Field Status Description
Timestamp Required The date and time of the impression event. Has to be reported in sync with authoritative time source in UTC time zone.
Account or Advertsier ID Required Ad Server partner Account ID
AdServer Campaign ID Required The campaign ID.
AdServer Creative ID Required The creative ID.
AdServer Impression ID Required Ad server unique impression ID.
DSP Impression ID Passthrough Required Passthrough variable filled by a DSP for ad server tag with:. The oRTB ID of the impression request and/or bid request using macro oRTB 2.x: bidrequest.imp.id and bidrequest.id oRTB 3.x: bidrequest.item.id and bidrequest.id; Vendor-specific DSP unique impression ID, e.g. ${AUCTION_ID} for Google Display Video 360.
Page URL and/or Site Domain Required Publisher site URL or Site Domain as determined by the Ad server.
App Bundle or Publisher App ID Required The app bundle for the application, where the impression was served (oRTB 2.x: bidrequest.app.bundle, oRTB 3.0: request.context.app.bundle) or the Publisher App ID.
Device Type Required The oRTB type of the device if available (oRTB 2.x: bidrequest.device.devicetype, oRTB 3.x: request.context.device.type). See device type in oRTB 2.5 table 5.21 or List: Device Types in oRTB 3.x.
Creative Type Required Type of creative (display, video, or size etc).
Country Required The country where the ad was served. For oRTB 2.x: bidrequest.geo.country, oRTB 3.x: request.context.geo.country.
DSP Seat ID Recommended Partner's DSP seat ID. For oRTB 2.x: bidresponse.seatbid.seat. oRTB 3.x: response.seatbid.seat.
OS Type Recommended OS type. This may differ by data provider and require creation of mapping dictionary.
Browser Type Recommended Browser type. This may differ by data provider and require creation of mapping dictionary.
State or Province Recommended State or Province
DSP Campaign ID Recommended The campaign ID passed from the DSP.
Insertion Order Number Recommended The insertion order number passed from the DSP.
Creative ID Recommended The creative ID passed from the DSP.
App Store URL Recommended The app store URL (oRTB 2.x: bidrequest.app.storeurl, oRTB 3.0: request.context.app.storeurl).
Measurable Recommended Whether the impression is measurable for viewability.
inView Recommended Whether the impression was viewable and which viewability specification was applied (IAB, GroupM, display/video etc).
Event Type Recommended Detailed type of the reported event: impression begin to render, click, conversion, etc. This may be reported as different events for subsequent matching or may be flagged as fields in the single impression event. Event type is only required if it is unknown to TTN what type of single events will be communicated or if there will be multiple events recorded. ie more than just impression events.

Demand Side Platform Requirements
Version: 1.2

Date Updated: September 18, 2023

Required Agreements

  • TAG TrustNet Membership Agreement 
  • TAG TrustNet Licensing and Service Level Agreement 

General Requirements

  • DSPs are required to receive Verified by TAG (https://www.tagtoday.net/verified-by-tag) status before applying for TAG TrustNet Membership.
  • DSPs are required to provide log level data to their clients, compliant with specifications set out below, specifically the 'required' fields.

Log Level Data Accessibility Requirements

  • Log level data access must be provided to clients promptly upon request by the DSP seat owner.
  • DSPs shall not prevent or delay its clients from accessing log level data and support the goal of its ingestion into TAG TrustNet for analysis and/or sharing with third parties.
  • Log level data files must be provided with comprehensive documentation including detailed descriptions of all data fields (typically with a data dictionary).
  • Impression events must be reported in compliance with industry guidelines, e.g., IAB begin to render:

Log Level Data Ingestion Automation (Optional)

  • To simplify the activation of a DSPs log level data in TAG TrustNet for DSP clients, DSP may support the following mechanism:
    • Upon a client's request for a log level data feed enablement for an owned seat ID:
      • Start continuous upload of seat ID log files into TAG TrustNet Node Amazon S3 storage bucket provided by TAG TrustNet; or,
      • Enable seat ID log data in the data view shared with TAG TrustNet Snowflake account using Snowflake Data Exchange;
    • TAG TrustNet will configure a dedicated instance of TAG TrustNet Node for each DSP, which will automatically share provided DSP seat log level data with TAG TrustNet Nodes of DSP seat owners;
    • Data will be protected from unauthorised access end-to-end using encryption in transit and at rest.
  • If data upload to TAG TrustNet Node Amazon S3 storage bucket is used, to avoid gaps in the data ensure that every data file is successfully uploaded and retry upload if necessary following S3 error best practices:
  • https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html,
    •  

Compliance with Data Protection Laws

  • You must use your best efforts to ensure log level data provided for ingestion into TAG TrustNet does not include any Personal Data (as defined below) and falls outside of the scope of any data protection laws, including, without limitation, the GDPR and the CCPA. You must use your best efforts to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from the data set that you provide before it is ingested into the TAG TrustNet. Further, you must not use any data accessed or received by use of the TAG TrustNet to generate, infer, or otherwise Process Personal Data.
    • "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "nonpublic personal information," or other similar term under any applicable data privacy or protection laws.
    • "Process" means (a) any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means or (b) as such term (or similar term) is otherwise defined under applicable data privacy or protection laws.

Log Level Data Technical Requirements

The tables below list the type of data files required, the frequency, and format.

  Log Files Data Required Frequency
DSP Impressions, Data Dictionaries New log file entries must become available continuously to TAG TrustNet within 24 hours

Technical Requirements

  • DSPs are required not to change data record contents in internal systems in a way that they will become out of sync with log level data provided to a client. If data restatement is required, then the seat owners and TAG TrustNet must be informed in a timely fashion so impression events can be reprocessed.
  • Impression log file records and database records provided to a client are deemed immutable in TAG TrustNet for the purpose of ad delivery audit.
  • Impression log file records must be included in the log files no later than 48 hours after the impression event. Any impression log file record delivered beyond this time limit will be ignored for the purpose of ad delivery audit in TAG TrustNet.
  • Timestamps for impression events must be determined on the server-side using an authoritative time source.
  • Timestamps must always be reported in UTC time zone.
  • If impression records are reported via database (e.g., Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.
  • As part of DSPs log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.
  • Reported seller IDs and buyer IDs have to match respective records in sellers.json and buyers.json files.

Required and Recommended Data Fields

The following table details the 'required' and 'recommended' fields for impression events, with references to the OpenRTB specs where appropriate.

Field Status Description
Timestamp Required The date and time of the impression event. Must be reported in sync with authoritative time source in UTC time zone.
Seat ID Required DSP seat ID. For oRTB 2.x: bidresponse.seatbid.seat. oRTB 3.x: response.seatbid.seat.
Exchange ID Required The name or ID of the Exchange platform that the bid response was submitted to.
Advertiser ID Required The advertiser ID in the reporting system identifies the advertiser who has purchased the impression. Mapping of advertiser IDs and advertiser names should be provided by reporting platform.
Campaign ID Required The campaign ID in the reporting system. For oRTB 2.x: bidresponse.seatbid.bid.cid. oRTB 3.x: response.seatbid.bid.cid.
Creative ID Required The creative ID number in the reporting system. oRTB 2.x: bidresponse.seatbid.bid.crid. oRTB 3.x: response.seatbid.bid.media.ad.id. 
Creative Type Required The creative type in the reporting system. ORTB 2.x: bidresponse.seatbid.bid.attr, oRTB 3.x: response.seatbid.bid.media.ad.attr. See creative type in table 5.3 in OpenRTB 2.x or the List: Creative Attributes in oRTB 3.x.
Country Required The country where the ad was served. For oRTB 2.x: bidrequest.geo.country, oRTB 3.x: request.context.geo.country.
Device Type Required The oRTB type of the device if available. oRTB 2.x: bidrequest.device.devicetype, oRTB 3.x: request.context.device.type. See device type in oRTB 2.5 table 5.21 or List: Device Types in oRTB 3.x.
Deal ID Required The deal ID when available. oRTB 2.x: bidresponse.seatbid.bid.dealid, oRTB 3.x: response.seatbid.bid.deal.
Page URL and/or Domain Required Publisher site URL, where the impression was served (oRTB 2.x: bidrequest.site.page. , oRTB 3.x: request.context.site.page). The publisher site domain, where the impression was served (oRTB 2.x: bidrequest.site.domain, oRTB 3.0: request.context.site.domain).
App Bundle or Publisher App ID Required The app bundle for the application, where the impression was served (oRTB 2.x: bidrequest.app.bundle, oRTB 3.0: request.context.app.bundle) or the Publisher App ID.
SellerID Required From the IAB Tech Lab Sellers.json spec: This is the same ID that appears in an ads.txt file and in the SupplyChain.nodes array sid property.  In most cases will also appear in the Publisher.id property in an OpenRTB request.
DSP Impression ID Required The DSPs own internal impression ID. This is required if, the DSP does not support oRTB Bid Request or Bid Request Impression IDs or if it represents the the impression ID that a DSP would populate as macro in a 3rd part Ad Verification tag.
oRTB Bid Request Impression ID Required The oRTB ID of the impression. oRTB 2.x: bidrequest.imp.id; oRTB 3.x: bidrequest.item.id.
oRTB Bid Request ID Required The oRTB ID of the bid request (oRTB 2.x: bidrequest.id, oRTB 3.0: request.id).
Media Cost in USD Required The cost of the impression being charged to the DSP by the Exchange. Media cost shall be reported in USD and match billing figure invoiced by the Exchange.
Data Cost in USD Required The cost of any data associated with the impression.
Platform Fees in USD Required DSP platform fees.
Other Costs in USD Required Any costs other than media and data that will be associated with the impression (excluding platform fees).
Total Cost in USD Required The total of media, data, other costs invoiced to a seat owner by DSP. Reported in USD. After conversion into Partner Currency shall match billing figure invoiced by the DSP.
Total Cost with Partner Markup in USD Recommended The total of media, data, other costs, and partner mark up (if the partner markup is being tracked in the DSP platform).
Partner Currency Recommended The currency that is used by the seat owner that is using the DSP if not USD
Partner Currency Exchange Rate From USD Recommended The numeric rate of exchange in use at the time of the event to convert from USD to partner currency, if not USD
Advertiser Currency Recommended The currency that is used by the advertiser.
Advertiser Currency Exchange Rate From USD Recommended The numeric rate of exchange in use at the time of the event to convert from USD to the advertiser currency.
Viewability can be measured Recommended Whether the impression is measurable for viewability by the DSP.
Viewability Measurement Recommended The viewability measurement by the DSP.
Seat Owner / Partner Name Recommended The name of the agency / advertiser, who has legal agreement with DSP and owns DSP seat.
Exchange Domain Recommended Domain, where Exchange sellers.json file is located.
Advertiser Name Recommended The name of the advertiser in the reporting system.
Campaign Name Recommended The campaign Name in the reporting system.
Insertion Order Number Recommended The insertion order number in the reporting system.
OS Type Recommended OS type. This may differ by data provider and require creation of mapping dictionary.
Browser Type Recommended Browser type. This may differ by data provider and require creation of mapping dictionary.
City, State or Province Recommended State or Province.
Auction Type Recommended The type of the RTB auction, first or second price. oRTB 2.x: bidrequest.at oRTB 3.x: request.at.
Transaction Type Recommended Type of the transaction: OMP, PMP, PG
Supply Chain Object Recommended The entire supply chain object reported to the DSP. This should include all nodes in the nodes array. (oRTB 2.4: bidrequest.ext.schain.nodes, oRTB 2.5 bidrequest.source.ext.schain.nodes, oRTB 3.x: request.source.ext.schain.nodes).
ads.txt Validation Recommended Validation that the SSP is listed in the publisher's ads.txt file.
App Domain Recommended The app domain for the application, where the impression was served (oRTB 2.x: bidrequest.app.domain, oRTB 3.0: request.context.app.domain).
App Store URL Recommended The app store URL (oRTB 2.x: bidrequest.app.storeurl, oRTB 3.0: request.context.app.storeurl).
Advertiser Domain Recommended Advertiser domain. oRTB 2.5: bidresponse.seatbid.bid.adomain. oRTB 3.0: response.seatbid.bid.media.ad.adomain.
Event Type Recommended Detailed type of the reported event: auction win notice, impression requested, impression code served, impression begin to render, click, conversion, etc. This may be reported as different events for subsequent matching or may be flagged as fields in the single impression event. Event type is only required if it is unknown to TTN what type of single events will be communicated or if there will be multiple events recorded. ie more than just impression events.

Supply Side Platform Requirements
Version: 1.2

Date Updated: September 18, 2023

Required Agreements

  • TAG TrustNet Membership Agreement 
  • TAG TrustNet Licensing and Service Level Agreement 

General Requirements

  • SSPs are required to receive Verified by TAG (https://www.tagtoday.net/verified-by-tag) status before applying for TAG TrustNet Membership.
  • SSPs are required to provide log-level data to their clients, compliant with specifications set out below, specifically the 'required' fields.

Log Level Data Accessibility Requirements

Log Level Data Ingestion Automation (Optional)

  • To simplify the activation of a SSPs log level data in TAG TrustNet for SSP clients, the SSP may support the following mechanism:
    • Upon a client's request for a log level data feed enablement for an owned seat ID:
      • Start continuous upload of seat ID log files into TAG TrustNet Node Amazon S3 storage bucket provided by TAG TrustNet; or,
      • Enable seat ID log data in the data view shared with TAG TrustNet Snowflake account using Snowflake Data Exchange;
    • TAG TrustNet will configure a dedicated instance of TAG TrustNet Node for each SSP, which will automatically share provided SSP seat log-level data with TAG TrustNet Nodes of DSP seat owners;
    • Data will be protected from unauthorised access end-to-end using encryption in transit and at rest.
    • If data upload to TAG TrustNet Node Amazon S3 storage bucket is used, to avoid gaps in the data ensure that every data file is successfully uploaded and retry upload if necessary following S3 error best practices:
    • https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html,
      •  

Compliance with Data Protection Laws

  • You must use your best efforts to ensure log-level data provided for ingestion into TAG TrustNet does not include any Personal Data (as defined below) and falls outside of the scope of any data protection laws, including, without limitation, the GDPR and the CCPA. You must use your best efforts to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from the data set that you provide before it is ingested into the TAG TrustNet. Further, you must not use any data accessed or received by use of the TAG TrustNet to generate, infer, or otherwise Process Personal Data.
    • "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "nonpublic personal information," or other similar term under any applicable data privacy or protection laws.
    • "Process" means (a) any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means or (b) as such term (or similar term) is otherwise defined under applicable data privacy or protection laws.

Log Level Data Technical Requirements

The tables below list the type of data files required, the frequency, and format.

  Log Files Data Required Frequency
SSP Served Impressions, Data Dictionaries New log file entries should must become available continuously to TAG TrustNet within 24 hours

Technical Requirements

  • SSP are required not to change data record contents in internal systems in a way that they will become out of sync with log-level data provided to a client. If data restatement is required, then the seat owners and TAG TrustNet must be informed in a timely fashion so impression events can be reprocessed.
  • Impression log file records and database records provided to a client are deemed immutable in TAG TrustNet for the purpose of ad delivery audit.
  • Impression log file records must be included in the log files no later than 48 hours after the impression event. Any impression log file record delivered beyond this time limit will be ignored for the purpose of ad delivery audit in TAG TrustNet.
  • Timestamps for impression events must be determined on the server-side using an authoritative time source.
  • Timestamps must always be reported in UTC time zone.
  • If impression records are reported via database (e.g., Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.
  • As part of SSP log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.
  • Reported seller IDs and buyer IDs have to match respective records in sellers.json and buyers.json files.
  • SSP must ensure that no impression records are filtered in log files due to technical or legal constraints and every delivered impression is reported. SSP must ensure that seller agreements allow this.

Required and Recommended Data Fields

The following table details the 'required' and 'recommended' fields for impression events, with references to the OpenRTB specs where appropriate.

Field Status Description
Timestamp Required The date and time of the impression event. Must be reported in sync with authoritative time source in UTC time zone.
Costs Disclosure Conditionally Required Whether seller agreement / publisher opt-in allows SSP to populate cost data fields unless it is confirmed that a '0' or 'null' values in cost fields represents this then Cost Disclosure it not required.
DSP ID Required DSP name or ID, which identifies DSP which requested the impression.
Seat ID Required DSP seat ID, For oRTB 2.x: bidresponse.seatbid.seat, oRTB 3.x: response.seatbid.seat.
Seller ID Required The ID of the Seller (publisher, ad network, another Exchange/SSP), shall match with a seller_id in SSP’s sellers.json file. Maps to the specific entity that served the impression, publisher or intermediary entity.
Page URL and/or Site Domain Required Publisher site URL, where the impression was served (oRTB 2.x: bidrequest.site.page. , oRTB 3.x: request.context.site.page) and or Site Domain.
App Bundle or Publisher App ID Required The app bundle for the application, where the impression was served (oRTB 2.x: bidrequest.app.bundle, oRTB 3.0: request.context.app.bundle) or the Publisher App ID.
SSP Impression ID Required The SSPs own impression ID
oRTB Bid Request Impression ID Required The oRTB ID of the impression in BidRequest. oRTB 2.x: bidrequest.imp.id; oRTB 3.x: bidrequest.item.id.
oRTB Bid Request ID Required The oRTB ID of the bid request (oRTB 2.x: bidrequest.id, oRTB 3.0: request.id).
Campaign ID Required The campaign ID received from DSP. For oRTB 2.x: bidresponse.seatbid.bid.cid. oRTB 3.x: response.seatbid.bid.cid.
Creative ID Required The creative ID number in the reporting system. oRTB 2.x: bidresponse.seatbid.bid.crid, oRTB 3.x: response.seatbid.bid.media.ad.id. The creative type in the reporting system. oRTB 2.x: bidresponse.seatbid.bid.attr, oRTB 3.x: response.seatbid.bid.media.ad.attr. See creative type in table 5.3 in OpenRTB 2.x or the List: Creative Attributes in oRTB 3.x.
Creative Type Required The creative type in the reporting system. oRTB 2.x: bidresponse.seatbid.bid.attr, oRTB 3.x: response.seatbid.bid.media.ad.attr. See creative type in table 5.3 in OpenRTB 2.x or the List: Creative Attributes in oRTB 3.x.
Device Type Required The oRTB type of the device if available. oRTB 2.x: bidrequest.device.devicetype, oRTB 3.x: request.context.device.type. See device type in oRTB 2.5 table 5.21 or List: Device Types in oRTB 3.x.
Country Required The country where the ad was served. For oRTB 2.x: bidrequest.geo.country, oRTB 3.x: request.context.geo.country.
Winning Bid Price in USD Required Winning bid in the auction in USD.
Gross Revenue in USD Required Impression cost invoiced to the buyer for a winning bid in USD. This number reflects clearing price for first and second price auctions and will be matched against media cost number reported by buyer and buyer invoice.
Media Cost in USD Required The amount in USD the seller is paid by reporting platform for impressions, excluding platform's fee. This number will be matched against revenue number reported by seller.
Platform Fees Breakdown in USD Required Detailed breakdown of SSP platform fees. Sum of platform fees can be calculated as a difference between gross revenue in USD and media cost in USD.
Buyer Currency in USD Required The currency of the invoice to the Buyer (DSP), unless in USD as standard.
Buyer Exchange Rate from USD Required The currency conversion rate between USD and invoice currency, if applied for the buyer, if not transacted in USD
Seller Exchange Rate from USD Required The currency conversion rate between USD and seller currency, if applied for the seller, if not transacted in USD
Other Costs in USD Required Any costs other than media and data that will be associated with the impression (excluding platform fees).
Deal ID Required The deal ID when available. oRTB 2.x: bidresponse.seatbid.bid.dealid, oRTB 3.x: response.seatbid.bid.deal.
Seller Type Recommended PUBLISHER, INTERMEDIARY or BOTH in the meaning defined in sellers.json specification (https://iabtechlab.com/wp-content/uploads/2019/07/Sellers.json_Final.pdf), shall match with seller classification in SSP's sellers.json file.
OS Type Recommended OS type. This may differ by data provider and require creation of mapping dictionary. (oRTB 2.x: bidrequest.device.os).
Browser Type Recommended Browser type. This may differ by data provider and require creation of mapping dictionary.
City, State or Province Recommended State or Province
Auction Type Recommended The type of the RTB auction, first or second price. oRTB 2.x: bidrequest.at, oRTB 3.x: request.at.
Supply Chain Object Recommended The entire supply chain object reported to the DSP. This should include all nodes in the nodes array. (oRTB 2.4: bidrequest.ext.schain, oRTB 2.5 bidrequest.source.ext.schain, oRTB 3.x: request.source.ext.schain).
Demand Chain Object Recommended The entire demand chain object reported by the DSP in BidResponse. This should include all nodes in the nodes array. (oRTB 2.4: bidresponse.ext.dchain, oRTB 2.5 bidresponse.seatbid.bid.ext.dchain, oRTB 3.x: bidresponse.seatbid.bid.ext.dchain).
ads.txt Validation Recommended Validation that the Seller is a publisher or is listed in the publisher's ads.txt file.
App Domain Recommended The app domain for the application, where the impression was served (oRTB 2.x: bidrequest.app.domain, oRTB 3.0: request.context.app.domain).
App Store URL Recommended The app store URL for the application, where the impression was served (oRTB 2.x: bidrequest.app.storeurl, oRTB 3.0: request.context.app.storeurl).
Integration Type Recommended Description of the exchange or integration type for an auction (e.g., exchange bidding, header bidding wrapper, etc.).
Seat Owner / Partner Name Recommended The name of the agency / advertiser, which has legal agreement with SSP and owns DSP seat, if available.
Advertiser ID Recommended The advertiser ID in the reporting system identifies advertisers who has purchased the impression. Mapping of advertiser IDs and advertiser names should be provided by reporting platform.
Advertiser Domain Recommended Advertiser domain. oRTB 2.5: bidresponse.seatbid.bid.adomain. oRTB 3.0: response.seatbid.bid.media.ad.adomain.
Floor Price Recommended The minimum price floor for the impression.
Seller Name Recommended Seller legal entity name.
Seller Domain Recommended Domain, where Seller sellers.json file is located, when seller type is INTERMEDIARY or BOTH.
Event Type Recommended Detailed type of the reported event: bid response received, auction win notice, impression begin to render, click, etc. This may be reported as different events for subsequent matching or may be flagged as fields in the single impression event. Event type is only required if it is unknown to TTN what type of single events will be communicated or if there will be multiple events recorded. ie more than just impression events.

Content Verification Requirements
Version: 1.1

Date Updated: September 18, 2023

Required Agreements

  • TAG TrustNet Membership Agreement 
  • TAG TrustNet Licensing and Service Level Agreement 

General Requirements

  • Content Verification providers are required to receive Verified by TAG (https://www.tagtoday.net/verified-by-tag) status before applying for TAG TrustNet Membership.
  • Content Verification providers are required to provide log-level data to their clients, compliant with specifications set out below, specifically the 'required' fields.

Log Level Data Accessibility Requirements

Log Level Data Ingestion Automation (Optional)

  • To simplify the activation of a Content Verification providers log level data in TAG TrustNet for clients, provider should support the following mechanism:
    • Upon a client's request for a log level data feed enablement for an owned seat or account ID:
      • Start continuous upload of seat or account ID log files into TAG TrustNet Node Amazon S3 storage bucket provided by TAG TrustNet; or,
      • Enable seat ID or account ID log data in the data view shared with TAG TrustNet Snowflake account using Snowflake Data Exchange;
    • TAG TrustNet will configure a dedicated instance of TAG TrustNet Node for each Content Verification Provider, which will automatically share provided verification log-level data with TAG TrustNet Nodes of Seat Id or account ID owners;
    • Data will be protected from unauthorised access end-to-end using encryption in transit and at rest.
    • If data upload to TAG TrustNet Node Amazon S3 storage bucket is used, to avoid gaps in the data ensure that every data file is successfully uploaded and retry upload if necessary following S3 error best practices:
    • https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html,
      •  

Compliance with Data Protection Laws

  • You must use your best efforts to ensure log level data provided for ingestion into TAG TrustNet does not include any Personal Data (as defined below) and falls outside of the scope of any data protection laws, including, without limitation, the GDPR and the CCPA. You must use your best efforts to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from the data set that you provide before it is ingested into the TAG TrustNet. Further, you must not use any data accessed or received by use of the TAG TrustNet to generate, infer, or otherwise Process Personal Data.
    • "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "nonpublic personal information," or other similar term under any applicable data privacy or protection laws.
    • "Process" means (a) any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means or (b) as such term (or similar term) is otherwise defined under applicable data privacy or protection laws.

Log Level Data Technical Requirements

The tables below list the type of data files required, the frequency, and format.

  Log Files Data Required Frequency
Content Verification Provider Impressions, Data Dictionaries New log file entries must become available continuously to TAG TrustNet within 24 hours

Technical Requirements

  • Content Verification Provider are required not to change data record contents in internal systems in a way that they will become out of sync with log-level data provided to a client. If data restatement is required, then the account owners and TAG TrustNet should be informed in a timely fashion so impression events can be reprocessed.
  • Impression log file records and database records provided to a client are deemed immutable in TAG TrustNet for the purpose of ad delivery audit.
  • Impression log file records must be included in the log files no later than 48 hours after the impression event. Any impression log file record delivered beyond this time limit will be ignored for the purpose of ad delivery audit in TAG TrustNet.
  • Timestamps for impression events must be determined on the server-side using an authoritative time source.
  • Timestamps must always be reported in UTC time zone.
  • If impression records are reported via database (e.g., Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.
  • As part of a Content Verification Provider log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.
  • Content verification provider must make sure that verification tags are installed in DSPs and ad servers with passthrough of variables required to fill log-level data fields described below, especially "DSP Impression ID Passthrough".

Required and Recommended Data Fields

The following table details the required and recommended fields for impression events, with references to the OpenRTB specs where appropriate.

Field Status Description
Timestamp Required The date and time of the impression event. Must be reported in sync with authoritative time source in UTC time zone.
Account ID Required Content Verification Provider partner Account ID.
Campaign ID Required The campaign ID passed from the DSP as passthrough variable
Creative ID Required The creative ID passed from the DSP as passthrough variable
Page URL or Site Domain Required Publisher site URL or Site Domain as determined by verification provider.
DSP Impression ID Passthrough Required DSP impression ID populated as a passthrough variable filled by a DSP within a  verification provider tag with: The oRTB ID of the impression request and/or bid request using macro oRTB 2.x: bidrequest.imp.id and bidrequest.id oRTB 3.x: bidrequest.item.id and bidrequest.id; Vendor-specific DSP unique impression ID, e.g., ${AUCTION_ID} for Google Display Video 360.
Measurable Impression Required Whether the impression is measurable for viewability.
Viewable Impression Required Whether the impression was viewable and which viewability specification was applied (IAB, GroupM, display/video etc).
Non GIVT/SIVT Impression  Required Whether the impressions were classified as general or sophisticated invalid traffic.
Blocked Impression Required Whether the impressions were blocked via blocking tag and the reason.
Monitored Impression Required Whether the impressions were monitored for GIVT/SIVT and brand safety.
Brand Safety Impression Required The impression's brand safety classification.
Seat ID Required Partner's DSP seat ID populated as a passthrough variable
App Bundle or Publisher App ID Required The app bundle (oRTB 2.x: bidrequest.app.bundle, oRTB 3.0: request.context.app.bundle) or as determined by the Ad Verification tool
Country Required The country where the ad was served as determined by the Ad Verification tool
Device Type Required The oRTB type of the device or the device as determined by the Ad Verification tool. See device type in oRTB 2.5 table 5.21 or List: Device Types in oRTB 3.x.
Creative Type Required Creative Type. May be display, video and other types.
OS Type Recommended OS type as determined by the Ad Verification tool. This may differ by data provider and require creation of mapping dictionary.
Browser Type Recommended Browser type as determined by the Ad Verification tool. This may differ by data provider and require creation of mapping dictionary.
City, State or Province Recommended State or Province
Insertion Order Number Recommended The insertion order number passed from the DSP as passthrough variable
App Store URL Recommended The app store URL (oRTB 2.x: bidrequest.app.storeurl, oRTB 3.0: request.context.app.storeurl) or as determined by the Ad Verification tool
Verification Tag Type Recommended Vendor-specific type of verification tag used for the event (pixel, JS, VAST pixel etc).
Event Type Recommended Detailed type of the reported event: pre-bid check, ad blocking wrapper loaded, impression begin to render, click, conversion, etc. This may be reported as different events for subsequent matching or may be flagged as fields in the single impression event. Event type is only required if it is unknown to TTN what type of single events will be communicated or if there will be multiple events recorded. ie more than just impression events.

Publisher Requirements
Version: 1.1

Date Updated: September 18, 2023

Required Agreements

  • TAG TrustNet Membership Agreement 
  • TAG TrustNet Licensing and Service Level Agreement

General Requirements

  • Publishers are required to receive Verified by TAG (https://www.tagtoday.net/verified-by-tag) status before applying for TAG TrustNet Membership.
  • Publishers are required to provide required legal consents and opt-ins to all integrated Ad Server and SSP providers to share Publisher related ad impression data with advertisers including costs breakdown as defined in TAG TrustNet Requirements for these vendors.
  • Publishers are required to provide and regularly update comprehensive list of sites and applications owned by a publisher to TAG for inclusion into Verified by TAG database records.

Log Level Data Accessibility Requirements (Optional)

  • Publisher optionally may decide to make Google Ad Manager log files available for advertisers over TAG TrustNet to enable analysis of Google costs for them.
  • In such a case, publishers are required to have access to Google Ad Manager Data Transfer impression log files and their data fields defined in the section "Required Data Fields for Google Ad Manager Data Transfer" below.
  • Publishers must configure the TAG TrustNet Reconciliation SDK tag on their sites and applications in accordance with instructions provided by TAG TrustNet.
  • TAG TrustNet will configure an instance of TAG TrustNet Node for publishers using the provided Google Ad Manager Data Transfer access credentials, which will automatically share the publisher's Google Ad Manager Data Transfer impression log level data with TAG TrustNet Nodes of determined DSP seat owners using the Reconciliation SDK.
  • Data will be protected from unauthorized access end-to-end using encryption in transit and at rest.
  • If data upload to TAG TrustNet Node Amazon S3 storage bucket is used, to avoid gaps in the data ensure that every data file is successfully uploaded and retry upload if necessary following S3 error best practices:
  • https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html,
    •  

Compliance with Data Protection Laws

  • You must use your best efforts to ensure log level data provided for ingestion into TAG TrustNet does not include any Personal Data (as defined below) and falls outside of the scope of any data protection laws, including, without limitation, the GDPR and the CCPA. You must use your best efforts to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from the data set that you provide before it is ingested into the TAG TrustNet. Further, you must not use any data accessed or received by use of the TAG TrustNet to generate, infer, or otherwise Process Personal Data.
    • "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "nonpublic personal information," or other similar term under any applicable data privacy or protection laws.
    • "Process" means (a) any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means or (b) as such term (or similar term) is otherwise defined under applicable data privacy or protection laws.

Required Data Fields for Google Ad Manager Data Transfer


File Names
NetworkImpressions
NetworkBackfillImpressions
NetworkCodeServes
NetworkBackfillCodeServes
Required Fields Recommended Fields
Time
AdvertiserId
OrderId
LineItemId
CreativeId
CreativeVersion
CreativeSize
IsCompanion
IsInterstitial
AdUnitId
CustomTargeting
Country
RequestedAdUnitSizes
Product
KeyPart
TimeUsec2
ActiveViewEligibleImpression
EventTimeUsec2
EventKeyPart
RefererURL
EstimatedBackfillRevenue
YieldGroupCompanyId
MobileAppId
DealId
DealType
AdxAccountId
SellerReservePrice
Buyer
Advertiser
ImpressionId
CreativeSizeDelivered
OptimizationType		 Region
Browser
OS
Domain
City
Bandwidth
BrowserId
OSId
CountryId
RegionId
CityId
BandwidthId
MobileDevice
OSVersion
BandwidthGroupId
DeviceCategory
VideoPosition
PodPosition
VideoFallbackPosition
YieldGroupNames
RequestLanguage
NativeFormat
NativeStyle
File Names
NetworkBackfillBids
Required Fields Recommended Fields
AdUnitId
AdxAccountId
AuctionType
BidAdvertiser
BidBidder
BidBuyer
BidDealId
BidDealType
BidPrice
BidRejectionReason
BidSellerReservePrice
BidYieldGroupCompanyId
Country
CountryId
DeviceFamily
KeyPart
LineItemId
MobileAppId
OptimizationType
OrderId
OSFamily
Time
TimeUsec2		 YieldGroupNames
trustnet-logo-white
Copyright © 2024 Trusted Advertising Network, LLC. All Rights Reserved.