Iubenda Consent Mode v2 Altering the Website Url

Lately we had a few issues, on a few websites, with the implementation of Iubenda Consent Mode v2 trough Google Tag Manager, using the Iubenda GTM template. I’ve just finished the call with Google’s Tech Rep, after this has escalated internally, and apparently this is something they never documented before.


So, if your implementation of Consent Mode v2 is messing up your page urls, altering the Dom and the HTML itself, you’re not alone, and here’s the solution (and explanation).

On a few websites, we’ve noticed how the implementation of Google Consent Mode v2 Advanced with Iubenda’s Template via GTM, would add a strong url decoration with google analytics parameters throughout page navigation, when consent was manually refused at the consent banner prompt.

This isn’t optimal for a few reasons, mainly these two:

  • UX: if a user refuses consent, and as an answer we start declaring with nonchalance that we are tracking them in the urls, that’s not great.
  • Tracking: what if you have triggers or websites functionalities or UTM that you rely on? All of that gets rewritten or altered.

What’s worst, is that in the case of this website, the Iubenda Template actually altered the website’s HTML! Resulting in this client’s purchase funnel ending up in a 404.

You can see what happens in these screengrabs:

consent mode v2 url passthrough issue
Step 1: the user refuses consent when the banner is prompted

consent mode v2 url passthrough issue 2
Step 2: on next page navigation, the urls are modified adding a visibile concatenation of Google identifiers; these are used to track a session without using cookies, but using the url reading instead.

consent mode v2 url passthrough issue 3
Step 3: this will result in broken funnels and 404’s depending on how your website utilizes urls. What is most interesting, is the presence of this [object RadioNodeList…, which is something extra when we consider the gclid parameter itself, which comes after.

consent mode v2 url passthrough issue 4
STEP 4: the craziest thing, this is not just an url rewriting; it was the actual content of the HTML at the earlier step of navigation that was changed by Iubenda’s template. Google tech people were puzzled by this unencountered behavior, and they are currently investigating this.

The solution

So, this unfortunate situation is caused by the “url passthrough” parameter in the Iubenda configuration tag. In order to solve this, just deselect the “url passthrough” option, and publish your container. Your issue should now be solved.

But what is “url passthrough” anyway? And what about “Ads data redaction”, which can by the way cause a similar issue? Do you need them? Let’s discover this together.

iubenda consent mode v2 url passthrough
Just deselect URL Passthrough like in the example here, and you should be good to go. If that isn’t enough, deactivate also ads data redaction.

In order to understand what is going on, we need to understand how the Iubenda template works. Just a few more words, I promise:

The first part of the template, let us set the consent state for Functionalities, Experience Enhancement, Measurement and Targeting & Advertising, plus the time for the javascritp to wait for the update. In most cases, and surely in the EU area, you must flag these all as denied, as per the regulations of DMA.

The culprits: URL Passthrough and Ads Data Redaction

So, what do URL passthrough and Ads Data redaction do? Essentially the following, and they are not needed by Google Analytics or Google Ads, as long as you have a conversion linker properly set, and you are using auto tagging.

Url Passthrough

This setting allows for cookieless tracking by adding the gclid identifier in the url; technically, it should not alter your website’s html though, and that’s the main issue in our case. However, if you don’t need to use it, just avoid activating it.

Ads Data Redaction

This is used to anonymize user data if you pass them on urls; as an example, sometimes you would have printed the user email, or transaction id, or other potentially or non potentially personal data in the url for your tracking; this is obviously not privacy compliant, and you can use this functionality to hide in the url said parameters.
Again, in most cases you won’t need this either.

As a last piece of the template, we have the cookie solution code, which loads the banner and its functionalities. Remember to only paste in here the right part of the default code, without the callbacks; here’s an example:

Standard example of Iubenda CS Code

<script type="text/javascript">
var _iub = _iub || [];
_iub.csConfiguration = 
{"ccpaAcknowledgeOnDisplay":true,
"ccpaAcknowledgeOnLoad":true,
"ccpaAppliesToEntireUSA":true,
"consentOnContinuedBrowsing":false,
"countryDetection":true,
"enableCcpa":true,
"gdprAppliesGlobally":false,
"lang":"it",
"perPurposeConsent":true,
"siteId":2398592,
"whitelabel":false,
"cookiePolicyId":55062451, 
"banner":{ "acceptButtonDisplay":true,
"backgroundColor":"#FF0000",
"closeButtonDisplay":false,
"customizeButtonDisplay":true,
"logo":null,
"position":"float-top-center",
"rejectButtonDisplay":true }}
;
</script>
<script type="text/javascript" src="//cdn.iubenda.com/cs/ccpa/stub.js"></script>
<script type="text/javascript" src="//cdn.iubenda.com/cs/iubenda_cs.js" charset="UTF-8" async></script>

The right way to implement the code in the Iubenda Template for Consent Mode v2

{"ccpaAcknowledgeOnDisplay":true,
"ccpaAcknowledgeOnLoad":true,
"ccpaAppliesToEntireUSA":true,
"consentOnContinuedBrowsing":false,
"countryDetection":true,
"enableCcpa":true,
"gdprAppliesGlobally":false,
"lang":"it",
"perPurposeConsent":true,
"siteId":2398592,
"whitelabel":false,
"cookiePolicyId":55062451, 
"banner":{ "acceptButtonDisplay":true,
"backgroundColor":"#FF0000",
"closeButtonDisplay":false,
"customizeButtonDisplay":true,
"logo":null,
"position":"float-top-center",
"rejectButtonDisplay":true }}

Google’s statement on the issue

Google’s tech team lead that connected with us, said he never saw this yet in the countless implementations. He has suggested to deactivate url passthrough and ads data redaction, as on Google’s side the only needed factors are for the consent defaults to be set to denied, and for the consent to be updated correctly based on user interaction.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.