Google Ads Conversion Tracking for WordPress Forms – TagFlux

1.4.1

• New: conversion value in the dashboard. WooCommerce purchases have reported their order value to Google Ads since 1.3.0, but TagFlux never asked Google for it back, so the dashboard counted sales without saying what they were worth. There is now a “Conversion Value” metric for the period, plus a value column in the breakdowns by form and by campaign.
• New: the server-side conversions card shows the value and currency of each upload. That data was already being sent by the site and returned by the API — it was simply not displayed. Unlike the Google Ads metrics, it appears as soon as the order is uploaded and uses each order’s own currency.
• The value is only shown where it means something: sites that only track form leads see the dashboard exactly as before, with no columns of zeros.

1.4.0

• Fix (privacy): the EU Cookie Law / TP Cookies consent plugin was never detected, because TagFlux looked for the wrong main file. Sites using it were treated as having no consent manager, so the click id cookie was stored even when the visitor had rejected cookies. All nine supported managers are now verified against the packages published on WordPress.org by an automated check.
• New: a public hook so any consent manager can be supported, including custom banners. Declare the visitor’s choice with the tagflux_consent_signals filter in PHP, or call window.tagfluxSetConsent( 'granted' | 'denied' ) from your banner. A real Consent Mode v2 signal always takes precedence, and returned values are validated.
• New: support for the WP Consent API, the WordPress consent standard — read both in the browser and in PHP, so server-side uploads no longer depend on the browser. Requires the wp-consent-api plugin, which most consent managers integrate with.
• New: support for consent managers running in IAB TCF mode, through the standard __tcfapi. No extra plugin needed.
• New: WPConsent (by the WPForms team) is now recognised as a consent manager.
• Fix: forms embedded through a reusable block or a theme block pattern were still invisible to Divi’s detectors, which resolved the reference only in one of the two scan paths.

1.3.1

• Fix: forms embedded through a reusable block or a theme block pattern (wp:block / wp:pattern) were invisible to the tracking script. The page content only stores a reference — not the form itself — so TagFlux concluded the page had no tracked form and never loaded its conversion script: browser-side conversions on those pages were silently lost. Block references are now resolved before the page is scanned, nested patterns included, and in place — so Divi’s position-based form matching keeps the document order. Pages with the form placed directly in the content are untouched.

1.3.0

• New: WooCommerce purchase tracking. Completed orders are sent to Google Ads as PURCHASE conversions with the order value and currency, from your server — the upload fires when the payment completes (including gateway webhooks), not when the buyer lands on the thank-you page. Works with both the classic and the block checkout, and with High-Performance Order Storage (HPOS).
• New: the Google click identifier and the visitor’s consent state are captured into the order itself at checkout time, so a payment confirmed hours later by a webhook still carries the right attribution and the right consent.
• New: a WooCommerce card in the settings screen to create the purchase conversion action in Google Ads with one click. In dual mode the thank-you page fires the browser-side tag with the same transaction ID, so Google deduplicates both paths.
• New: tagflux_conversion_value filter to adjust the reported conversion value per order (both the server-side upload and the browser-side tag use the filtered value).
• Fix: with consent declined, the click identifier now also survives form submissions — the URL-decoration that kept attribution alive across links did not cover form actions, so the add-to-cart step silently dropped the click identifier and cookieless purchases were never attributed.
• Fix: billing phone numbers are validated before being hashed for Enhanced Conversions, matching the form path — junk values are no longer uploaded as identifiers.

1.2.6

• Fix: Ninja Forms conversions were counted twice in dual mode. Ninja Forms submits its own field model instead of the page form, so the shared order ID never reached the server and Google saw two different transactions for the same lead. The order ID now travels through Ninja Forms’ own extra-data channel and both paths deduplicate again.
• New: Complianz support without extra setup. Complianz only emits Google Consent Mode v2 when a Google service is configured in its wizard; without one, the visitor’s choice never reached TagFlux and conversions were uploaded without a real consent signal (no Enhanced Conversions data, ever). TagFlux now also listens to Complianz’s public consent API, so accepting or declining the banner works out of the box. A real Consent Mode v2 signal, when present, always takes precedence.
• New: a settings notice when a consent banner has been active for a week but no consent signal has ever reached the site — the case where a site believes it is measuring consent and is not. The existing “your consent manager does not emit Consent Mode v2” notice now also stands down when the site demonstrably does receive the signal.

1.2.5

• Fix: declining consent after having accepted it now releases the click identifier everywhere — the value already painted in the hidden field, and carried by links clicked afterwards, stops travelling; not just the cookie. A click identifier arriving in the URL of the current request is kept, as it reads nothing from the visitor’s device.
• Fix: forms that appear after the page loads (popups, modals, AJAX tabs) now receive the click identifier and the shared order ID at submit time, so dual-mode conversions keep deduplicating instead of counting the same lead twice.
• New: TagFlux now obeys the Google Consent Mode v2 signal even when the consent banner is not one of the recognised plugins — a custom banner that emits Consent Mode is honoured automatically. ad_storage governs the cookie, the visitor’s choice survives navigation between pages, and region-scoped consent defaults are no longer misread as global.
• New: tagflux_consent_managed filter so custom banners can declare themselves in code, and a settings notice when the detected consent manager does not emit Consent Mode v2 — on those sites the attribution cookie waits for a signal that never arrives, which was working as designed but silently.