Consent Manager 2.0.0 Patch 2
- Thread starter DEBTech
- Start date
DEBTech updated Consent Manager (IAB TCF 2.2) with a new update entry:
1.0.4
Read the rest of this update entry...
1.0.4
Read the rest of this update entry...
I have a few questions:
- Is this CMP compatible with TCF 2.3? (https://support.google.com/adsense/answer/9804260?sjid=7473290129075777156-EU)
- Does this CMP therefore integrate Xenforo’s cookie solution (does it accept those cookies as well as third-party cookies and list them correctly?)
- Is this CMP therefore fully compliant with the GDPR in the EU? Has it been verified by a third party?
Hi,
Short answer:
With v1.0 I built my own IAB TCF 2.2/2.3 compatible CMP banner. It worked technically — TC String, Vendor Consents, addtlConsent cookie, Cross-Frame TCF API, Google Consent Mode v2 — everything was implemented and passed validation on external tools like Kukie.io.
The problem in practice:
Despite a technically correct implementation, I and my testers experienced significant problems with Google ad revenue. Ads were served, but often only as non-personalized ads (npa=1 instead of npa=0). Bidding rates were considerably lower than expected.
What I tried:
My finding:
The fundamental problem is: Google's own systems (AdSense, Ad Manager, GPT) trust their own CMP (Google Funding Choices, CMP ID 300) significantly more than any third-party CMP. Even when the TC String is technically identical, fewer bidders participate and revenue stays below expectations with a custom CMP.
This isn't a bug on my end — it's the reality of Google's ecosystem. Other third-party CMPs (Cookiebot, OneTrust) have this problem to varying degrees as well.
What I've built from that (v2.0.0):
I've completely restructured the addon. Instead of delivering my own banner, I now use Google Funding Choices as the banner provider and focus on what Google doesn't offer:
v2.0.0 Patch 1 is being released today and will be available shortly.
Short answer:
With v1.0 I built my own IAB TCF 2.2/2.3 compatible CMP banner. It worked technically — TC String, Vendor Consents, addtlConsent cookie, Cross-Frame TCF API, Google Consent Mode v2 — everything was implemented and passed validation on external tools like Kukie.io.
The problem in practice:
Despite a technically correct implementation, I and my testers experienced significant problems with Google ad revenue. Ads were served, but often only as non-personalized ads (npa=1 instead of npa=0). Bidding rates were considerably lower than expected.
What I tried:
- Expanded TC String to 831 characters with full vendor consent bitfield (1567 vendors)
- Added Disclosed Vendors segment (TCF v2.3 mandatory since Feb 2026)
- Fixed Google Consent Mode v2 timing — consent default BEFORE gtag.js
- Corrected purpose mapping (ad_storage = Purpose 7, not P3+P4)
- addEventListener instead of polling for faster consent signals
- addtlConsent cookie with 381 Google AC vendors
- __tcfapiLocator iframe + postMessage cross-frame handler
- External validation with Kukie.io, Consentik, IAB TCF Decoder, UniConsent
- Comparison with sites using InMobi Choice and other CMPs
My finding:
The fundamental problem is: Google's own systems (AdSense, Ad Manager, GPT) trust their own CMP (Google Funding Choices, CMP ID 300) significantly more than any third-party CMP. Even when the TC String is technically identical, fewer bidders participate and revenue stays below expectations with a custom CMP.
This isn't a bug on my end — it's the reality of Google's ecosystem. Other third-party CMPs (Cookiebot, OneTrust) have this problem to varying degrees as well.
What I've built from that (v2.0.0):
I've completely restructured the addon. Instead of delivering my own banner, I now use Google Funding Choices as the banner provider and focus on what Google doesn't offer:
- Consent Analytics Dashboard — accept rates, device breakdown, referrer stats, trend alerts
- Google AdSense API Integration — revenue directly in the XenForo admin dashboard (today/7d/30d)
- Revenue Forecast — estimated monthly revenue based on current accept rate
- Ad Blocker Detection — detects and counts ad blocker users
- Cookie Scanner — hybrid scan (HTTP + browser JS) with automatic known cookie detection
- Consent Rate Email Alerts — automatic notification when accept rate drops below threshold
- GDPR Compliance Report — CSV export of all consent data for audits
- Google Publisher Tag (GPT) Loader — automatic head injection for Ad Manager users
- Scheduled Re-Consent — automatic renewal every X months (GDPR recommends 12 months)
- User/Page Criteria — controls who sees the banner
v2.0.0 Patch 1 is being released today and will be available shortly.
DEBTech updated Consent Manager with a new update entry:
2.0.0 Patch 1
Read the rest of this update entry...
2.0.0 Patch 1
Read the rest of this update entry...
I updated to the new version. I selected the option to overwrite all files. After accessing the dashboard, I receive the following error message:
Edit: Perhaps you should address the topic of Google OAuth 2.0. What needs to be set up beforehand to use the Google API? How do you create the ID? I think not everyone using Adsende in conjunction with XenForo has dealt with this topic yet.
Thank you for your support.
Code:
XF\Db\Exception: MySQL statement prepare error [1054]: Unknown column 'device_type' in 'SELECT' in src/XF/Db/AbstractStatement.php at line 225
XF\Db\AbstractStatement->getException() in src/XF/Db/Mysqli/Statement.php at line 207
XF\Db\Mysqli\Statement->getException() in src/XF/Db/Mysqli/Statement.php at line 43
XF\Db\Mysqli\Statement->prepare() in src/XF/Db/Mysqli/Statement.php at line 61
XF\Db\Mysqli\Statement->execute() in src/XF/Db/AbstractAdapter.php at line 96
XF\Db\AbstractAdapter->query() in src/XF/Db/AbstractAdapter.php at line 157
XF\Db\AbstractAdapter->fetchAll() in src/addons/DEB/ConsentManager/Admin/Controller/ConsentDashboard.php at line 62
DEB\ConsentManager\Admin\Controller\ConsentDashboard->actionIndex() in src/XF/Mvc/Dispatcher.php at line 362
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 264
XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 121
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 63
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2824
XF\App->run() in src/XF.php at line 814
XF::runApp() in admin.php at line 15Edit: Perhaps you should address the topic of Google OAuth 2.0. What needs to be set up beforehand to use the Google API? How do you create the ID? I think not everyone using Adsende in conjunction with XenForo has dealt with this topic yet.
Thank you for your support.
Last edited:
DEBTech updated Consent Manager with a new update entry:
2.0.0 Patch 2
Read the rest of this update entry...
2.0.0 Patch 2
Read the rest of this update entry...
Okay, thanks for the reply, but how does this cookie solution handle Xenforo cookies? What about third-party cookies? Are they automatically detected and included?
Is it therefore fully GDPR-compliant? It can obviously be useful for very large sites, but the point is that we can’t risk cookies not complying with the privacy policy.
For example, if we used Matomo Analytics, how would it work? Would it automatically add the appropriate cookies and toggles?
The Cookie Scanner automatically detects all cookies on your site, both server side via HTTP headers and browser side via JavaScript cookies. It recognizes your XenForo cookie prefix and matches all XenForo cookies automatically. For third party cookies from Google, ad networks, analytics tools and so on, it uses an integrated database with over 2200 known cookies. If something unknown shows up, it gets flagged so you can check it.
Regarding GDPR: The consent banner comes from Google Funding Choices (CMP ID 300), Google's own IAB registered CMP. It handles everything on the consent side, so TCF 2.2/2.3 strings, purpose based consent and Google Consent Mode v2. My addon doesn't touch the banner at all. It sits behind it and tracks what happens: who accepted, who rejected, on which device, from which referrer and so on. For audits you can export everything as CSV and there's a validator that checks your setup for common issues.
Now the important part about Matomo: This addon does not block or load scripts. It doesn't manage individual cookie toggles. Google Funding Choices collects consent for IAB TCF purposes, and Google Consent Mode v2 controls whether Google's own tags fire, that works automatically. For non Google tools like Matomo, you need to check the consent status yourself. Matomo supports this, you can configure it to respect the analytics_storage signal from Google Consent Mode, or use the __tcfapi that Google FC provides to check if your visitor gave consent before tracking. But that's something you set up on the Matomo side, not in this addon.
To summarize: The addon monitors and reports on consent. Google FC handles the banner and consent collection. Script blocking for third party tools like Matomo needs to be handled by those tools themselves, based on the consent signals that Google FC provides.
Regarding GDPR: The consent banner comes from Google Funding Choices (CMP ID 300), Google's own IAB registered CMP. It handles everything on the consent side, so TCF 2.2/2.3 strings, purpose based consent and Google Consent Mode v2. My addon doesn't touch the banner at all. It sits behind it and tracks what happens: who accepted, who rejected, on which device, from which referrer and so on. For audits you can export everything as CSV and there's a validator that checks your setup for common issues.
Now the important part about Matomo: This addon does not block or load scripts. It doesn't manage individual cookie toggles. Google Funding Choices collects consent for IAB TCF purposes, and Google Consent Mode v2 controls whether Google's own tags fire, that works automatically. For non Google tools like Matomo, you need to check the consent status yourself. Matomo supports this, you can configure it to respect the analytics_storage signal from Google Consent Mode, or use the __tcfapi that Google FC provides to check if your visitor gave consent before tracking. But that's something you set up on the Matomo side, not in this addon.
To summarize: The addon monitors and reports on consent. Google FC handles the banner and consent collection. Script blocking for third party tools like Matomo needs to be handled by those tools themselves, based on the consent signals that Google FC provides.
When I install and activate patch version 2 on a freshly installed XenForo system, I get the following error message. Note: Based on the previous error message, I was using XenForo on a server in my home lab.
Code:
LogicException: Could not find repository 'DEB\ConsentManager\Repository\VendorRepository' for 'DEB\ConsentManager:Vendor' in src/XF/Mvc/Entity/Manager.php at line 296
[LIST=1]
[*]XF\Mvc\Entity\Manager->getRepository() in src/XF/Mvc/Controller.php at line 1068
[*]XF\Mvc\Controller->repository() in src/addons/DEB/ConsentManager/Pub/Controller/Consent.php at line 35
[*]DEB\ConsentManager\Pub\Controller\Consent->actionIndex() in src/XF/Mvc/Dispatcher.php at line 362
[*]XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 264
[*]XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 121
[*]XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 63
[*]XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2824
[*]XF\App->run() in src/XF.php at line 814
[*]XF::runApp() in index.php at line 23
[/LIST]
