--- title: TrustNet Member Requirements description: Data requirements for TrustNet's supply chain members. image: https://www.tagtrust.net/hubfs/TrustNet/trustnet-logo.png --- [![TAG_TrustNet_75h](https://www.tagtrust.net/hubfs/TAG_TrustNet_75h.png "TAG_TrustNet_75h")](https://www.tagtrust.net/?hsLang=en) # 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](https://www.tagtrust.net/member-requirements#AdvertiserRequirements) - [Ad Server Requirements](https://www.tagtrust.net/member-requirements#AdServerRequirements) - [Demand Side Platform Requirements](https://www.tagtrust.net/member-requirements#DemandSidePlatformRequirements) - [Supply Side Platform Requirements](https://www.tagtrust.net/member-requirements#SupplySidePlatformRequirements) - [Content Verification Requirements](https://www.tagtrust.net/member-requirements#ContentVerificationRequirements) - [Publisher Requirements](https://www.tagtrust.net/member-requirements#PublisherRequirements) --- ## 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](https://www.tagtoday.net/verified-by-tag?hsLang=en)) 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: - [Adserver](https://www.tagtrust.net/member-requirements#AdServerDataRequirements) - [Content Verification Provider](https://www.tagtrust.net/member-requirements#ContentVerificationDataRequirements) - [Demand Side Platform](https://www.tagtrust.net/member-requirements#DemandSidePlatformDataRequirements) - (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: - [Supply Side Platform](https://www.tagtrust.net/member-requirements#SupplySidePlatformDataRequirements) - 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: - [http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf), - [https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf](https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf), - [http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf). - 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](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 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](https://www.tagtoday.net/verified-by-tag?hsLang=en)) 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 access must be provided to clients promptly upon request by the contract owner. - 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: - [http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf), - [https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf](https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf), - [http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf.](http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf) ## 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. | --- ## 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](https://www.tagtoday.net/verified-by-tag?hsLang=en)) 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: - - [ http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf ](http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf), - [https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf](https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf), - [http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf.](http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf) ## 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](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. | --- ## 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](https://www.tagtoday.net/verified-by-tag?hsLang=en)) 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 access must be provided to clients promptly upon request by the DSP seat owner. - SSPs 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: - [http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf), - [https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf](https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf), - [http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf). ## 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](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.](https://iabtechlab.com/wp-content/uploads/2019/07/Sellers.json_Final.pdf) | | 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. | --- ## 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](https://www.tagtoday.net/verified-by-tag?hsLang=en)) 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 access must be provided to clients promptly upon request by the contract owner. - 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: - [http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Desktop-Display-Impression-Measurement-Guidelines-US%20(MMTF%20Final%20v1.1).pdf), - [https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf](https://www.iab.com/wp-content/uploads/2016/12/Digital-Video-Impression-Measurement-Guidelines_1.1.pdf), - [http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf](http://www.mediaratingcouncil.org/Mobile%20In-App%20Measurement%20Guidelines%20(MMTF%20Final%20v1.1).pdf). ## 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](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. | --- ## 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](https://www.tagtoday.net/verified-by-tag?hsLang=en)) 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](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](https://www.tagtrust.net/hubfs/TrustNet/trustnet-logo-white.png "trustnet-logo-white")](https://www.tagtrust.net/?hsLang=en) - [Privacy Policy](https://www.tagtrust.net/privacy?hsLang=en) - [Terms of Use](https://www.tagtrust.net/terms?hsLang=en) - [Support Center](https://support.fiduciadlt.com) - [Contact](mailto:info@tagtrust.net) - - Copyright © 2026 Trusted Advertising Network, LLC. All Rights Reserved.