Skip to content

DigiTrust for Publishers

Jump to bottom
Sam Tingleff edited this page Oct 2, 2019 · 4 revisions

Integration Process

For our purposes a publisher is a producer of web content who licenses third-party vendors for data collection, real-time bidding, etc. instead of building their own platform. If you have built your own platform which necessitates user syncing with other platforms you may wish to also read the documentation for exchanges.

In some cases this may not actually represent the actual publisher but rather a representative acting on their behalf with an ability to modify pages through an ad server or tag manager.

A publisher integration is approximately three steps

  1. Contractual
  2. Client integration (ad tags)
  3. Working with partners

Contractual Process

  1. Publisher to review all deployment requirements with appropriate internal team members. Your privacy counsel should be reviewing the guidance within the regulatory one-sheets for US Publishers or UK Publishers on changes to your privacy policy and (if applicable) your cookie notice; your legal counsel should be reviewing the DIGITRUST ID TERMS OF SERVICE which can be accepted by filling out this form; and your technical leadership should read through this page and perhaps the entire integration guide.
  2. Publisher will add DigiTrust/IAB Tech Lab (ID 64) to your vendor whitelist using a Consent Management Platform that is aligned with the IAB Europe Transparency and Consent Framework for GDPR/ePrivacy compliance in Europe.
  3. Publisher will create a test implementation of the DigiTrust solution, being careful to adequately test on browsers and devices in combination with your full technology environment - client-side and server-side.
  4. Publisher will update your privacy policy and (if applicable) your cookie notice.
  5. DigiTrust will then (optionally, at your request) review the technical integration on a publicly visible test page, and your privacy policy updates.
  6. DigiTrust will assign and provide you with a member ID and site ID for a production deployment.
  7. Publisher will alert their ad technology platforms that they’ve deployed DigiTrust, and request that the platforms begin passing the encrypted ID within every bid request (exchanges) and in any authorized data collection events (DMPs). This word-of-mouth support is critical for the industry adoption that will ultimately benefit Publishers with increased yield and reduced third-party requests (ID syncs) on your pages. A full list of members and their deployment status can be found here.
  8. As the ID gains broader coverage through publisher and platform deployments, publishers should align with their platform partners on a date to switch off user ID syncs. This should happen when the platform sees broader coverage of the DigiTrust ID than their proprietary ID.

Client Integration

Instructions to implement DigiTrust as part of prebid.js can be found at prebid.org.

Non-prebid publishers are expected to deploy the javascript tag directly on page or via tag manager. It should execute prior to any ad requests and should not be within an iframe.

<script src="https://cdn.digitru.st/prod/1/digitrust.min.js"></script>
<script type="text/javascript">
DigiTrust.initialize({
  member: "test",
  site: "test",
  redirects: true
});
</script>
  • The production values to use for member and site will come from the DigiTrust team upon signing the agreement.
  • The values used for member and site do not need to be unique to the site (domain) or publisher. We simply need a signal of the responsible party.
  • See the Integration Guide for more detail.
  • ❗️Note that the redirects parameter will enable rewriting links to route the browser through .digitru.st on some cycle. This is off by default (without the redirects: true above); please test this behavior to ensure no adverse effects!

Working with Partners

In addition to deploying the javascript, please work with monetization platforms to ensure the complete DTID flow works from page through ad request.

Technical Recommendations

  • Subresource integrity (SRI): while we recommend linking to a major version number of the DigiTrust javascript (/1/), sensitive publishers linking to a specific release (such as /1.5.31/) should use SRI to ensure that the linked asset does not change after integration. Please see the section on semantic versioning and subresource integrity in the integration guide.
  • Extensive testing: we understand there is a lot of technology running on your pages already, and therefore recommend testing each release to ascertain that no incompatibilities exist between DigiTrust technology and the technology from your existing ad tech partners.
  • SSL: we recommend serving content exclusively over SSL. Chrome no longer supports client-side encryption functionality within the browser if the web site is not SSL (https) enabled. This presents a challenge for DigiTrust because we encrypt the user token/ID client-side, and we need to introduce a network request for encryption on non-SSL content.
Clone this wiki locally