Make consent work

Before you ask for consent, make sure you don’t waste it.

Consent is meaningless unless it is enforceable. Unless a publisher prevents all data leakage, a consenting visitor cannot know where their data goes.

Perimeter enables publishers and adtech services to leverage personal data when GDPR-quality consent is present, and use non-personal data when consent is absent.

A regulatory firewall

Perimeter enables websites and mobile apps to protect and control the entire ad supply chain in a marketing campaign.

Publishers must stop users’ personal data from leaking, and being illegally processed, in order to comply with the GDPR. Users’ personal data leak via programmatic bid requests, code inside ads, mobile SDK, and 3rd parties active on a website. This exposes publishers, and their advertising partners, to legal risk.1

Control user data and 3rd parties in websites + apps

Perimeter brings privacy and data protection to RTB/programmatic advertising system in the following ways:

  • Automatic removal of data leaking scripts from ads before they are rendered.
  • Prevention of unauthorized 3rd parties from accessing personal data.
  • Enforcement of data protection in RTB bid requests.
  • Enforcement of data protection in SDK behaviors.
The online advertising system was not built with data protection in mind.

Personal data about a website visitor are shared with hundreds of parties every time the website requests an ad through one or more ad exchanges. There is nothing to prevent these hundreds of parties from leaking these data to anyone else. This must be controlled.

The video below shows how data leak from the online advertising system during bidding stage.

Ad exchanges send personal data about website visitors, such as the ad exchange’s own identifier on the user, the URL the user is on, the user’s IP address and details of the user’s browser and system. These data are shared with several hundred prospective advertisers so that they can decide whether to place a bid for that user’s attention.

When an ad is displayed to a user it arrives unaudited, and may execute script that introduces tracking on to the page.

Feature-rich adtech, even without personal data

Perimeter’s privacy-by-design technology enables relevant advertising and sophisticated measurement by compliant adtech partners (including frequency capping, attribution, impression counting, click counting, view-through counting, and conversion counting) without using personal data, unless people give their consent.

When adequate consent is present, Perimeter enables personal data adtech. And it will interoperate as other consent managers enter the market.

Adtech and the GDPR

Perimeter enables publishers to comply with the GDPR by strictly blocking all trackers and unique identifiers on a webpage, or in a mobile app – unless the data subject has given their consent.

Perimeter interoperates with GDPR compliant adtech services so that the publisher can run direct and programmatic advertising.

Let us know if you are an adtech company and would like to be whitelisted to access pages / apps protected by Perimeter.


Most of today’s ad servers implement frequency capping by using a server-side database to store the number of times an ad campaign has been shown to each user. Each user is tracked using a unique ID, which is stored both in the database and in a 3rd party cookie in the user’s browser [4]. Since this user ID could be used to track what websites the user is visiting, and could potentially be matched against other online trackers and offline data, this will be illegal under GDPR (unless the user has specifically consented to it).

A privacy-by-design alternative is to get rid of the user ID and move the counter directly into the cookie. The cookie it is stored in can have an expiry equal to the maximum amount of time the campaign should be capped for, and the name of the cookie can be set to the name of the ad campaign. Variations on this approach have been discussed for years – see Arvind Narayanan and Jonathan Mayer’s approach here. Since the counter does not contain any information specific to a particular user, it is not “personal data” under GDPR, and is not subject to consent.

Two inefficiencies of this approach, storage and bandwidth, are addressed below.

First, how much storage space will all those frequency capping cookies take up in the web browser? So long as the cookie expiry dates are reasonable, this data should be proportional to the number of ad campaigns delivered to a browser over a one- or two-week time window, and should not grow beyond that. Even if a user manages to view a hundred thousand different advertising campaigns in a two week period, that would still require no more than a few megabytes to store.

Second, how much bandwidth might be consumed by transmitting all these view counters along with every request to the ad server? This can be reduced by being efficient in the encoding of the cookie data. As shown in the inset below,  transmitting a frequency counter in the ad server cookie could take as little as 9 bytes of extra bandwidth, which means that thousands of counters could be transmitted without significantly impacting the weight of a modern web page.

Calculating potential bandwidth requirements
The name of the cookie might be used to store a campaign ID, efficiently encoded using all the characters available according to RFC 6265 (i.e., “A-Z”, “a-z”, “0-9” and “!#$%&’*+-.^_`|~”). That’s 77 characters, meaning that just four characters can be used to encode over 35 million (i.e. 774) different IDs, which is easily sufficient for all ad campaigns that an ad server might be managing in a given period. Meanwhile, the value portion of the cookie needs only contain a counter, which can be 2 characters long (to store a value up to 99 in decimal, or about 6,000 in base-77 encoding.With this system in place, a browser request to an ad server might consist of the following HTTP request:

GET /ad HTTP/1.1
Cookie: 2iP&=21; Rz%x=13

The “Cookie:” field concatenates all cookies previously stored by the ad server. We can see that the bandwidth consumed by each frequency counter is only 9 bytes in total: 4 characters for the campaign ID, 2 characters for the counter value, and 3 counters for the equals sign, the semi-colon delimiter and the space. It would only take 20 Kb to transmit over two thousand frequency counters in an ad call.

There is a further opportunity to optimize bandwidth, with the help of header bidding. Because header bidding sends multiple potential bids to the client, the client can do the work of deciding which ones have not reached a frequency cap and are therefore eligible for display. SSPs are currently moving from second-price auctions to first-price auctions to better support header bidding, and in time are likely to start returning multiple bids to header bidder wrappers, so that more bids can participate in the final auction. This will provide plenty of choice to a client-side frequency capping algorithm, and probably entirely eliminate the need for the frequency capping data to ever leave the browser.

Adtech: contact us to work with Perimeter
Campaign metrics allow advertisers and media owners to see how different advertising campaigns are performing, and to optimize campaigns if necessary. The typical metrics are impression counts, click counts, conversion counts, view-through measurement and viewability measurement.

Fortunately, none of these metrics concern individual people. Therefore, ad servers can avoid tracking information at an individual user level to ensure GDPR compliance. It is likely that many of today’s ad servers have not been so careful, and have implementations that currently depend on counting the same user ID that was used for frequency capping. These ad servers will need to consider providing alternative implementations when serving ads to EU users.

In the paragraphs below we review typical campaign metrics for likely GDPR compliance, and suggest alternative implementations where appropriate.

Impression Counting

Impression counting is normally implemented by incrementing a database counter pertaining to the ad campaign whenever a request is made to the ad server for that campaign, or when an impression pixel specific to that campaign is loaded from the ad server by the web browser. Basic impression counting should not pose a problem under GDPR, as no user-specific information is processed or stored [5].

Click Counting

Click measurement is normally performed by redirecting the browser to the ad server when the ad is clicked on, at which point it registers the click event, and then redirects the browser to the advertiser URL.

Like basic impression counting, click counting should not be problematic under GDPR, as all that is required is an overall counter of the number of times that an ad has been clicked on across all users, without the involvement of any user-specific information.

When the number of clicks is known, the click-through-rate is given by dividing the number of clicks by the number of impressions for any given campaign.

Conversion counting

Conversion counting is normally performed by obtaining a campaign-specific pixel from the ad server, and placing that pixel on a web page the user will be brought to when they complete a transaction with the advertiser (when they “convert”). When a user who has clicked on an ad “converts”, the conversion pixel will be loaded from the ad server, which will increase the conversion count for that campaign by one.

As with impression counting and click counting, there is no specific privacy concern here: only campaign-level data is used, and no user-specific information is processed.

View Through Measurement

Although click-through rates help an advertiser understand the immediate positive reaction of users who see their ad, many are also interested in the indirect response, e.g., how many people who saw the ad went on to buy the product during the subsequent weeks regardless of clicking on the ad?

It is possible that some ad servers currently perform view-through measurement using user-specific information. For example, the ad server might record that an ad was viewed by a particular user ID. When the conversion pixel loads on the advertiser’s post-conversion page, the ad server could look up the details of the last time that user ID viewed that campaign.

The above implementation would be incompatible with GDPR, as it involves tracking the behavior of unique users. Fortunately, there are alternative implementations that are equally effective.

The correct approach is to use a non-tracking cookie to store the fact that the user has viewed the ad campaign. This means that the cookie would contain the ID of the ad campaign, not an ID of the user (and consequently, every user who saw that campaign would have an identical cookie). This cookie should be set to expire automatically when a certain amount of time has passed, beyond which the advertiser is not interested in attributing the visit to the fact the ad was seen. In this system, when the user eventually converts for the advertiser, the cookie containing the campaign ID is transmitted to the advertiser’s ad server, which can then increment the relevant view-through counter.

It is possible that this approach could lead to a lot of cookie data being transmitted and consuming bandwidth. To mitigate this, the view-through pixel should be homed on a domain unique to each advertiser, rather than every advertiser sharing the domain of their ad server.

Viewability Measurement

Viewability measurement allows advertisers to understand how many of the ads they pay to serve on a web site are likely to scroll into view and be displayed for long enough for a user to potentially notice them.

Viewability measures a characteristic of websites, not users, and can therefore be implemented in a GDPR compatible fashion. Although some viewability systems today might store per-user information, there is no fundamental need to do so. All that is required is to detect when a view event has occurred for each ad space, and to send that to the server to be counted. The server will then aggregate these events and provide an overall count of the number of times each ad space has been viewable by any user in each time period.

Adtech: contact us to work with Perimeter
Perimeter components

Server side ad rendering
Controls data in bid requests and ad creatives.

Policy Manager
Empowers the publisher to decide what partners are permitted on the site / app.

User Consent Manager
Enables consent to be obtained, communicated, and withdrawn by users.

Privacy-by-design adtech interoperation
Perimeter is partnering with other adtech vendors who are innovating to be compatible with strict enforcement of privacy regulations. This re-enables all core campaign management, measurement, capping, and targeting features without depending on legally toxic tracking IDs.

Check your adtech vendors' GDPR-readiness
Publishers can use this questionnaire to query their adtech vendors about their GDPR-readiness.
From PageFair

We know adtech. And we know regulation.

We take a strict interpretation of the Regulation, and we believe that it will be enforced.

Perimeter is the result of 24 months of intensive research and development, working with publishers, app developers, advertisers, adtech services, privacy NGOs, regulators, and law makers.

PageFair’s adtech expertise comes from half a decade at the forefront of the adblocking challenge. Our technology protects billions of ads per month from tampering by adblock companies, and automatically re-renders intrusive ad formats in to LEAN standard ads to improve to user experience.

PageFair has a deep understanding of the GDPR. Our research notes on the GDPR are read by several thousand subscribers every month (Sign up to receive these for free), and we have been invited to present at the European Academy of Law, the European Parliament, and the World Federation of Advertisers.

You can access PageFair’s repository of analyses, explainers, and official documents here.

Register your interest

Size of your organisation

Combined monthly page views from website(s)
Monthly active users of mobile app(s)

Ticking the box below allows us to use a company called Mailchimp to send you research notes.

  • Every note we send includes links at the bottom with which you can change your details or withdraw your consent.
  • Should you believe your data are being misused, you can complain to a data protection authority. MailChimp transfers personal data between the EU and the U.S. under the Privacy Shield agreement, which provides you a range of rights and safeguards intended to be equivalent to those provided in the EU.
  • The personal data you submit on this form are stored only so long as you wish to receive research notes from PageFair.