fabiodalez

Hi Niharika,

Thank you for your kind words.

“Finally someone understood the need of individual publishers” is exactly the audience I had in mind when I forked, debranded and rewrote this thing: bloggers, small ecommerce stores, niche publishers, the people who need real GDPR / CCPA / IAB TCF compliance without paying a SaaS just to make a cookie banner do its job.

Two practical notes that might unblock your “put on hold” situation:

There is already a built-in Global Vendor List browser inside the plugin. Look for “Vendor List (IAB)” in the FAZ Cookie Manager admin menu (left sidebar). The current IAB TCF v2.3 Global Vendor List ships bundled — around 700+ ad vendors — and the screen lets you filter them by purpose (storage, personalised ads, ad measurement, audience research, etc.), search by name, and bulk-select / deselect. So you don’t have to add them manually one by one. If you only need the most common vendors (Google, Meta, Microsoft, Amazon, Criteo, TikTok, the big SSPs and DSPs your specific monetization stack uses), you can typically get a working setup in two minutes from that screen.

If the IAB GVL still feels like a lot to browse, a quick sanity tip: turn on IAB TCF in Settings only if your ad network actually requires it (Google Ad Manager / AdSense in EEA/UK + many programmatic SSPs do — but a single Google Analytics + Google Ads setup, for instance, can run on plain Google Consent Mode v2 alone, which the plugin emits natively without needing to pick any IAB vendors at all).

Your “auto-scan for ad vendors” idea is genuinely good and I’ve logged it for a future release. The plugin already runs a cookie scanner that finds the domains your site sets cookies on; correlating those domains back to their IAB vendor IDs (e.g. doubleclick.net → Google, vendor 755; facebook.com → Meta, vendor 89; tiktok.com → TikTok, vendor 1397; etc.) is a tractable piece of work and would let the GVL screen pre-tick the vendors a site is actually loading. That’s the feature you’re asking for, and it’s the kind of UX polish individual publishers will benefit from the most.

I won’t promise a date, but it’s on the list with priority because your reason for hitting pause is the right one: a 700-row vendor table is intimidating if you don’t already know which ones apply to you. Closing that gap is on me.

In the meantime — if you do hit anything specific while configuring the plugin for your site (banner styling, blocking a particular tracker, anything), drop a thread under the support tab. I read all of them.

Thanks again. Reviews like this genuinely help the plugin reach more publishers who are in the same situation you were.

— Fabio

Hi Alex, hi Tomas,

Alex — thanks for stepping into the thread. That’s the missing piece. Tomas — Alex’s diagnosis is correct.

A quick note on your conditional, Alex: “if you haven’t changed cookie names AND how the CMP state is saved and updated”. Those are two halves, and on FAZ only the first is violated. The state save/update mechanism is byte-for-byte the same machinery FAZ inherited from CookieYes 3.4.0: same cookie value shape (categories object plus action timestamps plus consent revision), same write path (single setcookie with first-party domain, samesite=Lax, 6-month expiry), same update protocol (the update event fires AFTER setcookie returns and AFTER the in-memory category map flips, so any listener that re-reads the cookie sees consistent state). The Google Consent Mode v2 emit is also identical to the CookieYes 3.4 path — same seven keys, same gtag(‘consent’, ‘update’, {…}) call, same dataLayer order. So Pixel Manager’s runtime expectations against a CookieYes-compatible CMP all hold once it can SEE that the CMP is there. The only thing that’s changed is the surface symbol names: the cookie is fazcookie-consent rather than cookieyes-consent, the JS event is fazcookie_consent_update rather than cookieyes_consent_update, the global accessor is window.getFazConsent rather than window.getCkyConsent.

What does Pixel Manager’s “supported CMP” enrollment process look like? Is it a PR against the Pixel Manager codebase, a docs page entry on sweetcode.com, a form, an email? If a PR is welcome, here is the minimum FAZ-side detection contract I can guarantee will stay stable for the foreseeable future — please tell me if you’d want different or additional probes:

• presence: typeof window.getFazConsent === ‘function’
• cookie name: fazcookie-consent
• cookie value shape: JSON, top-level keys “categories” (object: slug → boolean for necessary/functional/analytics/marketing/performance), “isUserActionCompleted” (boolean), “consentID” (string), “action” (ISO timestamp), “activeLaw” (“gdpr” | “ccpa”)
• update event: document dispatches a CustomEvent named fazcookie_consent_update on every accept / reject / preference change; the event’s detail is the same object getFazConsent() returns
• Google Consent Mode v2: gtag(‘consent’, ‘update’, {…}) is called with all seven standard keys (analytics_storage, ad_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage, security_storage) on every consent transition

I can guarantee semver-stable behaviour on those — any breaking change would be a major version bump with a deprecation cycle. If you let me know the right place to send the patch, I’ll open it within the day. Happy to align the symbol probes you’d use against whatever naming convention reads cleanest in your codebase.

Two related questions while we’re talking, Alex.

First, until either side ships the native detection, my read is that the safest “today” answer for Tomas is your WP Consent API bridge: install the free wp-consent-api plugin, FAZ already auto-loads a wca.js layer that translates fazcookie_consent_update into wp_set_consent() and wp_consent_type_defined calls, and Pixel Manager’s matrix already lists “WP Consent API ✔”. Is there anything I’m missing there that would make that path NOT work on Tomas’s stack? In particular: does Pixel Manager require the WP Consent API call BEFORE the page is fully loaded, or is a post-load update enough to release queued events (the WooCommerce purchase one specifically)?

Second, the Explicit Consent Mode point you raised. Tomas — Alex is right and it’s worth re-running the A/B with that in mind. Pixel Manager keeps tracking blocked until cookies are accepted, by design. If your A/B between Complianz and FAZ ran in fresh incognito windows where you opened the page but did NOT actually click Accept on the banner, Complianz may have appeared to “send tracking” simply because its default consent state was pre-granted, while FAZ correctly defaults to denied. A fair A/B is: open in incognito on both stacks, click Accept All on the banner, complete a test purchase, then check GA4 realtime. Only that path is apples-to-apples.

What Tomas can do right now (without waiting on either side).

1. Install and activate the WP Consent API plugin from ww.wp.xz.cn (no settings page; it just exposes the standard).
2. Leave FAZ Cookie Manager active — no toggle to flip on FAZ side, the bridge auto-loads when WP Consent API is present.
3. Keep Pixel Manager’s Explicit Consent Mode on.
4. Clear any page / object cache, open the site in an incognito window, click ACCEPT ALL on the FAZ banner, complete a test purchase, check GA4 realtime + the Google Tag Assistant.

If conversions still don’t arrive after that — and only then — it would help a lot if you could capture the browser DevTools console right after consent and tell me what you see for:

• window.wp_consent_type (should be “optin” or “optout”)
• wp_has_consent(‘marketing’) (should be true after Accept All)
• the dataLayer entry shape for “consent update” (the seven GCM keys should be present)
• any Pixel Manager-emitted console warnings about CMP detection

If Alex confirms the right channel for the supported-CMPs PR, native detection is the answer and there is nothing else to ship on the FAZ side. If the WP Consent API path turns out to need a small bridge tweak (timing, ordering of calls), I’ll fold that into FAZ 1.16.3 within the next few days. Either way I’ll come back here on this thread once there is something concrete to test.

Thanks both of you.

Hi Tomas,

Thanks for the report. I have a strong working hypothesis about what is happening, but I want to be upfront that I have not been able to reproduce your exact stack (FAZ + Pixel Manager + WooCommerce purchase event end-to-end) on my side, so what follows is informed by the code paths and by the public Pixel Manager documentation rather than by a confirmed reproduction.

What I have verified.

I have checked the FAZ Cookie Manager codebase and already emits a fully-formed Google Consent Mode v2 update on every banner interaction: gtag(‘consent’, ‘update’, {…}) with all seven keys — analytics_storage, ad_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage and security_storage. So the GCM side, in principle, should be giving Google’s tags the right state. You can sanity-check this in your browser after clicking Accept: a dataLayer entry “consent update” with the seven keys should appear.

What I think is happening (hypothesis, not confirmed).

Pixel Manager by SweetCode looks like it does not rely only on the gtag consent calls — based on their documentation it also tries to “detect” which CMP is on the page so it knows the moment consent is granted and can release queued events (the WooCommerce purchase event is the typical case: it fires once at checkout and the CMP-detection bridge has to flip very quickly). Their compatibility matrix on https://sweetcode.com/docs/pmw/consent-management/platforms lists explicit support for a handful of CMPs (Complianz, CookieYes, Cookiebot, Iubenda, Borlabs, etc.) plus a generic “WP Consent API ✔” bridge. FAZ Cookie Manager is not (yet?) in that named list, which I suspect is why your purchase events stopped flowing.

What I would try first.

FAZ Cookie Manager already includes a bridge to the WP Consent API standard. If you install the small free plugin “WP Consent API” (https://ww.wp.xz.cn/plugins/wp-consent-api/, maintained by Rogier Lankhorst — the author of Complianz, ironically), FAZ should detect it on load and start translating its own consent events into the standard wp_set_consent(‘marketing’, ‘allow’) / ‘deny’ calls plus the wp_consent_type_defined event. Because Pixel Manager declares explicit support for the WP Consent API bridge in their matrix, the chain in theory becomes:

1. Visitor accepts cookies on the FAZ banner
2. FAZ emits its internal fazcookie_consent_update event
3. The FAZ bridge translates it into wp_set_consent() calls and the wp_consent_type_defined event
4. Pixel Manager picks up those standard signals and releases the queued WooCommerce purchase event

The reason I think this should work is that all four pieces are present and individually documented.

The reason I am hedging is that I have not driven the full WooCommerce → purchase → Pixel Manager → GA4 path with this combination myself yet, and “should work according to the docs” and “does work on your site” are not the same thing.

Steps to try.

1. Install and activate the WP Consent API plugin from ww.wp.xz.cn (no configuration page, it just exposes the standard).
2. Leave FAZ Cookie Manager active — no setting to flip on FAZ side, the bridge should auto-load when WP Consent API is present.
3. In Pixel Manager, keep Explicit Consent Mode enabled.
4. Clear any page / object cache, open the site in an incognito window, accept cookies, complete a test purchase, then check GA4 realtime and the Google Tag Assistant.

If conversions still do not arrive after that, it would help a lot if you could send the browser DevTools console output captured right after consent — specifically:

• any console error or warning coming from Pixel Manager about CMP detection
• what window.wp_consent_type returns (should be “optin” or “optout”)
• what wp_has_consent(‘marketing’) returns after Accept (should be true)
• the dataLayer entries that fire on Accept and on the purchase confirmation page

With that information I can tell with much more confidence whether the bridge is doing its job, whether Pixel Manager is seeing it, or whether there is a third moving part involved.

A note on the future. Even if the WP Consent API path turns out to work, having to install a second plugin to make the most popular WooCommerce tracking stack happy is not a great default. I have logged this internally as a tracking item: either reaching out to SweetCode to get FAZ added to Pixel Manager’s auto-detection list, or shipping a small compatibility shim on the FAZ side so the detection happens transparently. That would land in a future release.

Thanks again.

Fabio

James, thank you for taking the time to write this in so much detail. The story you describe is exactly the experience that pushed me to build FAZ in the first place, and I made a deliberate choice early on: if it ships, it ships complete. No scan limits, no gated features, no manual cookie data entry.

Glad the cookie policy shortcode clicked for you. A heads-up that the next major release will include a much more complete Cookie Policy Generator, with full company and jurisdiction details, multi-language support, and a richer policy template. The code is already in the repo and will land soon.

Thank you again

Thank you so much!

I’m glad the new workflow solves your problem.

If you have a minute and you feel the plugin deserves it, I’d also really appreciate a review on ww.wp.xz.cn — it helps a lot for visibility and keeps the project alive and maintained.

Thanks again for the support

Quick follow-up: version 1.13.17 is out now on ww.wp.xz.cn and the Necessary category is in the Custom Blocking Rules dropdown.

So your GTM workflow is now this: open Settings, Script Blocker, Custom Rules, add a rule that matches googletagmanager.com (or any other always-on script you need to keep alive), and pick Necessary in the dropdown. From that point on the script loads unconditionally, regardless of consent, and the auto-scanner will not move it back into Analytics on the next run because rules you set explicitly always win over what the scanner detects.

I decided not to ship googletagmanager.com or dataLayer as Necessary out of the box. On many sites the GDPR-cautious choice is to load GTM only after the visitor accepts, and shipping it as Necessary by default would silently override that boundary for installs that did not opt in. With the dropdown change you can pick the trade-off explicitly for your site, which felt like the right line to draw.

Quick follow-up: version 1.13.17 is out now on ww.wp.xz.cn and it carries the fix for the category counters.

After updating, every time the scanner discovers a new cookie, or you create, edit, or delete one by hand, the counters on the left side will refresh right away. Same goes for renaming or deleting a category. I also added a regression test that simulates exactly what you reported, so this specific bug now has a permanent guard against coming back in future versions.

After update I would recommend purging LiteSpeed Cache once so the new behaviour reaches your site immediately. The object cache flush is not strictly required, but does not hurt.

Once the update is in, a fresh scan plus auto-categorisation should show the correct numbers on the left straight away.

Thanks for the framing — this was a real UX gap and you are right that the workaround of deleting GTM rows by hand is lossy because the scanner re-adds them on the next run.

Quick context on what was actually happening, because the backend was further along than the UI suggested. The settings sanitiser already accepted Necessary as a valid category for custom script-blocking rules — the eight built-in blocker templates that ship with the plugin (Cloudflare Turnstile, Gravatar, reCAPTCHA, hCaptcha, Wordfence, WPForms, Ninja Forms reCAPTCHA, WooCommerce Attribution) are stored as Necessary rules and they survive a save without issue. The hole was strictly in the admin JS that builds the dropdown for the Custom Blocking Rules table: that array hardcoded analytics, marketing, functional, performance, and Necessary was silently absent from the picker even though the backend would have persisted it.

In version 1.13.17 (out now) Necessary is in the dropdown. You can mark googletagmanager.com or any other always-on script as Necessary and it loads unconditionally regardless of consent state. The auto-scanner already respects the rule (it categorises only into the categories you have not pre-claimed via custom rules), so a rule that points googletagmanager.com at Necessary will keep being honoured across re-scans rather than being moved back into Analytics. The same applies to gtm.start and the inline GTM bootstrap once you point them at Necessary by URL pattern or handle.

I considered pre-populating googletagmanager.com, gtm.start and dataLayer as Necessary out of the box and decided against it for now — those identifiers genuinely belong in Analytics on many sites (the GDPR-cautious posture is “load GTM only after consent”), and shipping them as Necessary by default would silently override that consent boundary for installs that did not opt into it. The right move is to expose Necessary in the dropdown — which 1.13.17 does — and let each admin pick the trade-off explicitly for their site.

Best,
Fabio