Compliance with GDPR
  • 18 minutes to read

Compliance with GDPR


Cxense helps publishers and marketers across the globe to transform their raw data into their most valuable resource. Cxense's leading Data Management Platform (DMP) with Intelligent Personalization, gives companies unprecedented insight about their individual customers.

This resource must be managed with care and diligence, and the General Data Protection Regulation (GDPR) is the legal framework under which Cxense as an EEC-based company, operates when processing personal data

This guide aims to describe the changes that may be required to continue operating a web property with Cxense powered analytics, content recommendations or advertising, and in doing so provides some context about the GDPR to shape a common understanding of the motivations for these changes.

Important!
The interpretations of and references to the GDPR contained in this document do not constitute legal advice. Cxense advises our customers to obtain the advice of their own legal counsel with regard to the application of regulation to their operations

What is GDPR?

GDPR has been introduced in the EU to unify the existing national privacy regulations of the EU member states. While the GDPR is a significant piece of legislation, it is not a massive change from previous regulations in every way. Many of the rights granted to individuals are already part of existing legislation and many practices that are now required were recommended practices before.

Legal basis

The most significant change from the perspective of technical integration of Cxense is the requirement that all personal data processing must take place under a limited set of legal bases. While the GDPR enumerates a number of possible legal bases for various processing activities, the legal basis most likely to be applicable to Cxense customers is individual user consent of Article 6(1)(a). In some specific cases, the processing may also be based on the legitimate interest of the data controller, of Article 6(1)(f).

When considering the options, be mindful that GDPR compliance is an industry wide challenge, and the full complement of third party tags and widgets on the site must be taken into account when considering the impact of the GDPR on a site.

The decision of which legal basis to use for data processing rests with you as the data controller, and requires careful consideration and understanding of the law and the particulars of your operation. Consult with your legal counsel or data protection officer.

We will briefly describe the two options below to get you started.

Consent

Individual user consent is the least legally risky option, and the most generally applicable legal basis for the data processing activities. Individual informed consent from your users is a strong legal basis for collecting and processing personal data with the services provided by Cxense.

Cxense services in and of themselves are not particularly more likely to require consent than other offerings in the DMP and personalization space, and customers should assess the entirety of their data processing activities when deciding about the legal basis for their operation.

Cxense supports serving users with individual user consent, but this may require implementation changes on the site where the Cxense cx.js tag is deployed. See below for more details.

Legitimate interest

When a data processing activity is compellingly justified by a legitimate interest of the data controller and care is taken to consider and protect people’s rights and interests, article 6(1)(f) may be an applicable legal basis for processing of personal data under the GDPR.

This legal basis puts a legal burden on the controller to demonstrate their interest in the processing and require a careful balancing of the legitimate interest and necessity of the processing in achieving that interest, and the individual’s interests, rights and freedoms.

When considering this balance, be aware that the user interest profile generation functionality of the Cxense platform constitutes a type of personal data processing that may be difficult to justify with legitimate interest as a legal basis.

Despite these hurdles, this is a very attractive option for one simple reason: Not all users are likely to consent to having data about them collected and processed. This must be weighed against the legal risks of non-compliance.

Where Cxense is used for a processing activity and purpose justified by a legitimate interest, the existing Cxense cx.js tag may be used without further modification.

Other concerns

Several other changes also require the attention of Cxense and you as a Cxense customer, such as stricter obligations on those who control and process personal data, requirements on documenting the processing of data and designing for privacy throughout all personal data processing. One aspect of the GDPR that has caught much attention is the financial sanctions for non-compliance which have been raised significantly from earlier levels.

We have also prepared a more compact set of questions and answers regarding the GDPR and Cxense in the form of an FAQ

Overview of processing activities

Cxense tracks page view and other behavioral events which constitute personal data. These events are used to produce statistics, user profiles and content profiles. With these statistics and profiles, we personalize individuals’ experiences with our customers’ content and targeted marketing.

The page view events collected by Cxense are sent from users’ devices by embedding a Cxense tag on customers’ web pages. This tag collects a set of Cxense cookies, device information, and site visit information. While no directly personally identifiable data is collected here, it is possible to include directly identifying information via custom parameters provided by customers’ code. In any case, this data is considered personal due to the pseudonymous identifiers included.

DMP events submitted to the Cxense DMP platform may contain arbitrary data, although commonly used data types include gender and age group information, pseudonymised subscriber identifiers, and other first party data relevant to targeting personalised experiences or advertising.

These events, combined with data collected from customers’ web sites, are used to build aggregated user interest profiles and audience segments which in turn are used to serve personalised content, tailor user experiences to the user, or serve targeted advertisements.

Cxense maintains a registry of Data Processing Activities as mandated by the GDPR and reports from this registry are available to our customers to document and audit the data processing activities performed by Cxense on behalf of our customers.

Roles and obligations under the GDPR

The GDPR places specific obligations on those involved in processing personal data.

Under the GDPR, the Data Controller is the entity that determines the purposes and means of a given data processing operation. You, the customer, act as the data controller for data collected by Cxense to provide our services.

As your service provider, Cxense acts as a Data Processor in GDPR terms, as we process data on behalf of you, the data controller.

The impact on your agreement with Cxense

The GDPR places additional obligations on both the data controller and data processor involved in a data processing operation. To clarify these obligations and responsibilities, we have updated our master terms of service and published a new Data Processing Addendum which lays out the specifics of our cooperation. You will receive this for review and execution from your account manager.

This Data Processing Addendum needs to be entered into by existing customers before the GDPR enters into force to maintain compliance, as it contains language updated to comply with the requirements of the GDPR.

Your obligations as a data controller

The GDPR places many responsibilities with the data controller. The primary responsibility for the data controllers is ensuring and documenting compliance with the data processing principles. This includes the requirement of only processing data on a sound legal basis. For the purposes of services provided by Cxense most likely means assessing whether the data processing is legal based on a legitimate interest, or requesting consent before any processing of personal data takes place.

The data controller is also responsible for complying with data subjects’ rights to control the data about them. Cxense is prepared to support our customers with these compliance requirements with optimized support case processes and aim to offer APIs optimised for this purpose.

Other obligations involve having data processing agreements in place with data processors, maintaining records of processing activities and contact with data protection authorities including breach reporting. Cxense will provide a Data Processing Addendum to our terms of service to cover the requirement for a data processing agreement, and are preparing records of our data processing activities to support our customers’ record keeping obligations and any audits.

Cxense obligations as a data processor

Cxense is compelled to process personal data only in a lawful manner, which requires that we only process data that the data controller can lawfully process, and only within the scope set forth by our mutual data processing agreement.

Data processors are obligated to maintain confidentiality, ensure the security of the data processing activity and may only subcontract processing to third parties with the agreement of the data controller.

Many of the obligations imposed on data controllers also apply to data processors inasmuch as they affect the processing of data. One example of this is the obligation to notify users in case of a data breach. In this case, Cxense will notify you without undue delay, to enable to you to comply with the 72 hour notification deadline stipulated by the GDPR.

The division of obligations between Cxense and our customers are specified in the Data Processing Addendum to our Master Service Terms.

Updated legal terms and documentation

The GDPR mandates that all data controllers have a binding contract with their data processors and places specific requirements on what this contract must contain.

To support this, Cxense has prepared an updated Data Processing Addendum document to our contracts. The changes made to this document compared to previous contracts are mandatory under the GDPR and must be executed by all our GDPR affected customers by May 25th to maintain compliance.

In addition, Cxense is publishing an updated privacy notice and preparing other supporting documentation regarding our data processing activities.

Technical changes to maintain compliance

Cxense technology is most commonly deployed on our customers’ or their partners’ web sites, using the Cxense “cx.js” javascript tag.

In its default state, the Cxense tag will submit pageview data to the Cxense platform as soon as the page is loaded and immediately submit any DMP data as soon as the script function is invoked on the site. Content recommendation widgets and ads will also be loaded as soon as possible when the call queue is processed or any insertWidget or insertAdSpace calls are made. This constitutes processing of personal data.

Legal basis and implementation impact

For customers who base their processing of personal data on legitimate interests as described in GDPR article 6(1)(f) and consider the entirety of the processing activities and purposes the Cxense to be used for to be within the scope of their legitimate interests, the existing Cxense tag can be used while still complying with the GDPR.

For customers who base their processing of personal data on informed consent as described in GDPR article 6(1)(a), implementation changes will most likely be required on sites where the Cxense Javascript tag is deployed.

To ensure that the Cxense services only processes personal data by consent only, there are broadly speaking two options:

  • Only serve the site or page to users who have given their consent in advance. This could apply to a site where registration and agreement to terms of service is a prerequisite for access to the service, such as an organizational intranet or a subscriber-only section of a news site. Note that this is likely not an acceptable solution in the majority of cases where a site is accessible to the public and can function even if some personal data processing activities, such as personalised advertisements, are avoided.
  • Migrate to the consent-aware version of the Cxense tag, which avoids processing personal data for a given purpose unless a script call has been made to declare that the user has consented to that particular processing.

Depending on the site, its audience, and the nature of personal data submitted to the Cxense platform this choice may require careful consideration of the GDPR’s requirements for a request for consent to be specific about the type of data processing that will be performed and that it be granular, allowing a person to opt in for each distinct purpose.

Legitimate interest or when user consent is given a priority

When the use and processing of personal data is justified by a legitimate interest of the data controller, or when individuals have given consent to data processing before a page is loaded, processing of personal data may happen when the page is loaded with no further input from the individual. In this case the existing mode of operation of the Cxense tag will not infringe on the GDPR.

For sites basing their process in individual informed consent, this would apply when access control and existing agreements ensures that users have already consented to the type of processing performed by Cxense on your behalf. Note that simply having access control and a terms of service agreement click-through may not give sufficient options for users to opt in to specific types of processing. Consult with your legal counsel to determine if this approach is viable.

Process personal data only by consent

Cxense supports these specific types of processing purposes that can be opted in to by a user. Each is identified in the Cxense script tag by a short single-quoted name.

  • ‘pv’ - Page view tracking, DMP event tracking and browsing habit collection to understand a user’s interests and profile.

  • ‘recs’ - Personalisation of content recommendations and suggested content based on user interests and browsing habits.

  • ‘segments’ - Audience segmentation - processing of browsing habits and first party data to include users in specific audience segments.

  • ‘ad’ - Targeting advertising based on browsing habits and audience segmentation.

Note that the latter three purposes depend on the first kind of processing to be applicable - without tracking browsing there will be no data available to base personalisation of content on, nor any data to determine which audience segment(s) a person belongs to, or to target advertisements based on.

Personalisation of content recommendations is not normally considered targeted advertisement, but depending on customer use cases and the content surfaced using recommendations, this may not be the case.

Audience segmentation is commonly used to target advertising, but not always, and so is kept as a separate consent opt-in for technical reasons, but it may not necessarily be a specific data processing purpose that requires its own opt in - the use case for audience segmentation on your site(s) is the determining factor here - personalising the user’s experience based on audience segment membership may not necessarily be considered ads targeting. Unless, of course, the nature of the personalised experience appears to be marketing.

Targeted advertising is a clearly flagged separate data processing purpose in the GDPR. Be careful to separate a request for consent to target advertisements from other opt-in options.

Determining what functionality to enable based on the user’s consent

It is important to understand that the different classes of functionality above do not necessarily correspond directly with your purpose for using their functionality. As we touched upon above, audience segmentation is often, but not always, used for marketing activities. Personalised content recommendations are also sometimes used for marketing purposes - but more often the content surfaced with these is not marketing material.

The purpose of the various data processing functions offered by Cxense is thus determined by you as the data controller and implementer, and that is the important part of the request you must make to your users.

Consult your privacy counsel and consider how you use Cxense services when determining which of these purposes where you must request consent.

Practical application of user opt in

The Cxense tag itself does not request consent directly from the user, as this would lead to a disruptive experience on the site. Rather, the Cxense script exposes a set of new functions to selectively enable functionality for the purposes which a user has opted-in.

The API and behavior changes have been designed to be backwards compatible, such that an unchanged tag continues to work as before. Only by explicitly enabling the consent awareness functionality will the tag avoid processing personal data until consent has been affirmatively given.

Initializing the Cxense tag with Consent requirement awareness is done by declaring an cX as an object with {options: { consent: true }}. Alternatively a function call to requireConsent() can be placed in the call queue, above any other functions.

If there are multiple Cxense tag invocations on the page, we recommend starting all of these invocations with the preamble that enables consent awareness, to avoid having the load order of the tags influence the behavior of the tag.

These are the new functions:

  • requireConsent(): This has the same function as initializing the cX object with the options field mentioned above, and may be used interchangeably, or if the consent functionality should be enabled only after some processing justified by a legal basis other than consent has taken place.
  • isConsentRequired(): Returns true if the Cxense tag is set to be consent-aware.
  • setConsent(types, options): Flags to the Cxense tag that the user has opted-in to particular type(s) of processing, enabling that functionality in the Cxense script. The types of processing a user has opted in to is stored in the browser’s local storage to enable quick resumption of processing in subsequent page views without requiring new setConsent calls. The “types” object may contain fields named ‘pv’, ‘segments’, ‘recs’ and ‘ad’, each with a value of true or false to enable or disable the particular type of operation according to user consent. The options object may contain a ‘runCallQueue’ field, which, if true, will cause cx.js to submit any earlier consent-blocked event data to the Cxense platform.
  • hasConsent(type): returns true if the specific consent is registered in local storage.

As an example a simple consent-aware Cxense tag starts like this:

<script>
var cX = cX || { options: { consent: true }};
cX.callQueue = cX.callQueue || [];
cX.callQueue.push(['setSiteId', '1141829794503140426']);
cX.callQueue.push(['sendPageViewEvent']);
cX.callQueue.push(['invoke', requestConsent]);

The requestConsent function is a function to be implemented by the site and should check if a user consent is already in place with the Cxense tag using hasConsent(type). If it is not already set, then display a Consent request dialog, or if the user is logged in, perhaps check with the site backend if the user has already given consent. If a user consents to a type of processing, invoke the setConsent(type, options) function to enable that functionality.

function requestConsent() {
 if (!cX.hasConsent('pv') && confirm('Do you give consent?')) {   
  cX.setConsent({ 'pv': true }, { runCallQueue: true });
 }
}

What happens if consent is not given?

Page view events

Page view events and DMP events queued in the callQueue before ‘pv’ consent is in place will not be sent to the Cxense platform right away. However, if consent is granted, the queued events will be dispatched if the runCallQueue options is included with the setConsent call in the call queue, like this: setConsent({’pv’: true}, { runCallQueue: true }). If 'pv' consent is not granted, the identity will not be used for recording statistics about the performance of content widgets, even if 'recs' consent is granted.

Audience segmentation

If ‘segment’ consent is not in place, the getUserSegmentIds call will return an empty set of segments. Browsing habit data submitted without segment consent will not be included in audience segment generation.

Personalisation

If ‘recs’ consent is not in place, the user's personal data will not be processed for the purposes of serving personalized content. This means that content widgets will not be personalised, but the API will still serve content recommendations based on non-personal data such as the page context and traffic trends. While this is not currently live in production, it’s planned for delivery in time for the GDPR go-live date. If 'pv' consent is not granted, the identity will not be used for recording statistics about the performance of the content widget.

Targeted advertising

If ‘ad’ consent is not in place, ad space insertion calls will do nothing. Ad spaces will not be inserted.

Data storage options

While the GDPR does not mandate that data is stored only within the EU, moving data to third countries is complex from a legal compliance standpoint. While Cxense has taken steps to ensure that our transfers and processing operations in third countries happen on a sound legal basis, we understand our customers’ compliance concerns and may help to mitigate the perceived risk.

Please contact your Cxense account manager if you wish to discuss these concerns and how Cxense can help you.

Easy compliance with data subject rights

Cxense has prepared technology for dealing with Data Subject Rights in the GDPR to ensure that we can support our customers’ obligation to let individuals access and take their data out and to have their data removed. This process and the internal tools developed to support it are designed to ensure that the compliance deadlines in the GDPR can be consistently met.

The specific data subject right functionality we will offer direct integration for is:

  • Requesting removal of personal data from the Cxense platform. An API to file such a request will be available on api.cxense.com at the /personal/delete endpoint
  • Retrieving a copy of all personal data associated with a device/user identifier from the Cxense platform, in a machine readable format. This API will be published at api.cxense.com/personal/read

These APIs will be documented on the Cxense API documentation site, and are not covered in further detail here.

We will not offer a separate API for rectification, as existing APIs include functionality for updating externally supplied data.

In addition we support clearing personal identifiers from a device through a new function clearIds(), which can be used to ensure that personal data stored in the Cxense platform can not be retrieved using a device’s cookies after a user has logged out.

Was this article helpful?