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.
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.
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.
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
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 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 .
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 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 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
Publishers can use this resource to verify their adtech vendors’ GDPR readiness.
Server side ad rendering
Controls data in bid requests and ad creatives.
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-readinessPublishers can use this questionnaire to query their adtech vendors about their GDPR-readiness.
We know adtech. And we know regulation.
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.