Learning by Building a Consent Management Platform

Please note that the following information is not legal advice or regulatory guidance. Please consult a lawyer and expert to determine the right technical approach to follow government regulations like GDPR and CCPA.

Marketing and data governance have been closely intertwined in recent years. Whether it is a corporate stance on user data privacy or a government regulatory body putting a stop to the abuse of user information, marketers have needed to be aware of data governance more than ever before. It has been unavoidable in my line of work since the introduction of the regulatory policies GDPR in EEA and CCPA/CCPR in California, USA. The ubiquity of consent management platforms (CMP) to manage user privacy on websites and apps has left most marketers with the comfort of someone else policing these policies, and not having to understand how these tools work. Instead of following the herd, I let curiosity get the best of me and built my own CMP to understand how they work.

Research

This process started by reading articles on the major regulations (GDPR, CCPA/CCPR), observing various CMP experiences across different websites, and then researching the CMP solutions available to understand what I would need to consider and how I would execute a solution.

Concerning the disclaimer at the top of the article, the product I created and will walk you through below should not be viewed as something to replicate to adhere to these regulations. While I capture a lot of the functionality that complete CMPs provide, I did not consult a lawyer or expert during this process and I don’t believe managing this on your own is feasible without dedicated resources to monitor and police the changing regulatory landscape. This process was purely for personal research.

Architecting my CMP

For this research, I used my personal website as a test. Since this was a research project, the code is not live on my website. The screenshots below are from running this test locally.

I started my consent manager project with cookie management. Cookies are one of the most commonly used browser methods to store information and the easiest way to store user consent preferences which control how user data is stored and shared. Ironically, cookies are also the main vehicle where businesses are at risk of violating government regulations, by storing and sharing user information with various third-party trackers. For CMPs this is the common method to store user privacy information like their permission choices.

Information like:

• Uniquely identifying the browser, which will have a purpose later on.
• Knowing which government regulation needs to be adhered to based on the user's location
• Understanding the individual cookie policies that a user is accepting and rejecting
  

These requirements led me to create the following cookie storage architecture:

• userId (UUID) = Random UUID stored to identify a browser for storage and auditing purposes.
• cookieConsent (Yes/No) = Approval of all cookies or certain cookies
• functionalCookies (Yes/No) = Approval for necessary cookies. This is defaulted to “true” and never changed. Functional data storage and usage is an exception for all regulations due to their necessity for the website to work
• analyticsCookies (Yes/No) = Approval for data tracked, stored, and shared with analytics providers
• marketingCookies (Yes/No) = Approval for data tracked, stored, and shared with marketing providers
• doNotSellCookies (Yes/No) = Opt-out of data being used for sale
• region (String) = Determines if the user interacted with a GDPR-compliant manager or CCPA/CCPR

Building the CMP

With this cookie architecture, the next step was to build out the consent manager user interface and the backend work that comes with it. The wireframe below captures the considerations I made in this build-out related to the typical flow of a user interacting with my consent manager, and the resulting events happening behind the scenes. The steps beneath the wireframes go into how each part was translated into code.

1. I programmed a prompt modal with copy and consent actions based on the user's location. The user location is detected with an IP address lookup API. These APIs capture the user's device's internet connection IP address and look it up in a database containing IP addresses from around the world to reveal the geographic details. The prompt is only triggered if the user's location is in the EU or California.
2. Depending on the actions a user makes with the consent preferences, I set the appropriate cookies with their boolean values, the user's location based on the prompt region, and a randomly generated ID to identify the device. If the user changes these policy settings at any point, the cookies will be updated based on these selections.

1. Something that can be an afterthought throughout this process because it is not on the front end is the record keeping of user choices in case of audits. This is especially important with GDPR as article 30 specifically calls for records of processing activities. An article that serves to help easily maintain the removal of data processing, sharing, and retention. Given the small volume of visitors to my website and the need for simplicity, I spun up a SQLite DB on my server as a record keeper, inserting a record on the first interaction with the consent modal and adding new records as the user makes changes.

1. At this point, the modal and its storage functionality are in place, and the last piece that needs to be addressed is the compliance component of ensuring that your tracking mechanism is adhering to the users’ selections. I am fortunate to have the simplicity of a personal blog where the only user tracking I do is for analytics. Your website might be very different with the need to take inventory of the user information being tracked and processed, along with your lawyers to understand the categorization, and governance of the items in that inventory. I am using Google Tag Manager for my third-party trackers, so it serves as a data governance layer that can handle the permissions of allowing/blocking these items based on cookie-based trigger rules. As you can see in the diagram below, this setup is much easier to control than the alternative of manually updating trigger rules within my code.

Having taken these steps, I now have a functional, consent management platform. It doesn’t contain a fully exhaustive list of features, but it should be enough for my website and the purpose of my research. It is important to emphasize “should” in the last sentence because as I have sprinkled throughout this article this development work was not architected based on legal or expert advice. I have done significant research on the topic which makes me confident in the steps I have taken to avoid privacy concerns, but even so, I recognize myself as a student in this field and no expert. This means there might be regulatory exposure to my home-built solution that I am not aware of and I would approach this topic differently if I were a business and use a third-party CMP.

Conclusion

Building my own consent management platform (CMP) was an insightful experience that has allowed me to become comfortable with this material and knowledgeable enough to be a part of a conversation about these regulations. As you can tell by my hesitancy in conviction to use my final product for any situation, there are a lot of complexities involved in data privacy compliance. When dealing with compliance it is best to stand on the side of risk and evaluate the cost/benefit of taking this process in-house versus relying on a CMP that has dedicated resources to handle the rapidly changing user privacy regulatory environment.