LLD
requirements
TAG TrustNet LLD Requirements
​
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.
LLD Requirements by LLD Supplier categories:
Advertiser/Agency Requirements
Demand Side Platform Requirements
Supply Side Platform Requirements
​
You can also download the requirements HERE
Advertiser/Agency LLD Requirements
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:
a. Have received the “Verified by TAG” status (https://www.tagtoday.net/verified-by-tag);
b. Support impression LLD, in compliance with the specifications set out in the respective LLD Requirements;
c. 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:
a. 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.
b. Every LLD Supplier is providing comprehensive LLD documentation, including detailed descriptions of all data fields (typically with a data dictionary).
c. 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.
a. "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.
b. "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 LLD Requirements
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:
a. Using the LLD Spplier’s products and services;
b. Licensed to use the Platform;
c. 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 must be reported in compliance with industry guidelines, e.g., IAB begin to render:
b. https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf
​
c. http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf
​
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.
a. "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.
b. "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.
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
​
The following table details the 'required' and 'recommended' fields for impression events, with references to the OpenRTB specs where appropriate.
Demand Side Platform LLD Requirements
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:
a. Using the LLD Supplier’s products and services;
b. Licensed to use the Platform;
c. 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:
a. http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf
b. https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf
c. http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf
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.
LLD is to be protected from unauthorised access end-to-end by the Platform using encryption in transit and at rest.
3.2 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.
a. "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.
b. "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.
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
​
The following table details the 'required' and 'recommended' fields for impression events, with references to the OpenRTB specs where appropriate.
Supply Side Platform LLD Requirements
Version: 1.2
Date Updated: March 18, 20
​
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:
a. Using the LLD Supplier’s products and services;
b. Licensed to use the Platform;
c. 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:
​
a. http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf
b. https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf
c. http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf
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 SSP, 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.
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
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.
​
a. "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.
b. "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.
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.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 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
​
The following table details the 'required' and 'recommended' fields for impression events, with references to the OpenRTB specs where appropriate.
Ad Verification Provider Requirements
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:
a. Using the LLD Supplier’s products and services;
b. Licensed to use the Platform;
c. 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:
a. http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf
b. https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf
c. http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf
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 SSP, 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.
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
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.
​
a. "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.
b. "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.
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.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 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
The following table details the required and recommended fields for impression events, with references to the OpenRTB specs where appropriate.
