GDPR & Kevel

The European Union's General Data Protection Regulation (GDPR) went into effect on May 25th, 2018. This law will impact any business that is dealing with personal data of EU residents.

For an in-depth dive into what the GDPR is, please refer to The GDPR: A Quick Synopsis for Ad Tech.

Below lists the steps that Kevel has undertaken to be compliant with GDPR. We've also included a guide for our customers to follow to remain compliant.

❗️
Please note: it is likely that the GDPR will impact you, even if you aren't located in the EU, as it affects any entity that processes data of EU residents. The biggest changes for our customers will likely be around EU frequency capping, user-level targeting, and user matching for programmatic ads.

Technical Changes to Ensure Compliance

In order to ensure Kevel and our clients are compliant with the GDPR, we have enacted the following measures.

1. Ability to Track Consent For EU Residents

If Kevel is sent a request with an EU IP address, by default we will:

Not store data in the user's UserDB record
Not set Kevel-related cookies in their browser

However, as long as the EU citizen gives consent - and that consent is passed to Kevel - we will continue to store information and/or add cookies.

This can be done in one of three ways (specific integration details are here):

Say that the user has consented in the Decision API Request
Say that the user has consented in the Ados.js request
Update UserDB directly with the consent

🚧
In identifying an EU resident, Kevel will be looking at their IP Address. This would mean that an EU citizen in the USA wouldn't get blocked. Likewise, a US-citizen in Spain would. Multiple guidance from regulators have said that using IP to identify if they are an EU-resident is acceptable.

2. Removal of PII in Data Shipping Logs

Instead of writing a user's UserAgent into data shipping logs (which can be a potential source of personally identifiable information), Kevel logs device info via WURFL:

Device & Version
OS & Version
Browser & Version
Form Factor (mobile, desktop, tablet)

An example of device data from data shipping logs:

"Device":{  
      "brandName":"Google",
      "modelName":"Chrome",
      "osRawVersion":"0",
      "osMajorVersion":0,
      "osMinorVersion":0,
      "browser":"Chrome Desktop",
      "browserRawVersion":"63.0",
      "browserMajorVersion":63,
      "browserMinorVersion":0,
      "formFactor":"desktop"
   },

We've also removed latitude and longitude data from logs.

3. Removal of Frequency Capping & RTB User Matching on EU Non-Consenting Users

Starting on May 25th, 2018, Kevel requests that originate from the European Union and do not include GDPR consent nor have a UserDB row that indicates consent will no longer be frequency capped. Frequency capping requires that Kevel store anonymous information about ads served to individual users, so per the GDPR consent is required.

If Kevel customers want to continue to frequency cap ads to audiences in the EU, they must obtain GDPR consent from their users.

This also applies to user matching on RTB requests, as Kevel customers must obtain GDPR consent from EU users before the user matching endpoints can be used. This means that cookie syncing and other forms of user matching cannot be processed for non-consent requests.

4. Ability to Honor the Right to Be Forgotten

Kevel has added a new UserDB endpoint that removes a UserDB record entirely and unsets the azk cookie that contains the UserKey.

5. Using Individual CNAMEs for Privacy

To better handle consent we are moving all customers to their own custom CNAME. This means for most customers your decision API request will go to a new URL or an additional line will be needed to your ados.js tag. This will be a mandatory change for all customers.

6. Certifications

Kevel will be PrivacyShield certified for EU traffic.

7. Continuous Risk Assessment

Kevel has several recurring automated and human-operated risk and vulnerability analyses in place to detect potential security vulnerabilities.

8. What we collect / how long we store it

Our privacy policies are updated to reflect the needs of the GDPR. While we've always considered your data of the utmost importance, some data like IP address and user agent are being protected even more than in the past.

9. Stripping of PII Before Sending to RTB Partners

For ad requests from in EU member nations, if no GDPR consent is given, then all personally identifying information (PII) including IP address, user agent string, and latitude/longitude will be stripped before making any downstream RTB bid requests.

10. Created a Data Processing Agreement

Kevel's DPA is aimed to help you feel confident that you are working with a GDPR-compliant partner and to save both parties from legal harm should the other party breach the agreement. The document lives here.

11. Breach Notification Plan

If Kevel were to experience a data breach then all impacted customers would be notified within 72 hours.

12. Secure data transfer and storage outside the EU

All data is stored and transmitted via encryption. All EU data transferring outside of the EU will follow the strict rules of the EU PrivacyShield certification.

13. Technical and organizational security measures

Kevel takes a holistic, risk-based approach to security. This means the platform secures your data in transit and at rest, restricts and secures data access, and provides continuous incident monitoring.

14. Processing according to controller instructions

Kevel only processes personal data according to instructions from the controller (our customers).

15. We're coordinating with our vendors

We're reviewing all our vendors, finding out about their GDPR plans, and arranging similar GDPR-ready data processing agreements with them.

16. No sharing of data

Kevel has never - and will never - share user-level data of our customers. Any user-level information you have ever sent us, or will in the future, is only your own, meaning we don't even share aggregated, anonymized data.

What Customers Need To Do

Fortunately we've made it as easy as possible for our customers to be compliant. In fact, if you have little European traffic and won't be collecting consent, then you don't need to do anything!
In that case Kevel will conservatively handle requests from European IP addresses to ensure compliance.

However, if you're collecting consent in order to track and use data about European residents, then you'll need to follow the steps below.

What To Do If You're Collecting Consent

1. Update your Kevel calls to send consent

See here for instructions on updating your calls and sending us information on whether a user has consented.

2. Determine whether you want to store consent yourself or in Kevel's UserDB

If you are collecting consent, you'll want to determine whether you store that in your system (and set "consent": {"gdpr": true} for all future requests for that user), or store that information in Kevel's UserDB first-party data management platform. If you store it in UserDB, you only need to pass "consent": {"gdpr": true} once. Please note this requires the UserDB upgrade.

3. Make sure you have a way to honor the user data rights (i.e. enable your users to access and delete data you have on them)

In the FAQ below we provide more details on how you can use Kevel to do this.

❗️
If you use frequency capping, RTB user matching, or user-level targeting for EU campaigns, please note that these will no longer work for users that haven't given consent. This means that you may see ad serving changes starting on May 25th, 2018, when Kevel officially switches over.

FAQ

Biggest Impacts for Customers

Can I frequency cap ads for EU residents?

You can employ frequency capping for users that have given you consent. However, for those that have not, then Kevel cannot store the number of times they have seen each ad, and, therefore, frequency capping will not work for those users.

How will RTB work for EU residents?

Kevel will still send request to RTB partners for EU traffic. However, two things will happen that will likely impact fill rates and eCPMs:

(a) Kevel will block any user matching / dropping of cookies, so the request will be unmatched on the partner's side
(b) Kevel will not send IP Address or User Agent, potentially limiting fill rates and eCPMs

Will I see a drop in RTB revenue

Probably - but just for EU residents. This drop could be substantial, so it's important to start planning now on ways to get consent / increase revenue through other sources.

What should I tell my advertisers?

For your direct-sold campaigns, the biggest change will be loss of frequency capping for non-consenting users. If you have sold an advertiser on this capability, you will want to have a conversation with them about GDPR.

Additionally, you'll want to create your own website page explaining the steps you've taken to be GDPR compliant, so that your advertisers feel safe continuing to work with you. That outline would likely mainly consist of what's on this document, as well as any specific plans you're making to collect and honor consent.

General GDPR Questions

What's considered Personally Identifying Information (PII)?

The GDPR is strict on what is considered PII. It includes, but isn't limited to: SSN, IP Address, lat/long coordinates, cookie IDs, mobile IDs, user agents, RFID numbers, email, physical address, and biometric/financial/behavior/demographic data.

Can I continue to use data I collected before May 25th, 2018?

Only if you subsequently receive opt-in consent. Data about non-EU residents can of course still be used.

Do I have to delete the data I collected before May 25th, 2018?

For EU residents, if you do not receive consent to use their data in a timely manner then the data should be purged.

Is the UK considered part of the EU?

For now, yes.

What happens if I don't comply?

There can be enormous financial penalties, as high as 20 million Euros or 4% of your global revenue, whichever is higher. It's likely that before a fine happens you'll get a warning first, after which a fine will come with further non-compliance.

Are my data providers compliant?

If you are partnering with a 3rd-party data provider to match your user data to wider data sets, then likely no. Many data providers buy their data, adding an extra layer of potential issues, and the original first-party source was unlikely to have asked consent pre-GDPR. No matter what, you'll want to sign data processing agreements with all your data partners and only work with GDPR-compliant ones.

What data can I collect now?

You can continue to collect and store any data that the user has consented to via an opt-in form. This includes e-mail addresses, demographic data, etc.

Questions About Consent

How do I store consent?

There are two ways to do this:

Store this information in your database. Then, if you want to do frequency capping and RTB matching, pass "consent": {"gdpr": true} in the API every time you send a request
Store this information in UserDB. All you need to do is set "consent": {"gdpr": true} once, and UserDB will record that. For future pings, you just need to pass the UserKey. Please note - this requires the UserDB upgrade.

Where does Kevel store the consent?

If you are not using UserDB, then we do not store any user-level data in our system. However, we do drop a cookie on the user's browser that contains info about what campaigns/flights/ads they saw, in order to enable frequency capping.

If you are using UserDB, then we store that info in UserDB, with all info you send tied to a specific UserKey. This data could include frequency capping info, first-party demographic data, and interest segments based on content they've interacted with.

How can I honor the data rights?

There are multiple data rights, and below we list how you can honor them. Please note that the onus of honoring the rights falls on the data controllers, while Kevel (the data processor) provides the ability to store, pull, and remove that data.

Right	Description	If using UserDB	If not using UserDB
Right to informed consent	Users must be informed of what data is collected and why	This should live in your opt-in consent form	This should live in your opt-in consent form
Right to object	User can prohibit certain data uses	In your consent form you should determine whether to have opt-in for different data uses	In your consent form you should determine whether to have opt-in for different data uses
Right to be forgotten	User can request data to be deleted	Ping our new Forget User Endpoint with their UserKey. Please note, this requires API authentication	Tell the user to reset their cookies
Right to rectification	Users can request that any data be changed	You can use the UserDB Custom Properties Endpoint to update any info tied to their UserKey	You will be storing this, not Kevel
Right to access and right to portability	User can access collected data or ask for it to be transferred	Ping the Read User UserDB Endpoint to pull UserDB data, which can then be shared individually with the user	You will be storing this, not Kevel

How do I create an opt-in consent form?

Below are some resources to help you build a GDPR-compliant consent form.

GDPR: 10 examples of best practice UX for obtaining marketing consent - eConsultancy
How to design GDPR compliant consent - Sagara Gunathunga
GDPR: consent opt-in examples - Zettasphere
GDPR consent dialogue examples - PageFair
Consent, forms, and the GDPR - GF4B

Should I even bother asking for consent?

There is no right answer to this. If you are heavily reliant on programmatic revenue, then the more people who consent, the more money from RTB you'll make, as CPMs will drop without user matching. At the same time, if consent rates are low, you may find that the user experience is not worth prompting every user.

Also, please remember you really only need to ask for consent from EU residents. If you have little or no European traffic you probably don't need to bother to ask for consent.

How should I ask for consent?

If you do ask for consent, you should target the prompt to just EU IPs by using an IP look-up tool. You could ask at any point, including:

When the user is finishing a registration process
When the user first enters the site
When the user has completed an action, such as finished an article, purchased an item, etc

Do I need to ask consent every time they come to the site?

Once you get consent once, you do not not need to keep asking on future visits. If they haven't consented, it's your choice whether to keep prompting them or not.

Can I send you PII if the user gives consent?

Yes, but we do prefer that you pseudonymize the data before it's sent. For instance, for security purposes, we'd prefer receiving a user string like 1241251 versus [email protected]. This also helps to minimize the actual PII data you share with us, your data processor, making it safer for you should a breach happen. This isn't strictly necessary but a best practice.

If I'm using UserDB, how do I offer my users the right to rectify/access/etc their data?

How you do this is up to you. Two basic ideas are:

Have a website page dedicated to GDPR compliance that lists an e-mail address to contact to rectify/delete any stored data. Then, match them to their UserKey and use the UserDB endpoints to pull/change/delete their user data, and respond to them individually.
Have a page decided to the GDPR that syncs with Kevel's UserDB API automatically, so that the user can press a button and see/edit/delete the data you have on them.

Kevel-Related Questions

Will Kevel be deleting all legacy user-level data for EU residents that don't have consent?

No, as the data belongs to our customers and not to us, we cannot outright delete data that was captured before May 25th, 2018. However, Kevel cannot use this data for ad targeting purposes unless consent if given.

How long does Kevel store data for?

We store campaign configuration information and first-party user data (in UserDB) indefinitely. We also store historic reporting information (in aggregate) indefinitely. However, any potential PII including IP address, user agent string, and latitude/longitude data are retained only for a few minutes while we serve ad decisions and then post-process the decisions for reporting purposes. We strive to keep this time period, usually only a couple of minutes, as short as possible.

If we part ways, will Kevel delete my data?

Kevel will store your ad serving data - such as campaigns, ads, raw logs - for 30 days after expiration of the contract before deleting it. Alternatively, if you ask for it to be deleted within 30 days, we will comply with that.

If I send PII to Kevel that isn't compliant, is Kevel at fault for storing it?

As we are blocking PII collection unless you specifically say there's consent, the onus of legal responsibility would fall on you as the Data Controller under the GDPR.

Do I have to worry about Kevel's data being compliant?

The good news is - Kevel doesn't bring it's own data! As Kevel is not a 3rd-party DMP or data provider, the only data we use for user-level targeting is data which you give to us. So, you can be confident that by building with Kevel, you aren't potentially working with data that was collected illegally.

UserDB questions

Why should I use UserDB for GDPR compliance?

If you plan on collecting consent, you can store it on your side and pass it on every ad request. Alternatively, you could use UserDB to store whether a specific user consented. In this case, you would tell Kevel just once that the user consented, and then won't need to include that in future requests. This is especially helpful if you're already storing first-party data for custom targeting.

Do I need UserDB to do frequency capping?

Nope. You will need to pass "consent": {"gdpr": true} on every ad request for that user for it to work, though. Please see our frequency capping documentation for additional steps to implementing it via the API.

Do I need UserDB to do RTB user matching?

Yes, the RTB third-party pixel matching mechanism requires the UserDB feature.

How much does UserDB cost?

UserDB may require an upgrade if your contract doesn't include it. Please chat with your account manager for more info.

Kevel as the Data Processor

The GDPR specifies two types of companies in respect to data: Controllers (those who decide what to do with the data) and Processors (those who engage with the data on behalf of the controllers).

For Kevel clients, Kevel will be their Data Processor, while our clients are controllers. According Article 28, the relationship between the controller and the processor needs to be made in writing (or signed electronically) - and this is why we have a Terms of Service, Privacy Policy, and Data Processing Agreement.

Kevel as the Data Controller

Additionally, Kevel acts as the data controller for the personal data we collect about you, the user of our web app, mobile apps, and website.

First and foremost, we only process data that is necessary for us to perform our contract with you (GDPR Article 6(1)(b)).

Secondly, we process data to meet our obligations under the law (GDPR Article 6(1)(c)) — this primarily involves financial data and information that we need to meet our accountability obligations under the GDPR.

Thirdly, we process your personal data for our legitimate interests in line with GDPR Article 6(1)(f).

What are these ‘legitimate interests’ we talk about?

Improving the UI and API
Making sure that your data and Kevel's systems are safe and secure
Responsible marketing of our product and its features
Collecting and storing form-fill-out information for sales outreach purposes
Customer relationship management

As the controller for your personal data, Kevel is committed to respecting all your rights under the GDPR. If you have any questions or feedback, or want to view/delete/rectify the data we have on you, please reach out to us at [email protected].

Sub-Processors Kevel Uses

For a full list of sub-processors Kevel uses, please visit this page.