Reducing Risk - Part 1: How a CMP is Deployed Matters

When deploying a Consent Management Platform (CMP) on your website, there typically is not much focus or care from vendors or implementation teams on the best way to deploy the CMP code on the website. They just want the banner to show and to be functional. This is because if you are not an expert in privacy, website architecture, Tag Management Systems (TMS), and broader MarTech, it’s not clear how all of these work together to actually load on the page, honor user consent, and collect accurate data. I’m going to break down how these CMPs actually load and function to call out the best way to implement them for both reducing legal risk and increasing data collection accuracy.

Website Loading & Network Resources

Before we dive into how these CMPs operate from a technical perspective, we need to cover how websites work (sorry, I’ll try to be quick). Website features, analytics, personalization, and all other content load by making network requests and typically load asynchronously (unless hard-coded on the page). Browsers typically limit the number of network connections occurring at once, which means different types of resources (content, analytics, legal resources, personalization, etc.) are all fighting for the same limited network resources AND are also event-driven based on page load points or user action.

CMP Loading Behavior

Each CMP typically offers features such as a customized banner with your website styling, specific legal language, language translations for non-native language users, geo-location rules to honor specific laws based on geo-location, just to name a few. What isn’t always obvious is that each of these features is typically deployed independently from a technical perspective, meaning a new code file may need to be downloaded for that feature to be enabled. Below is an example of OneTrust loading on a page and the different network connections it makes to enable each feature:

This means the browser is making around 11 asynchronous network requests to load the banner, determine any customizations for consent based on user location, and any custom logic for your website, all while trying to download content, styling, and other marketing tools at the same time. Why does that matter in the broader scheme?

MarTech & TMS Impacts

To understand the impacts of how the CMP loads and integrates with other technologies, including other MarTech, we need to understand how the TMS typically executes tags. Most tags that run in a TMS run at DOM Ready / </body> (not all, but this helps illustrate a point). This means if the TMS is configured to honor consent for each tag, based on how the consent logic is configured (opt-in vs. opt-out, does the consent value contain a specific value or doesn’t contain a specific value, etc.), it checks for consent at that moment. Depending on how the CMP is deployed, it may still be in the middle of downloading all those files when DOM Ready is hit, which means you may either collect data when you shouldn’t or not collect data when you might be able to. This primarily is a problem on the first page view for a visit due to the lack of caching, but it is still important. This is an even larger problem for tags that fire immediately after the TMS loads on the page since there is an even greater chance the CMP will not be completely configured (and if the CMP is deployed through the TMS, this is almost certainly never ready). This means if you want to have different tracking rules based on where the user is, unless you have a custom data layer framework to queue events (which almost all TMS do not have, stay tuned on a fix for that), the consent governance logic your business uses likely isn't always being followed. Ouch.

CMP Deployment Options

Most CMP vendors allow for their code to be deployed natively in the HTML (hard-coded) or deployed through a TMS. Every CMP allows deployment through a TMS for one reason - it gets their technology deployed faster. This deployment method totally works, especially for getting started quickly to ensure your business starts following privacy laws by having a way to capture user consent. But it introduces timing and reliability issues that are easy to avoid with a different setup. Each have their pros and cons:

Natively:

Pros:

• Typically gets deployed in the <head> of every page and loads before the TMS
• Higher likelihood of initializing all CMP features before most tags are evaluated
• Won’t be blocked from loading if the TMS is blocked by ad blockers

Cons:

• Can take longer to get in the queue of your website development team for initial implementation and for changes
• Can create a website dependency on your CMP files being available from a third-party vendor (if loaded third-party domain synchronously in the <head>)

TMS:

Pros:

• Most TMSs have tag templates for major CMP vendors
• Speed to compliance is quick (can be deployed in minutes)

Cons:

• CMP codes loads after the TMS, so any tags that need to fire immediately likely won’t have proper consent details stored for first-time visitors
• More difficult to ensure privacy laws are being followed based on user location
• Most TMSs do not have a great way to block tags from firing until consent is ready
• If a user has a browser extension installed to block trackers, this will typically block the TMS from loading as well, which means your user never sees a banner

Recommended Deployment Approach

Given that every implementation decision is a tradeoff, my recommendation for the most robust CMP implementation is to deploy the CMP code natively in the <head> of every page of the website. This gives you the best chance of avoiding race conditions with your TMS and tag firing. Also, follow these tips when doing so:

• Make sure the CMP is loaded before the TMS.
• If your website dev team has a long backlog and you cannot get this squeezed in quickly, consider a hybrid approach for the short term:
  • Deploy the CMP through the TMS but wrap loading the base code in logic that checks to see if the base code already exists on the page before you try to load it.
  • Get the CMP code in the queue of your website dev team. Once they go live with the code, the logic above in the TMS will automatically prevent it from loading twice on the page. I love this hack and have used it throughout my career in many different scenarios.

To really make this bullet-proof, the TMS really needs to have a queuing system to prevent firing of tags before consent is ready. But, this isn’t an option with most TMSs out of the box. Stay tuned for a future post that outlines a solution for this.

Summary

Deploying a CMP through a TMS works, but it introduces avoidable timing and dependency issues. Loading the CMP directly as part of the site drastically reduces race conditions and gives you a more consistent point of control for consent and reliable data capture.