The 5 most common mistakes in cookie bar settings

One of the most complicated aspects of setting up website analytics is integrating a cookie bar. I’m not referring to legal requirements, but rather technical accuracy. It seems so simple, yet it’s not.

Recently, I’ve come across recurring errors in settings. Below, I’ll describe these errors and how to identify them on a website.

I will not discuss the legal aspects or wording. I will focus on errors that affect the quality of measured data in GA4 or marketing tools.

1. the bar does nothing

The manager ordered the cookie bar to be implemented. And the programmer implemented it. Both then checked that the bar was displayed and happily closed the task. However, no one thought to change the execution of analytical, marketing, or other codes.

The bar is only displayed; the measurement codes continue to run happily. Even without consent. We have all the data, but it violates the law.

How to tell if the cookie bar is not working

The easiest way is to open the developer tools and find the “Cookies” item in the “Applications” tab. After loading the page, the cookie list must be either completely empty or contain only technically necessary cookies (you will probably need a programmer to assess this).

If you are inserting measurement codes directly into the HTML of your website, tell your programmer.

If you use Google Tag Manager for management, study “Consent Mode” or find an analyst.

2. codes do not run after consent is given

Once you get consent, you need to run the tracking codes. Not on the next page. Right away.

If you run them on the second page, you’ll lose all the data about the source of the visit. UTM parameters, document.referrer, gclid, everything. Visits then appear as direct (e.g., direct entry into the browser). Marketing then has nothing to evaluate campaigns based on.

In GTM, tags with built-in consent are usually fine, as they ensure that data is sent after consent is given.

However, tags with “additional consent” tend to be problematic – in this case, you must ensure that they are run after consent is given.

How to tell that codes are not running after consent has been given

Check that the codes are executed after consent is given. Chrome extensions such as Ghostery, or platform-specific extensions such as Meta Pixel Helper, UET Tag Helper, etc., can help you with this.

If you are more technically savvy, you can look in the Developer Tools under the Network tab—here you should see the requests that send the tracking codes.

3. page reload

If cookies, toolbars, and marketing codes are managed by a programmer, they sometimes simplify their work. And when they get consent, instead of running complicated marketing codes, they simply refresh the page—similar to pressing F5. Only then are the marketing codes run and the data sent. Unfortunately, not all of it—when you reload, you lose the “document.referrer” value. This is exactly the value that allows Google Analytics to recognize whether you are coming from another website or, for example, from a search engine. So most visits from referring websites or searches will then fall into the “direct” category. And you definitely don’t want that!

Once you get consent, you need to make sure the tracking codes are activated. Right away. On the same page. If you don’t start tracking right away, you’ll lose essential data for evaluating your marketing.

How to recognize when measurement starts after reloading

Typically, you will see a very high percentage of direct visits in Google Analytics, easily 70% or more. There is also a significant discrepancy between the data from Google Search Console and Google Analytics.

4. you don’t know the opt-in rate and consent rate

Due to consent, you will not be able to measure some of the data. If you want to evaluate the data, you need to know how much is missing. And it could be anywhere between 20 and 80%—depending on how compliant your cookie solution is with all regulations.

You will be interested in two metrics:

  • Opt-in rate – which indicates what percentage of people give you consent. If you don’t know how to calculate the opt-in rate, read the linked article.
  • Consent rate – the proportion of data you have measured with consent. If you send GA4 anonymous pings and store data in BigQuery, you can easily obtain the metric from BigQuery.

If you have data modeling enabled in GA4, the values displayed may be close to reality. However, it is still necessary to evaluate the accuracy of the measurements.

5. inappropriately selected Wait for timeout

Wait for timeout is a mysterious parameter set by some cookie bars. It affects the behavior of Google tags, i.e., GA4 or Google Ads. It tells scripts to wait a while before sending a hit—that consent will come. This setting is necessary if you use asynchronously loaded consents.

The problem is that Google Tags wait for the set time, whether you have consent or not. If you have wait for timeout set on your transaction measurement page, you can easily lose tens of percent of measured transactions.

How to tell if your wait for timeout is set incorrectly

Compare the data share in GA4 (or ideally in BigQuery) with reality. If there is a significant discrepancy (after taking into account the consent rate), this may be the cause.

Legal requirements

If everything is technically in order, you can check whether the bar is also legally compliant. The Office for Personal Data Protection recently published an article summarizing the most common shortcomings of cookie bars.

When checking the cookie bar, I recommend going through all the observations of the ÚOOÚ in addition to the points above.

Not sure if everything is in order?