Frequency capping and ad campaign measurement under GDPR

Sean Blanchfield GDPR Leave a Comment

This note describes how ad campaigns can be measured and frequency capped without the use of personal data to comply with the GDPR. 

It is likely that most people will not give consent for their personal data to be used for ad targeting purposes by third parties (only a small minority [1] of people online are expected to consent to third party tracking for online advertising). Even so, sophisticated measurement and frequency capping are possible for this audience.

This note briefly outlines how to conduct essential measurement (frequency capping, impression counting, click counting, conversion counting, view through measurement, and viewability measurement) in compliance with the EU’s General Data Protection Regulation. This means that publishers and advertisers can continue to measure the delivery of the ads that sustain their businesses, while simultaneously respecting European citizens’ right to protection of their personal data.

Note that this discussion assumes that the final text of the EU’s ePrivacy Regulation will not incidentally illegalize non-tracking cookies (i.e., cookies that neither contain nor reveal any personal data, and therefore pose no privacy risks) [2].

Table: cleaner ad tech measurement [3]

 

Frequency capping, without personal data

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
Host: acmeadserver.com
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.

Campaign Metrics

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.

Notes

[1] See “Europe Online: an experience driven by advertising”, GFK, 2017, p. 7 and “Research result: what percentage will consent to tracking for advertising?”, PageFair Insider, 12 September 2017.

[2] For an overview of the issues see a previous PageFair Insider note, “The Privacy Case for Non-Tracking Cookies: PageFair writes to the European Parliament”, PageFair Insider, 10 August 2017 (URL:  https://pagefair.com/blog/2017/non-tracking-cookies/).

[3] Clearly, a campaign that targeted a single individual without a legal basis for doing so would be illegal. It is important that campaigns must target more than a small set of viewers.

[4] These data are automatically transmitted to the ad server along with every request.

[5] Ad servers may also support the counting of “unique impressions”, which means the number of unique users who saw the campaign. This mechanism generally relies on tagging each user with a unique identifier, and counting the number of unique identifiers. Therefore, while impression counting is practical, unique impressions may not be because a unique identifier could be misused.