Marfeel CMP: A Frontend Development Odyssey in the Realm of GDPR
Written by Gianmarco | Product Frontend Developer
Let’s be real.
From 1 to 10, how sick are you of the dozens of “We value your privacy” pop-ups you encounter day after day as you’re striving to, say, read some news on any website?
And, on the same scale, how much did your awareness increase in regards to how your personal data is managed within this or that website, since this bunch of pixels started to get in the way of you and the content you want to access?
While you ponder these questions, you may know that — as of May 25 — publishers, advertisers, and the whole ecosystem of businesses which make direct or indirect use of personal data have been forced to dig deep into the plot of the European General Data Protection Regulation.
Now, compliance is the key aspect also for the technical development of software solutions (Consent Management Platforms or CMP) to gather the consent of the users in order to handle their personal data on the web. The issue is that to be effective and law-compliant, a CMP should meet a set of requirements which can be hard to combine: functional completeness, informational completeness, and ease of interaction.
And here is where the odyssey of frontend development starts.
Just a pop-up? The ingredients of an impossible recipe.
A Consent Management Platform represents the middleman between a user and the proposer of web-content of some sort who may make use of personal information directly (e.g. sampling data from a newsletter subscription) or indirectly (e.g. selling data to third-party vendors for monetization purposes). Its main functional goals are two and user-centric:
- Having the users know how such data could be used while consuming or interacting with the contents of a website, in terms of well-defined purposes and vendors who endorse them.
- Getting the explicit approval or rejection from the users to actually use that data.
From a technical standpoint, such goals are achieved through the development of a stand-alone software item which mainly relies on frontend technology and endorses characteristics that are common to all the CMP’s.
To start with, all the CMP’s expose a common core JS API which is built on top of the IAB Transparency and Consent Framework JS specification. As users express their preferences through the CMP’s UI, this gets encoded into a consent string that will then be accessible by web-content providers and vendors through the public API to know how to behave in terms of advertisement targeting, data tracking, etc.
Speaking of UI and UX, GDPR-compliance is a mission that can offer some nightmares: A CMP needs to expose the five official purposes for which personal data will be used — allowing the user to individually choose which ones to give their consent to — along with the continuously updated list of vendors who endorse some or all of them. In other words, a lot of informational content for the user’s own good, whose importance is nevertheless crucial for the good of all the parties involved.
All of these ingredients to be wisely mixed up with the by now all-too-common development best practices of UI/UX responsiveness, a lightweight logical flow, and some additional features to monitor the behavior of the software itself.
It all boils down to speed and KISS
As we’ve now ventured through the waves of a rough sea, here’s the seemingly impossible equation to keep the ship en-route:
Effectiveness = Ease of use + Completeness + Compliance
Before developing our in-house solution, we learned some behavioral and technical lessons by using other platforms that were renowned in the market. What we observed is that even though GDPR raised some awareness for users, the tendency is to look at the CMP either as an annoying and engagement-blocking wall or as a scary monster from which to escape.
A CMP could be perfectly compliant, informationally exhaustive and even user-friendly, and yet fail to be effective. How so? The more a user comes closer to consuming the content they look for on the web — with all the possible setbacks of loading times and external distractions — the more the CMP results as an uninvited guest.
How to remedy to this lose-lose situation? Simply, the answer is speed.
The sooner and faster the piece of software loads, the more effective it will be for user-engagement. And here is where the problem becomes evident: many renowned platforms on the market simply are too heavy in terms of file size.
Sure you may think that constraining the size of the CMP may come hand in hand with the downfall of limiting its features and customizability. This is not the case, and specifically for the purpose of compliance, which enforces a clear and KISS-like logical flow where the crucial information can be served more and more in-depth on demand.
Our CMP, tools, and KISS-flow
The JS scene by now proposes plenty of tools and frameworks to develop web-applications.
And as the stress is on the file size and the action flow of the final product, the choice has fallen on a promising library whose main focus is performance: PreactJS.
As you may guess, PreactJS appears as (but it is not — )a shrunk-down in size version of the famous Facebook library ReactJS. Just like its big brother, it ships the same ES6 component-based architectural style and the same core syntax (props and basic state handling) and templating features (JSX/VDOM). One of the essential differences which explains the extremely reduced size is the absence of some core and heavy-weight ReactJS functionalities: PropTypes, Children, and Synthetic Events.
But at the end of the day, the dev-flow of a CMP simply needs to combine 2 basic parts: the core GDPR-compliant JS functionalities with UI visual elements like text, buttons/toggles, and long lists.
All of this is organized into 3 views for on-demand information serving:
- A welcome view for overall approval
- A purposes view to toggle consent preferences
- A vendors’ list view for in-depth reading about each vendor’s intent of use of the user’s personal data.
What about UI styling? It is well-known how CSS styling of HTML components may affect the final file size, but certainly, we wouldn’t want to fail on the goal of user-engagement. Here is where the performance CSS-in-JS postprocessor nanoCSS comes in. Its main prerogative? Styles caching and CSS per-component optimization without sacrificing expressivity.
With this in mind, PreactJS and nanoCSS have proven themselves to be fast and modern development tools in their very nature. But did we make a good choice for the goal of speed and, hence, of file size constraint? You bet. We managed to achieve a currently unmatched final bundle size of 19.8kB (served gzipped) which translates into just a 70kB file size. This while being IAB approved, publically available, and not sacrificing any essential requirement for GDPR compliance.
