Written by Femke van Zelst
During the night of 18th to 19th of February, Clang was updated. This new release contains a number of new standard features, including the RemoveCustomer object and the EncodeCustomer object. These objects are now standard for all Clang users. Considering the GDPR, these are very important and valuable objects to use. In this blog you will find out why.
The RemoveCustomer object lets you easily remove several records from your database simultaneously.
Let’s say you want to know for each of the records that you don’t have valid opt-ins for if they still receive your emails. You can simply build a campaign where you send all these records an email with the question of whether or not they wish to continue receiving your mailing. Does the record still wish this, then they are to click ‘Yes’ in the email. If they do not, they don’t need to do anything. You can then see who, out of all the records that received the email, clicked the ‘Yes’ button. The group that did not open the email can be sent another reminder. If there is still no response, or the mail is not opened, it’s clear these records are no longer interested and do not wish to continue receiving your mailings. By implementing the RemoveCustomer object in your campaign, the records who no longer wish to receive your mailing will automatically be removed from Clang.
The opt-ins of records that have confirmed they wish to continue receiving your emails are now obtained in a valid way. The only thing you need to do is document the date and way in which you obtained the opt-in.
Figure 1: Example flow of the RemoveCustomer object
The object can also be used when customers indicate they wish to be forgotten (the right to erasure/right to be forgotten). When your CRM and Clang are linked, Clang can be signalled as soon as the CRM indicates that a customer needs to be forgotten, and they will be immediately removed from Clang as well. Need help linking your CRM to Clang? Please contact your Project Manager.
The EncodeCustomer object enables you to encrypt customer data in a campaign environment field. The encrypted value can for instance be used to safely forward customer data to an external website. Within the object, it’s possible to select one or several customer or campaign fields. These fields are then consecutively encrypted as a single value. It is also possible to separate fields by using a separator.
The EncodeCustomer object in Clang offers various algorithms for encrypting customer data. It distinguishes two types:
Within the object, several encryptions are offered.
Figure 2: Example flow of EncodeCustomer object
Figure 3: EncodeCustomer object where you can select the fields you wish to encrypt
Figure 4: The hash that is sent along to the landing page
The EncodeCustomer object encrypts customer data. This makes the object very useful in relation to the GDPR. Encrypting customer data has the potential to protect a person’s data and privacy, which is the overarching goal of the GDPR.
The GDPR introduces a new term for encapsulating procedures such as masking data, encrypting and hashing that are all aimed at securing and protecting personal information. This umbrella term is called pseudonymising. The term is defined as follows:
”The processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data is not attributed to an identified or identifiable natural person.”
In practice, this means encrypting or masking data so that, without a decryption key, the data cannot be used to identify a person.
Applying pseudonymisation on personal data can decrease the risks for the data subject and help controllers and processors meet the data protection requirements. As a business, you are also less vulnerable to data leaks when you encrypt sensitive data. And should there be a data leak anyway, informing the data subject is only required if it is likely the breach results in a considerable risk for the rights and freedoms of the natural person.
Recital 34 of the GDPR furthermore dictates that informing a person is not necessary if suitable protective measures have been taken for the personal data, such as encryption. In short: by masking data and applying pseudonymisation, your business will limit the need of informing customers if data is being violated. This keeps your business’s reputation intact.
With these two objects, you are better able to meet the GDPR’s requirements. Do you need any help implementing these objects in your campaign? Please contact your Project Manager.