A privacy gate can be defined as a layer implemented by the publisher to centralise consent collection in one place and share this consent across their properties. It is very important, however, to state in the first layer the scope of collected consent and what properties the user’s consent applies to. 

Following the industry’s changes with the upcoming deprecation of 3rd party cookies, the introduction of global privacy control initiative, Apple’s ITP restrictions and other changes, industry stakeholders have started thinking about ways they can replace cookies for targeting, content personalization and most importantly consent collection. Consequently, a number of our clients have started implementing what is called a privacy gate to better prepare for these changes.

The privacy gate serves, among others, the following purposes:

  • Share consent between properties
  • Prolong consent duration in Safari
  • Make sure authenticated users have their consent preferences respected across different devices and properties (in case you choose to go with an authenticated consent).

While there are multiple ways to implement a privacy gate whereby the same logic is tweaked to answer specific needs, we have compiled a popular method of implementing a privacy gate utilized by some of our clients.

Privacy gate requirements

The following requirements are necessary in order to set up a privacy gate (some of these requirements are covered in this article):

  • Have Sourcepoint’s SDK installed on the properties between which consent will be shared.
  • Include properties between between which consent will be shared on the same vendor list.
  • Set the Consent Scope in the vendor list builder to Shared.
  • Ability to set a server side cookie.

Privacy gate schematic

Below please find the schematic for how consent is shared across your properties:


Privacy gate implementation

The implementation for a privacy gate happens both in the Sourcepoint platform and on the publisher side:

Sourcepoint platform

Include all properties between which consent will be shared on the same vendor list and set the Consent Scope to Shared.

Click Save when finished.


Publisher side

The following changes should be implemented on the publisher side:

  • Set up a new domain that will serve as the privacy gate. This domain can be disassociated from your properties and only serves the purpose of communicating the authId cookie between properties
  • CNAME the privacy gate’s domain to point to Sourcepoint's endpoint
  • In your CDN, set up a logic that checks the existence of a cookie authId at the level of the privacy gate. If the cookie does not exist, generate a random value and create a first-party cookie with the same value.
  • Set the authId cookie on the privacy gate
  • Redirect to the property using a get parameter with the authId
  • Set the cookie on the property’s URL

Tips and improvements

  • You can choose to use a mix of authenticated and unauthenticated consent. For example. if the user logs in, overwrite the authId’s value with the user’s ID.
  • Set the cookie at the server side, this way the cookie’s lifespan gets extended beyond the 24 hours set by Safari’s ITP restrictions.
  • If you wish to show the banner at the privacy gate, you can put a background that is an exact copy of the property’s URL. You will also need to add our script to this URL, create a property/campaign in the UI and add this property to the shared vendor list.
Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.