Consent management platforms often offer two configuration options: automatic and manual. How do they differ, and which one should you choose?
Automatic configuration
In the automatic configuration, the CMP’s bot scans the site and identifies the scripts responsible for setting individual cookies.
Based on this information, the CMP script embedded in the page code holds back the execution of scripts associated with cookies that haven’t been marked as necessary — until the appropriate consent is given.
To make this possible, the CMP script runs synchronously as the first script on every page and modifies the behavior of the scripts that would run after it.
Manual configuration
In the manual configuration, every script whose execution we want to make conditional on consent has to be manually marked with an appropriate attribute on every page. Depending on the platform, this condition can differ — it may take the form of, say, data-cookieconsent=”statistics, marketing”. It causes the script to be blocked until the appropriate consent is obtained.
This may sound like tedious work, but if you use Google Tag Manager (GTM) and your CMP provides a GTM integration template, manual configuration simply means adding the appropriate “additional consent check” in the settings of each tag in GTM.
For Google tags using advanced consent mode, choose the “No additional consent required” option or leave “Not set”. These two options behave identically — it’s merely a way of marking whether a given tag has been reviewed for consent (which can help keep your GTM tidy).
Bear in mind, though, that GTM won’t do everything for us. If the site contains embedded content, e.g. YouTube videos, you also need to manually mark that content in the page code so it is properly blocked until consent is given, with a message displayed in its place explaining that additional consent is required to access it — as described in this article.
If we set up consent management by placing the CMP tag in Google Tag Manager (GTM), that is a manual configuration.
Pros and cons of automatic configuration
The indisputable advantage of the automatic configuration is — at least in theory — its simplicity. Just add the right script to the site and you’re done.
The convenience of the automatic configuration can sometimes prove illusory.
First of all, script blocking in the automatic configuration depends on each cookie being classified correctly. If we trust the CMP’s default settings, or misclassify some of the cookies ourselves (and there can sometimes be dozens or more), it may turn out that certain scripts run without the required consent — or that we block functions essential for the site to work properly.
Unintended automatic blocking of essential scripts can be prevented by manually marking, in the page code, those code fragments that are necessary for the site to work, so that the automatic blocker ignores them (such a marker may look like, e.g., data-cookieconsent=”ignore”).
Also remember that the cookie scan doesn’t happen in real time, so newly added scripts may not be properly blocked until the next scan.
When changing the site and installing new tracking scripts in the future, you’ll also need to remember to classify the cookies appropriately, or check that the default classification is correct.
Automatic cookie blocking requires the CMP script to run synchronously as the first script on every page, which can adversely affect page load speed.
For embedded content (e.g. YouTube videos) that uses cookies requiring consent, the automatic blocker will stop that content from displaying, but we have no control over how this affects the page layout. It may turn out that empty spaces appear in its place, or that elements referenced by the page content are simply missing — which can leave users confused.
The automatic configuration therefore carries the risk not only of incorrect consent management, but also of slower page loads, user-visible errors, or even blocking of essential site functions. Making the site resilient to such errors, in turn, may prove more labor-intensive than configuring the scripts manually in GTM.
Pros and cons of manual configuration
With the manual configuration, we have to mark each script ourselves. Of course, mistakes can happen in this process too. However, there are usually fewer scripts than cookies — a single script, e.g. a Google tag, can generate several different cookies. So in the manual configuration there are far fewer scripts (rather than cookies) to classify.
There is also more control over scripts than over cookies. We add scripts to the site ourselves, and they shouldn’t appear unexpectedly. On the other hand, script vendors won’t necessarily warn us about introducing a new cookie generated by a given script, or replacing existing cookies with others — which can mean new, unclassified cookies appearing on the site. That in turn can make the automatic blocker misbehave — until the new cookies are correctly classified.
Admittedly, in practice there can be cases where developers fail to coordinate newly introduced technology with the people responsible for the consent management configuration, and new scripts generating unknown cookies may suddenly appear in the page code (outside GTM) — but these situations are much rarer, and those files will usually (though not always) be necessary for the site to work.
And remember that in the manual configuration, cookie classification is purely informational and has no effect on script blocking. So the risk that such changes affect how the site works, or cause scripts to run without the appropriate consent, is much smaller in manual mode.
Manual configuration via GTM also allows tracking and consent management scripts to run asynchronously, so the CMP’s impact on page load speed is much smaller.
Automatic cookie blocking and GTM tags at the same time?
Can you use a CMP in automatic cookie-blocking mode and simultaneously use tags placed in Google Tag Manager?
It’s entirely possible, but it requires adding the CMP script to the page code as the first script to run synchronously on the page (right after the <head> tag). The CMP tag added to GTM should be paused, or its trigger removed, so it doesn’t fire from GTM.
Moreover, GTM itself must be marked in the page code with the parameter that makes the automatic blocker ignore it (e.g. data-cookieconsent=”ignore”). GTM will then manage the tags it contains according to the consents given, while the remaining scripts are controlled by the automatic blocker. Otherwise, the CMP may block GTM entirely.
Some platforms describe this setup (automatic blocking + GTM) as the “best of both worlds”, but keep in mind that it also combines the risks inherent in each of the two solutions.
In some situations — if for various reasons some tracking scripts (requiring consent) must remain in the page code — placing the CMP code in the page code (rather than in GTM) will be advisable. One reason is the need to control the order in which scripts run (scripts in the page code could load faster than a consent management tag placed in GTM). Some ad blockers and privacy features block GTM, which could cause scripts in the page code to run without consent if the CMP were launched from GTM. Even so, in such situations it’s still worth checking whether manual mode can be used — given the automatic mode’s impact on page load time.
Which solution is best?
There is no single best solution for every website. Based on experience implementing CMPs and consent mode, however, it’s fair to say that the most reliable option is manual configuration using GTM.
It’s not the only way to implement things correctly, and it won’t always be the simplest, but it appears to be the most universal, carries the least risk to the site’s proper functioning, and gives much more control over the process than the automatic configuration.
Using the GTM integration also radically simplifies implementing consent mode and any future updates to it.
