dany897

Hi Lee,

after a deep analysis of the plugin source code, we have identified multiple consent mode issues. Here is a complete report.

Bug 1 — Fixed in our local copy
File: consent-management.9d45b6cb.chunk.min.js (source: cmps/iubenda.mjs)

In the getConsent() function, the fallback operator uses ?? true instead of ?? false for statistics, marketing and preferences:

statistics: consent.purposes['4'] ?? true,
marketing:  consent.purposes['5'] ?? true,
preferences: consent.purposes['2'] ?? true,

When a user accepts only necessary cookies (purpose 1), purposes 2, 4 and 5 are absent from the iubenda cookie. The ?? true fallback causes them to be treated as granted, leading to incorrect consent signals.

Bug 2 — Fixed in our local copy
File: consent-api.c33d5439.chunk.min.js (source: consent/consent-api.mjs)

In processExternalGcmConsentUpdate_experimental, the preferences value is calculated as:

preferences: (functionality_storage === 'granted') || (personalization_storage === 'granted')

The || operator means that if either signal is granted, preferences becomes true. Since iubenda sends both functionality_storage: granted and personalization_storage: granted for functional-only consent, this causes preferences: true even when the user has not consented to personalization.

Bug 3 — Fixed in our local copy
File: pixel-google.17caa9f5.chunk.min.js

In both loadGoogle and updateGoogleConsentMode, personalization_storage is mapped to the preferences category:

personalization_storage: preferences ? "granted" : "denied"

Per Google’s specification, personalization_storage relates to ad personalization and should be mapped to marketing, not preferences. The current mapping causes personalization_storage to be set to granted whenever the user accepts functional cookies, which is incorrect.

Bug 4
File: pixel-google.17caa9f5.chunk.min.js

When a returning user has previously given consent, loadGoogle reads the cached consent and calls:

gtag("consent", "default", { ad_storage: "granted", analytics_storage: "granted", ... })

The consent default should always be set to denied for all signals, regardless of previously saved consent. The saved consent should then be applied via a subsequent consent update call. The current behavior collapses default and update into one, which is not compliant with Google’s Advanced Consent Mode specification.

Bug 5

When a user denies consent and the page reloads, Pixel Manager correctly reads the iubenda cookie and sets the consent default to denied. However, it never fires a gtag('consent', 'update') call in this scenario, because no CMP click event occurs during the reloaded session. As a result, the “Updated State” column in consent mode inspection tools shows unknown instead of denied.

We have applied local fixes for bugs 1, 2 and 3 by editing the compiled files directly. These are temporary workarounds and will be lost on the next plugin update. We kindly ask you to address all five issues in the next release.

Best regards,

Hi, news?

Hello, even after deactivating the Pixelyousite plugin, the issue persists.
The problem occurs when functional cookies are enabled. Upon refreshing the page, the functional storage cookies are correct, while the personalization storage cookies are activated abnormally. In the default state they are accepted, whereas the “update state” cookies are correctly blocked. Why are the personalization storage cookies activated by default?
With the Pixel Manager plugin deactivated, the issue does not occur.