The TAG TrustNet impression log-level data requirements (the “LLD Requirements”) define the requirements related to the products and services provided by suppliers (the “LLD Suppliers”) involved in the acquisition, delivery and verification of programmatic advertising impressions on behalf of advertisers, and/or their designated agency, with a license to use the Fiducia LLD Management Platform (the “Platform”) in the context of TAG TrustNet, and any other permitted uses, including designated advertiser solution partners or the participation of the advertiser to the industry benchmark developed jointly by TAG TrustNet and the ANA.

Specific requirements apply to specific categories of Suppliers. Please select the category corresponding to your category. Depending on the scope of your activity the requirements of multiple Supplier categories might apply.

Advertiser/Agency

Version: 1.2
Date Updated: March 18, 2024

1. General LLD Requirements

1.1 The Platform licensed advertiser (the “Licensee”), and/or their designate agency, needs to verify that Ad Servers (optional), Ad Verification Providers, DSPs and SSPs (optional) being used in their supply chain:

1. Have received the “Verified by TAG” status (https://www.tagtoday.net/verified-by-tag);
2. Support impression LLD, in compliance with the specifications set out in the respective LLD Requirements;
3. Have impression LLD access rights for the LLD Supplier in each category: Ad servers (optional), DSPs, SSPs (optional) and Ad Verification providers.

1.2 Licensee must configure all advertising tags for Ad Verification providers according to instructions provided by them, or by the Platform, to correctly populate DSP Impression ID Passthrough data fields in their LLD feeds. Failure to do so will result in limited visibility of advertising delivery data on the Platform.

2. LLD Accessibility Requirements

2.1 Licensee needs to ensure that

1. Access to the impression LLD of Ad Servers (optional), Ad Verification providers, DSPs and SSPs (optional) for all DSP seats IDs authorized by the advertiser is provided to the Platform on an ongoing basis.
2. Every LLD Supplier is providing comprehensive LLD documentation, including detailed descriptions of all data fields (typically with a data dictionary).
3. Impression events are reported in compliance with industry guidelines, e.g., IAB begin to render:

2.2 For impressions where SSP LLD is not accessible, metrics on SSP cost breakdown and supply path will not be available in the Supply Chain Monitor.

2.3 For LLD Suppliers providing data not fully compliant with LLD Requirements, the Platform may not be in a position to deliver expected supply chain insights to Licensee. This will be discussed with the Licensee to determine how to address the identified issues.

2.4 If an Amazon S3 storage bucket is used by the Licensee for the upload of LLD to the Platform, to avoid gaps in the LLD the Licensee needs to ensure that every data file is successfully uploaded, and retry to upload it when needed following S3 error best practices: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html.

3. Compliance with Data Protection Laws

3.1 Licensee needs to ensure that LLD provided for ingestion into the Platform 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. Licensee needs to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from LLD provided by LLD Suppliers before it is ingested into the Platform. Further, Licensee is required not to use any data generated by the Platform to generate, infer, or otherwise process Personal Data.

1. "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "non-public personal information," or other similar term under any applicable data privacy or protection laws.
2. "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

Version: 1.2
Date Updated: March 18, 2024

1. General LLD Requirements

1.1 Ad Servers (“LLD Supplier”) are requested to provide always-on access to LLD feeds to the Platform at no cost, in compliance with the specifications set out below, on behalf of advertisers, and/or their designated agency, which are:

1. Using the LLD Spplier’s products and services;
2. Licensed to use the Platform;
3. Providing a Letter of Authority designating Fiducia as a third party authorized to use the Supplier’s LLD in the context of TAG TrustNet and any other permitted use, including advertiser solution partners or the participation of the advertiser to the industry benchmark developed jointly by TAG TrustNet and the ANA.

2. LLD Accessibility Requirements

2.1 Access to the LLD feed is to be provided promptly to the Platform upon receiving a Letter of Authority from the advertiser or designated agency, depending on who owns the contract with the LLD Supplier.

2.2 LLD files must be provided with comprehensive documentation including detailed descriptions of all LLD fields (typically with a data dictionary).

2.3 Impression events are reported in compliance with industry guidelines, e.g., IAB begin to render:

3. LLD Ingestion Automation (Optional)

3.1 To simplify the activation of Supplier LLD on the Platform, the LLD Supplier may support the continuous upload of advertiser LLD into a designated Amazon S3 storage bucket either provided by the Platform or the Supplier, or via another agreed source.

3.2 LLD is to be protected from unauthorised access end-to-end using encryption in transit and at rest.

3.3 When the Amazon S3 storage bucket is used for the upload of LLD to the Platform, to avoid gaps in the LLD, the LLD Supplier needs to ensure that every data file is successfully uploaded, and retry to upload it when needed following S3 error best practices: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html

4. Compliance with Data Protection Laws

4.1 The LLD Supplier needs to ensure that LLD provided for ingestion into the Platform 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. Licensee needs to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from LLD provided by LLD Suppliers before it is ingested into the Platform. Further, Licensee is required not to use any data generated by the Platform to generate, infer, or otherwise process Personal Data.

1. "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "non-public personal information," or other similar term under any applicable data privacy or protection laws.
2. "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.

5. LLD Technical Requirements

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

	Log Files Data Required	Frequency
Ad-server	Served impressions, data dictionaries	New log file entries should must become available continuously to TAG TrustNet within 24 hours

5.1 The LLD Supplier should not change data record contents in internal systems in a way that they will become out of sync with LLD provided to an advertiser or agency. If a data restatement is required, then the advertiser or account owners and the Platform must be informed in a timely fashion so impression events can be reprocessed.

5.2 Impression LLD records and database records provided by the Platform to an advertiser or agency are deemed immutable for the purpose of ad delivery auditing.

5.3 Impression LLD records must be included in the log files no later than 48 hours after the impression event. Any impression LLD record delivered beyond this time limit will be ignored by the Platform for the purpose of ad delivery auditing.

5.4 Timestamps for impression events must be determined on the server-side using an authoritative time source.

5.5 Timestamps must always be reported in UTC time zone.

5.6 If impression records are reported via a database (e.g. BigQuery, Snowflake) they must contain both the impression timestamp and timestamp of the data record insertion into the log database.

5.7 As part of the LLD Supllier’s log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.

5.8 The LLD Supplier must make sure that ad server tags are installed in DSPs with passthrough of variables required to fill LLD fields described below, especially "DSP Impression ID Passthrough" for impression level matching when required.

6. Required and Recommended Data Fields

6.1 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 Advertiser 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.

Ad Verification

Version: 1.2
Date Updated: March 18, 2024

1. General Requirements

1.1 Ad Verification providers (“LLD Supplier”) are requested to provide always-on access to LLD feeds to the Platform at no cost, in compliance with the specifications set out below, on behalf of advertisers, and/or their designated agency, which are:

1. Using the LLD Supplier’s products and services;
2. Licensed to use the Platform;
3. Providing a Letter of Authority designating Fiducia as a third party authorized to use the Suppliers’s LLD in the context of TAG TrustNet and any other permitted use, including advertiser solution partners or the participation of the advertiser to the industry benchmark developed jointly by TAG TrustNet and the ANA.

2. Log Level Data Accessibility Requirements

2.1 Access to the LLD feed is to be provided promptly to the Platform upon receiving a Letter of Authority from the advertiser or designated agency, depending on who is the LLD Supplier’s contract owner.

2.2 LLD Suppliers should not prevent or delay the access to LLD feeds and support the request of advertisers and agencies to use the Platform for LLD reconciliation and supply chain monitoring.

2.3 LLD files must be provided to the Platform with comprehensive documentation including detailed descriptions of all LLD fields (typically with a data dictionary).

2.4 Impression events must be reported in compliance with industry guidelines, e.g., IAB begin to render:

3. Log Level Data Ingestion Automation (Optional)

3.2 LLD is to be protected from unauthorised access end-to-end by the Platform using encryption in transit and at rest.

4. Compliance with Data Protection Laws

1. "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "non-public personal information," or other similar term under any applicable data privacy or protection laws.
2. "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.

5. LLD Technical Requirements

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

	Log Files Data Required	Frequency
Ad-Verification Provider	Served impressions, data dictionaries	New log file entries should must become available continuously to TAG TrustNet within 24 hours

5.1 The LLD Supplier should not change data record contents in internal systems in a way that they will become out of sync with LLD provided by the Platform to an advertiser or agency. If a data restatement is required, then the seat owners and the Platform must be informed in a timely fashion so impression events can be reprocessed.

5.2 Impression LLD records and database records provided by the Platform to an advertiser or agency are deemed immutable for the purpose of ad delivery auditing.

5.4 Timestamps for impression events must be determined on the server-side using an authoritative time source.

5.5 Timestamps must always be reported in UTC time zone.

5.6 If impression records are reported via a database (e.g. BigQuery, Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.

5.7 As part of the LLD Supplier’s log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.

5.8 The LLD Supplier must make sure that verification tags are installed in DSPs and ad servers with passthrough of variables required to fill LLD fields described below, especially "DSP Impression ID Passthrough" for impression level matching.

6. Required and Recommended Data Fields

6.1 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	Content Verification Provider partner Account ID.
Account ID	Required	The campaign ID passed from the DSP as passthrough variable
Campaign ID	Required	The creative ID passed from the DSP as passthrough variable
Creative ID	Required	Publisher site URL or Site Domain as determined by verification provider.
Page URL or Site Domain	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.
DSP Impression ID Passthrough	Required	Whether the impression is measurable for viewability.
Measurable Impression	Required	Whether the impression was viewable and which viewability specification was applied (IAB, GroupM, display/video etc).
Viewable Impression	Required	Whether the impressions were classified as general or sophisticated invalid traffic.
Non GIVT/SIVT Impression	Required	Whether the impressions were blocked via blocking tag and the reason.
Blocked Impression	Required	Whether the impressions were monitored for GIVT/SIVT and brand safety.
Monitored Impression	Required	The impression's brand safety classification.
Brand Safety Impression	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
App Bundle or Publisher App ID	Required	The country where the ad was served as determined by the Ad Verification tool
Country	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.
Device Type	Required	Creative Type. May be display, video and other types.
Creative Type	Recommended	Quartile Completion for video impressions
Quartile Information	Recommended	OS type as determined by the Ad Verification tool. This may differ by data provider and require creation of mapping dictionary.
OS Type	Recommended	Browser type as determined by the Ad Verification tool. This may differ by data provider and require creation of mapping dictionary.
Browser Type	Recommended	State or Province
City, State or Province	Recommended	The insertion order number passed from the DSP as passthrough variable
Insertion Order Number	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
App Store URL	Recommended	Vendor-specific type of verification tag used for the event (pixel, JS, VAST pixel etc).
Verification Tag 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.
Event Type	Recommended	Partner's DSP seat ID populated as a passthrough variable
Seat ID	Required	The date and time of the impression event. Must be reported in sync with authoritative time source in UTC time zone.

DSP

Version: 1.2
Date Updated: March 18, 2024

1. General Requirements

1.1 Demand Side Platforms (“LLD Supplier”) are requested to provide always-on access to LLD feeds to the Platform at no cost, in compliance with the specifications set out below, on behalf of advertisers, and/or their designated agency, which are:

1. Using the LLD Supplier’s products and services;
2. Licensed to use the Platform;
3. Providing a Letter of Authority designating Fiducia as a third party authorized to use the Supplier’s LLD in the context of TAG TrustNet and any other permitted use, including advertiser solution partners or the participation of the advertiser to the industry benchmark developed jointly by TAG TrustNet and the ANA.

2. Log Level Data Accessibility Requirements

2.1 Access to the LLD feed is to be provided promptly to the Platform upon receiving a Letter of Authority from the advertiser or designated agency, depending on who owns the contract with the LLD Supplier.

2.2 The LLD Supplier should not prevent or delay the access to LLD feeds and support the request of advertisers and agencies to use the Platform for LLD reconciliation and supply chain monitoring.

2.3 LLD files must be provided to the Platform with comprehensive documentation including detailed descriptions of all LLD fields (typically with a data dictionary).

2.4 Impression events must be reported in compliance with industry guidelines, e.g., IAB begin to render:

3. Log Level Data Ingestion Automation (Optional)

3.1 To simplify the activation of Supplier LLD on the Platform, the LLD Supplier may support the continuous upload of advertiser LLD into a designated Amazon S3 storage bucket either provided by the Platform or the Supplier, or via another agreed source.

3.2 LLD is to be protected from unauthorised access end-to-end by the Platform using encryption in transit and at rest.

4. Compliance with Data Protection Laws

4.1 The LLD Supplier needs to ensure that LLD provided for ingestion into the Platform 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. Licensee needs to ensure all Personal Data, and any data fields which represent pseudonymous data, are removed from LLD provided by LLD Suppliers before it is ingested into the Platform. Further, Licensee is required not to use any data generated by the Platform to generate, infer, or otherwise process Personal Data.

1. "Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "non-public personal information," or other similar term under any applicable data privacy or protection laws.
2. "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.

5. LLD Technical Requirements

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

	Log Files Data Required	Frequency
DSP	Served impressions, data dictionaries	New log file entries should must become available continuously to TAG TrustNet within 24 hours

5.2 Impression LLD records and database records provided by the Platform to an advertiser or agency are deemed immutable for the purpose of ad delivery auditing.

5.4 Timestamps for impression events must be determined on the server-side using an authoritative time source.

5.5 Timestamps must always be reported in UTC time zone.

5.6 If impression records are reported via a database (e.g. BigQuery, Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.

5.7 As part of the LLD Supplier’s log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.

5.8 Reported seller IDs and buyer IDs need to match respective records in sellers.json and buyers.json files.

6. Required and Recommended Data Fields

6.1 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.
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.

SSP

Version: 1.2
Date Updated: March 18, 2024

1. General Requirements

1.1 Supply Side Platforms (“LLD Supplier”) are requested to provide always-on access to LLD feeds to the Platform at no cost, in compliance with the specifications set out below, on behalf of advertisers, and/or their designated agency, which are:

1. Using the LLD Supplier’s products and services;
2. Licensed to use the Platform;
3. Providing a Letter of Authority designating Fiducia as a third party authorized to use the Supplier’s LLD in the context of TAG TrustNet and any other permitted use, including advertiser solution partners or the participation of the advertiser to the industry benchmark developed jointly by TAG TrustNet and the ANA.

2. Log Level Data Accessibility Requirements

2.1 Access to the LLD feed is to be provided promptly to the Platform upon receiving a Letter of Authority from the advertiser or agency depending on who is the DSP seat owner.

2.2 The LLD Supplier should not prevent or delay the access to LLD feeds and support the request of advertisers and agencies to use the Platform for LLD reconciliation and supply chain monitoring.

2.3 LLD files must be provided to the Platform with comprehensive documentation including detailed descriptions of all LLD fields (typically with a data dictionary).

2.4 Impression events must be reported in compliance with industry guidelines, e.g., IAB begin to render:

3.2 LLD is to be protected from unauthorised access end-to-end by the Platform using encryption in transit and at rest.

1. Personal Data" means any information defined as "personal data," "personal information," "personally identifiable information," "non-public personal information," or other similar term under any applicable data privacy or protection laws.
2. "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.

5. LLD 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

5.1 The LLD Supplier should not change data record contents in internal systems in a way that they will become out of sync with LLD provided by the Platform to an advertiser or agency. If data a restatement is required, then the seat owners and the Platform must be informed in a timely fashion so impression events can be reprocessed.

5.2 Impression LLD records and database records provided by the Platform to an advertiser or agency are deemed immutable for the purpose of ad delivery auditing.

5.4 Timestamps for impression events must be determined on the server-side using an authoritative time source.

5.5 Timestamps must always be reported in UTC time zone.

5.6 If impression records are reported via a database (e.g., BigQuery, Snowflake), they must contain both the impression timestamp and timestamp of data record insertion into the log database.

5.7 As part of the LLD Supplier’s log file delivery, data dictionaries allowing the mapping of impression record data fields to their meaning must be provided at least every 24 hours.

5.8 Reported seller IDs and buyer IDs need to match respective records in sellers.json and buyers.json files.

5.9 The LLD Supplier should ensure that no impression records are filtered in log files due to technical or legal constraints and every delivered impression is reported. The LLD Supplier must ensure that their seller agreements allow this.

6. Required and Recommended Data Fields

6.1 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	DSP name or ID, which identifies DSP which requested the impression.
DSP ID	Required	DSP seat ID, For oRTB 2.x: bidresponse.seatbid.seat, oRTB 3.x: response.seatbid.seat.
Seat 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.
Seller ID	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.
Page URL and/or Site Domain	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.
App Bundle or Publisher App 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 Impression ID	Required	The oRTB ID of the bid request (oRTB 2.x: bidrequest.id, oRTB 3.0: request.id).
oRTB Bid Request ID	Required	The campaign ID received from DSP. For oRTB 2.x: bidresponse.seatbid.bid.cid. oRTB 3.x: response.seatbid.bid.cid or the SSPs own Campaign ID
Campaign ID	Required	The country where the ad was served. For oRTB 2.x: bidrequest.geo.country, oRTB 3.x: request.context.geo.country.
Country	Required	Winning bid in the auction in USD.
Winning Bid Price 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.
Gross Revenue in USD	Required	The currency of the invoice to the Buyer (DSP), unless in USD as standard.
Buyer Currency in USD	Required	The currency conversion rate between USD and invoice currency, if applied for the buyer, if not transacted in USD
Buyer Exchange Rate from 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. Sum of platform fees can be calculated as a difference between gross revenue in USD and media cost in USD.
Media Cost in USD	Required	The currency conversion rate between USD and seller currency, if applied for the seller, if not transacted in USD
Seller Exchange Rate from 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.
Platform Fees Breakdown in USD	Required	Any costs other than media and data that will be associated with the impression (excluding platform fees).
Other Costs in USD	Required	The deal ID when available. oRTB 2.x: bidresponse.seatbid.bid.dealid, oRTB 3.x: response.seatbid.bid.deal.
Deal ID	Required	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.
Seller Type	Recommended	OS type. This may differ by data provider and require creation of mapping dictionary. (oRTB 2.x: bidrequest.device.os).
OS Type	Recommended	Browser type. This may differ by data provider and require creation of mapping dictionary.
Browser Type	Recommended	State or Province
City, State or Province	Recommended	The type of the RTB auction, first or second price. oRTB 2.x: bidrequest.at, oRTB 3.x: request.at.
Auction Type	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).
Supply 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).
Demand Chain Object	Recommended	Validation that the Seller is a publisher or is listed in the publisher's ads.txt file.
ads.txt Validation	Recommended	The SSPs own impression ID
SSP Impression ID	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 Domain	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).
App Store URL	Recommended	Description of the exchange or integration type for an auction (e.g., exchange bidding, header bidding wrapper, etc.).
Integration Type	Recommended	The name of the agency / advertiser, which has legal agreement with SSP and owns DSP seat, if available.
Seat Owner / Partner Name	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 ID	Recommended	Advertiser domain. oRTB 2.5: bidresponse.seatbid.bid.adomain. oRTB 3.0: response.seatbid.bid.media.ad.adomain.
Advertiser Domain	Recommended	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.
Costs Disclosure	Recommended	The minimum price floor for the impression.
Floor Price	Recommended	Seller legal entity name.
Seller Name	Recommended	Domain, where Seller sellers.json file is located, when seller type is INTERMEDIARY or BOTH.
Seller Domain	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.
Event Type	Recommended	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 ID	Recommended	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	Recommended	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.
Device Type	Recommended	The date and time of the impression event. Must be reported in sync with authoritative time source in UTC time zone.
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.

Log-Level

Data Requirements

Advertiser/Agency

Ad Server

Ad Verification

DSP

SSP