Pixel Manager for WooCommerce – Conversion Tracking, Google Ads, GA4, TikTok, Dynamic Remarketing

Changelog

1.68.0

Release date – 14.09.2026

• New: The TikTok, Microsoft Ads, Pinterest, Snapchat, Reddit and OpenAI browser pixels are now part of the free plugin, together with Microsoft Ads Consent Mode. The Conversions API and Events API connections, Advanced Matching, Enhanced Match and Enhanced Conversions for these platforms stay in the Pro version
• New: The new pmw_order_shipping_profit filter adds the shipping economics of an order to the profit margin. The calculation leaves shipping out on both sides, because WooCommerce records what the customer was charged but never what the carrier charged the shop, so shops had to rebuild the whole margin to account for it
• New: With the Marketing value logic set to Profit margin, an alert now names how many recent orders contain a product the plugin knows no cost for, and the new Profit_Margin::order_has_complete_cogs() helper answers that for a single order. Such products count with a cost of zero, so their whole revenue is reported as profit
• New: pmw.trackCustomGoogleAdsConversion() sends a conversion to a conversion action of your own, applying the same marketing consent gate and the same wait for the Google tag as the plugin’s own Google Ads conversions. A hand-written gtag() call sent nothing at all on shops that defer or delay JavaScript
• New: The Abilities API now offers every setting the admin interface offers. Ten were missing, among them the lifetime value calculation, the logger and the server-side tracking toggles, so an AI agent was blind to a part of the plugin a shop owner could see
• Tweak: X (Twitter) now counts as a popular pixel on the Tracking Pixels tab, so it shows under the Popular filter and in the popular group of the pixel list
• Tweak: An opportunity card for a Pro feature now says so on installs that cannot use it and carries the upgrade button, and the Payment Gateway Tracking Accuracy alert names server-side tracking and Automatic Conversion Recovery as the fix for the untracked orders it lists. Both only linked to the documentation before
• Tweak: The Consent Management Platforms card no longer reads “None detected on this site” when it finds no cookie banner plugin. It now says that only platforms installed as a WordPress plugin can be listed there, that a platform loaded as a script works on the shop all the same, and how to confirm that in the browser console
• Tweak: With “Always send server-side events” enabled, the Payment Gateway Tracking Accuracy report stops offering that setting as the fix for orders excluded because the visitor denied all consent categories. It now says those conversions were still sent server-side and only stay out of the report because the report measures the browser, and the order records that too
• Tweak: When the accuracy trend compares two periods, it now names how much of the change comes from orders that left the report because the visitor denied all consent categories, and what the change is with those orders counted as untracked in both periods. A shift in that population moves the average accuracy on its own, without a single additional purchase being measured
• Tweak: A script that takes over the plugin’s pmw object now reports itself through the new pmw:warning:global-replaced event and a running count on pmw.globalGuard, not only as a console warning. The shop that reported this could confirm that the errors had stopped but not how often the race still happened, because its analytics tool records errors and not warnings
• Tweak: The extra order data output on order pages is no longer marked as a Pro setting. The plugin allowed it on the free version everywhere except the settings interface, which locked the toggle
• Tweak: The Pinterest events now carry the product brand and category, on the browser pixel and on the Conversions API. Pinterest lists both among the parameters it wants on a checkout and reads their absence as a coverage gap, which holds its automated bidding back
• Tweak: The direct integrations for Borlabs Cookie and Real Cookie Banner have been removed. Direct support for both was deprecated in 1.41.1, and both still reach the plugin through Google Consent Mode update calls, which the plugin reads like any other consent signal
• Tweak: The HTTP request logging setting is no longer marked as a Pro setting. It sits in the otherwise free logger group, and the plugin allowed it on the free version everywhere except the settings interface
• Fix: Under WooCommerce’s built-in Cost of Goods Sold, a variation that inherits or adds to its parent’s cost is priced with that cost at last. The plugin read a meta field that only exists on order line items, so those variations counted with a cost of zero and their whole revenue was reported as profit
• Fix: Pricing an order no longer writes a WooCommerce “doing it wrong” notice into the log for every line item on shops with the built-in Cost of Goods Sold enabled. The cost was read with the generic meta accessor, which WooCommerce answers from the same getter anyway and warns about on the way
• Fix: The lifetime value calculation on orders now asks for an active Pro license everywhere. Its settings field, the route that schedules a recalculation and the calculation itself did not, so it was reachable on the free version and a Pro shop whose license had lapsed kept recalculating its whole order history
• Fix: The trial card on the dashboard no longer claims that no credit card is required. The 14-day trial does ask for a card at checkout, so the card now says so and that cancelling before the trial ends costs nothing
• Fix: A consent tool in auto-blocking mode, such as Cookiebot, could run the plugin’s configuration line again after the tracking library had started, which replaced the library’s object and silently stopped add-to-cart, product click and checkout tracking. The configuration now merges into that object, and the library restores it if another script replaces it
• Fix: A tracking library that stops starting up part way through now reports it in the console, and through the new pmw:error:init-aborted event, instead of leaving the shop partially tracked without a word. The listener files no longer depend on the load order for the functions they use while they register
• Fix: On shops that run CookieYes, the visitor is no longer treated as having answered the cookie banner before they have. CookieYes writes its consent cookie, and fires its consent update event, on the first page view already, in shapes that carry a consent value but no answer, and reading any of those as a choice skipped the region check, so visitors outside the configured Explicit Consent Regions stayed blocked
• Fix: The Cookiebot and OneTrust consent readers now deny a category their cookie does not name instead of granting it. A OneTrust cookie that carries no consent groups, which OneTrust also writes for its own bookkeeping, is ignored rather than raising an error, and one written before the visitor answered the banner no longer counts as a decision
• Fix: On shops that run OneTrust or CookiePro with its standard cookie categories, the visitor’s choice is read at last. The Pixel Manager only understood the plain group numbers, not the C0001 to C0004 ids OneTrust ships by default, so neither the consent cookie nor the consent change event told it anything
• Fix: A gtag('consent', 'update') issued by a cookie banner itself is no longer stored as the Pixel Manager’s own decision. That record has no expiry and outlived the banner that made it, so a decline kept declining after the banner had forgotten it. Such an update can also no longer deny the necessary category
• Fix: On shops that run Complianz, Complianz’ own Google Consent Mode is switched off while the Pixel Manager’s is active, the same as for Cookiebot. Two consent default blocks on one page compete and the last one wins, so the pixels could run against a default consent state the Pixel Manager never set
• Fix: Requests for the Google Tag Gateway service worker that arrive after the measurement path was changed or removed are now answered with a 410 before WordPress runs its query and renders a 404 page. Browsers send one per visit until the old worker is gone, and on a busy shop each one held a PHP worker for seconds
• Fix: One shopper action that the theme, a funnel builder or WooCommerce itself reports twice is now counted once. Each pass carried its own event ID, so a single product view or add to cart reached Pinterest, Meta and GA4 several times, on the browser pixel and on the server-side API alike
• Fix: A Pro setting submitted through the Abilities API on a site without an active Pro license is now refused instead of saved. It was stored with a note that it would not take effect, which left a configuration the plugin could not act on, while the REST API refused the very same value
• Fix: The remove from cart event fires again on the cart and the mini cart. A cart synced from the server replaced the cart item key map that the remove button is resolved through with a different structure, so the event failed with “Wasn’t able to retrieve a productId”, and an item the map does not list now falls back to the product ID on the remove button itself

1.67.0

Release date – 07.09.2026

• New: The new pmw_fire_parent_view_item_on_variable_products filter fires a view_item with the parent product when a variable product page loads. With variations reported separately, no view_item went out at all until the shopper picked a variation, and WooCommerce preselects none by default, so those page views were unreported
• New: The new pmw_facebook_auto_config filter switches Meta’s automatic configuration off per pixel, which stops Meta’s automatic event detection, its microdata scraping and its SmartSetup instrumentation. The snippet our troubleshooting page documented for this defined a placeholder fbq and stopped the Meta pixel from loading at all
• Tweak: The Meta Event Setup Tool warning and the debug report now name every rule and value extractor by its ID and by the URL it is scoped to. Meta sometimes keeps delivering rules after they were deleted in the Events Manager, and only Meta support can remove those, for which they need those IDs
• Tweak: The debug report now has a Google Tag Gateway section that counts gateway requests which ended in a WordPress 404 that day, and names the last one. Nothing in the plugin could show that gateway traffic was being dropped, which is what made the resulting server load so hard to trace
• Tweak: The Pinterest events now use Pinterest’s own standard event names throughout. Product views move from PageVisit to ViewContent, and starting a checkout is reported as InitiateCheckout instead of Checkout. Expect reported Pinterest Checkout conversions to drop, because checkout starts were previously counted as completed orders
• Tweak: The Freemius section of the debug report now states whether the in-dashboard account page exists, why it does not, and which link the plugin hands out in its place. None of that was visible anywhere, so a shop reporting a dead account link could not be diagnosed from a debug report
• Fix: Purchase tracking no longer ends in a fatal error when WooCommerce cannot resolve the order behind an order line item. That broke the checkout response after the payment had already been captured, so those customers read it as a failed payment and ordered again, which charged them twice
• Fix: On LiteSpeed Cache the Pixel Manager excludes itself from “Load JS Deferred: Delayed”, which held every script back until the visitor clicked or scrolled and lost purchases on the order confirmation page. It also keeps its ?ver cache buster when “Remove Query Strings” is on, so browsers stop replaying a pre-update script that requests chunk files no longer shipped
• Fix: The automatic cache purge after a Pixel Manager update now clears NitroPack, Kinsta and Proxy Cache Purge, which failed silently and left those shops serving the previous release’s tracking library, so it disabled itself and tracked nothing. A cache that cannot be cleared now raises an admin notice, and a stale library names itself in the console
• Fix: pmw.trackCustomFacebookEvent() now honors the visitor’s current marketing consent, the same gate every other Meta event passes. It only checked whether the pixel had loaded at some point, so a custom event fired from a shop’s own snippet still reached Meta after the visitor withdrew consent in the cookie banner
• Fix: A jQuery snippet that fires a Pixel Manager event from a pmwLoad handler no longer sends the page into an endless loop that freezes the browser and floods the server with requests, which our own documented parent view_item snippet did. Legacy jQuery handlers on the lifecycle events also ran twice per page load and now run once
• Fix: The deprecated wpmLoad event again reaches listeners that register after the tracking library has loaded. Printing the deprecation warning also switched off the compatibility dispatch, so a snippet registering from _pmwq or from any late-loading script was warned that the event is deprecated and then never called, while identical code running earlier still worked
• Fix: Requests to the Google Tag Gateway service worker, which Google’s tag registers under the measurement path, are answered by the gateway instead of falling through to a full WordPress 404 page. Every visitor triggered one, which flooded 404 logs and put shops with regular traffic under load they had no way to explain
• Fix: The Google Tag Gateway proxy no longer writes several log lines per tracking request at the info level, which grew a normal shop’s daily log to several megabytes and buried the entries the logger was turned on to find. That detail is now logged at the debug level; warnings and errors are unchanged

1.66.0

Release date – 26.08.2026

• New: The debug report now states whether Meta’s own Conversions API Gateway is connected to the pixel, and which events it mirrors. The Gateway copies every browser event into the server channel from Meta’s side, so it explains a server event count of roughly twice the browser one while being invisible in the WordPress plugin list
• Tweak: Removed the one-time notice that announced the Nova interface on installs that predate it. Nova has been the default since 1.62.0, and the Support tab still offers the switch back to the Classic interface
• Tweak: TikTok for WooCommerce no longer tracks alongside the Pixel Manager when the TikTok pixel is configured here. The plugin offers no setting or filter for it, so its event senders are unhooked, which stops its browser pixel and its Events API events while leaving the catalog sync, the order sync and its settings screen untouched
• Fix: Configurable Composite Products are reported with the price the shopper configured instead of the cheapest possible configuration, so add_to_cart no longer under-reports every upgraded option. The quantity of composites and bundles is now read from the container’s own quantity input rather than from the first component’s
• Fix: The Meta AddPaymentInfo event now reports the cart’s contents, value and currency, on the browser pixel and on the Conversions API; it was sent with no commerce data at all, which is what makes Meta ask for valid price and currency data for the event
• Fix: In explicit consent mode on shops that run Complianz, the pixels are no longer treated as approved before the visitor has answered the cookie banner. Complianz relays each consent category separately through the WP Consent API, and a category missing from such a relay, or a missing consent cookie, was read as consent
• Fix: Google for WooCommerce and Google Analytics for WooCommerce are switched off again when the Pixel Manager tracks Google Ads or Google Analytics. Both plugins decide whether to track earlier than our compatibility filters were registered, so shops running either one alongside the Pixel Manager sent every event twice for logged out visitors
• Fix: Events that other plugins or custom code report to the Pixel Manager, an add_to_cart from a custom button for example, are no longer lost when they arrive while the plugin is still loading; they are held and processed as soon as it is ready. A shipping method reported by both the plugin and a snippet is now counted once
• Fix: The checkout page of shops whose checkout builder also makes WooCommerce report it as the cart page, CheckoutWC in Distraction Free Portal mode for example, is recognized as the checkout again, so begin_checkout and the other checkout page events fire there. The ambiguity is now resolved the way WooCommerce core resolves it
• Fix: Visits from bots and automated browsers are now suppressed from the very first event, instead of only from the first server-side send onwards; the events before that were tracked as regular traffic, and with server-side tracking switched off the whole visit was

1.65.1

Release date – 18.08.2026

• Fix: The license upgrade page shows every license tier again when it is opened in a background tab, which is what a middle click or a cmd/ctrl click produces; the licensing SDK measures the window width once while the page loads, and browsers report zero for a tab that has never been in the foreground
• Tweak: The purchase event of an order that contains a product WooCommerce can no longer resolve, which deleting a product after the order was placed leaves behind, now reports the products that do still exist instead of none at all, and names the skipped line in the debug log; the line items of every pixel are built as defensively

1.65.0

Release date – 17.08.2026

• New: Deposit and partial-payment plugins are now tracked correctly: each sale reports one purchase conversion, for the full amount, when the deposit is paid, and the instalment orders no longer produce additional conversions; supported are Deposits & Partial Payments for WooCommerce (Acowebs) and WooCommerce Deposits (Webtomizer), and the pmw_split_payment_order_role filter classifies orders of other deposit plugins
• New: Site snippets and third party integrations can now use the jQuery-free event API pmw.bus to listen to the Pixel Manager’s events and to dispatch tracking events; every documented jQuery snippet keeps working through a permanent compatibility bridge, and a purchase listener registered after the purchase event has already fired still receives the order
• Tweak: The tracking library has been restructured for the upcoming multi-platform support: the core now runs without jQuery and all WooCommerce specific code lives in a dedicated platform layer, none of which changes what the pixels send; a new snapshot test suite pins the payloads of every pixel and fails the build on any unintended change
• Tweak: On shops that run without pretty permalinks, WooCommerce no longer loads the session, the cart and the customer object for the Pixel Manager’s own REST requests; WooCommerce only recognizes the /wp-json/ form of a REST route, so on those shops every tracking call booted the whole WooCommerce frontend stack and could write an outdated cart back into the session
• Tweak: The cart item data that travels inside the WooCommerce cart fragments is no longer output for user roles that are excluded from tracking, which is the gate the front-end script bundle already followed
• Tweak: The Cart and Checkout blocks are now also tracked at DOM level, alongside the WooCommerce Blocks JavaScript hooks; WooCommerce is migrating its blocks to the Interactivity API, which dispatches no such hooks, so the shipping method, payment method and place order steps keep being reported once that migration reaches them
• Tweak: The Google tag gateway opportunity is now offered to every shop that has a Google tag configured and no measurement path set yet; it used to be shown only on shops detectable behind Cloudflare, which left out every shop on another CDN, while shops without a single Google tag were shown the card anyway
• Tweak: The Google tag gateway log now names the request whose path was rejected; the log line meant to report the original path printed the result of the rejection instead, which is always the same empty value
• Tweak: The purchase confirmation page now resolves the order key from the URL only once per request, and not at all on a standard WooCommerce confirmation URL; the page check, the order loading and the user ID lookup each ran WooCommerce’s order key search, which on the legacy order storage is a full scan of the post meta table
• Fix: With the marketing value logic set to the order subtotal, the conversion value is now correct for orders that carry fee or refund lines: WooCommerce fee lines (gift wrap, cash on delivery, deposit surcharges) are no longer deducted, because the subtotal never contained them, and refunds are deducted by their product share only
• Fix: With the marketing value set to the profit margin, a refund entered as a plain amount instead of per line item is now deducted from the margin; the calculation reversed refunds through the refunded quantity, which such a refund does not record, so the value did not move at all, most visibly in the Google Ads conversion adjustments feed
• Fix: The Google Ads conversion adjustments feed no longer applies a refund twice; the corrected value of a partially refunded order already accounts for the refund, but the feed scaled it down by the refunded share again, so a half refunded order was restated at a quarter of its value
• Fix: The conversion value reported to the ad platforms can no longer be negative; a deposit or instalment order that carries its payment as a fee line and holds no products, and orders whose refunds exceeded the subtotal, used to report a negative value, which the platforms reject or misinterpret
• Fix: Turning the order duplication prevention off, or adding &nodedupe to a confirmation URL for testing, no longer overrides the deliberate tracking suppressions; it now waives the “this order has already been tracked” check and nothing else, so the pmw_conversion_prevention filter, failed, cancelled and refunded orders, and excluded user roles are respected again
• Fix: The cart item script that travels inside the WooCommerce cart fragments now creates the data layer it writes into, so cart updates no longer raise a JavaScript error when a consent tool blocks the data layer script or an HTML optimizer strips it; it is also no longer output twice per mini cart item on themes such as Flatsome
• Fix: Product level events triggered by a third party integration or a site snippet now always carry the shop currency; those events may be triggered with a raw pmwDataLayer.products entry, which holds no currency, and Meta, TikTok, Snapchat, Pinterest, Reddit, Taboola and AdRoll then sent an amount without one, which Meta rejects outright
• Fix: Site snippets and third party integrations that read the consent state inside the command queue (window._pmwq) now work as documented; the queue ran before the consent module had loaded, so pmw.consent did not exist yet and every line after the consent check was skipped, which usually meant the integration’s own event listener was never registered
• Fix: The add_shipping_info event now also fires on checkouts that select the shipping method for the customer instead of waiting for a click, CheckoutWC among them, and on shipping packages that offer a single rate; the trigger was bound to the standard checkout form and to a genuine click, so the shipping stage was missing from the funnel
• Fix: On shops that run the FAZ Cookie Manager, the Pixel Manager’s scripts are now whitelisted on every distribution of the plugin; the whitelist only carried the folder name of the woocommerce.com version, so on the wordpress.org and the Pro version the cookie banner’s script blocker kept the tracking scripts from loading
• Fix: On shops that run Cookie Script, the pixels are no longer treated as approved before the visitor has answered the cookie banner; Cookie Script writes its consent cookie already on the first page view, holding no decision yet, and the mere presence of that cookie was read as full consent, so in explicit consent mode every pixel fired beforehand
• Fix: Consent categories that are not passed to pmw.consent.categories.set() now keep their current value instead of being reset, which the documented consent API and the CMP integrations were never affected by because they always pass all categories
• Fix: The order key that StoreApps Custom Thank You Page puts into the confirmation URL is now also used to load the order, not only to recognize the page as a purchase confirmation; on a URL that carries only that parameter the page was recognized but no purchase was reported
• Fix: Products shown by the Product Collection block are now tracked, and stay tracked when the block re-renders; the block renders without the classic WooCommerce loop hooks, so collections that do not inherit a shop, search or taxonomy query reported no view_item_list and no select_item at all, and its client-side pagination and filters left the products loaded that way untracked
• Fix: Add to cart is now reported for the block add to cart paths that announce a cart change without naming it; the Interactivity API cart store behind the blockified add to cart button and the Add to Cart with Options block names neither product nor quantity, so the Pixel Manager reconciles the two carts and reports the difference
• Fix: A conflicting copy of the Freemius SDK shipped by another plugin or theme can no longer take the shop down with a critical error; the SDK decides which copy is in charge and can return without providing the function the Pixel Manager calls, so the Pixel Manager now stays inactive and points the administrator at the conflict
• Fix: The “Upgrade to Pro”, free trial and account links now lead to a working page on shops without the licensing SDK’s pricing page; the SDK only registers those pages once the shop is connected or a license is active, so before that and after a license expired they produced a “you are not allowed to access this page” error
• Fix: The Google tag gateway serves the Google tag to returning visitors again; it read Google’s “not modified” answer to a cache revalidation as a failure and replied with an error page instead of the script, so from the second visit onwards no Google tag loaded and Google Analytics reported those sessions under “(not set)”

1.64.0

Release date – 29.07.2026

• New: Added the pmw_facebook_pixel_identifiers filter for tracking multiple Facebook (Meta) pixels at the same time; every browser event is sent to all configured pixels
• New: Added a check that detects active Meta Event Setup Tool rules on the Facebook pixel and warns in the opportunities and the debug info, because those point-and-click rules fire additional events without deduplication and mostly without values, which inflates event counts and corrupts purchase values in Meta
• New: Added an “Ask Pixie” chat icon next to most settings, from the pixel IDs and API tokens to the consent and order configuration options, that opens the AI assistant with a ready-to-send question about that setting
• Tweak: The Facebook (Meta) pixel now detects when another script on the site has defined window.fbq before the Pixel Manager loaded it and logs a clear warning in the browser console, because such a script prevents Meta’s standard bootstrap from loading fbevents.js and the browser pixel silently stops tracking
• Tweak: The Pixel Manager now detects when Meta restricts events for a Facebook (Meta) pixel because of its business category (health and wellness, for example) and reports the restricted event names in the browser console and the debug info; Meta silently drops those events both in the browser and on the Conversion API, which looks like a tracking failure
• Tweak: API tokens are now masked in the log; with request logging enabled, credentials that travel in the request URL (Meta and Snapchat access tokens, the GA4 Measurement Protocol API secret) or in an authorization header used to end up in clear text in the WooCommerce log, which is a file that gets shared with support
• Tweak: The “PMW pixels not fired” counter above the WooCommerce order list no longer loads every matching order into memory just to count it; the number now comes from a counting query and is cached for a few minutes, which noticeably speeds up the order list on shops with many orders
• Tweak: The order value calculation no longer looks up the brand and the categories of the same product more than once per request, which reduces the number of database queries on shop, category, cart, and order pages, most visibly on pages that list many products
• Tweak: The notification count next to the Pixel Manager entry in the WooCommerce menu is now cached instead of being recalculated on every single admin page load; calculating it meant loading all opportunity checks, one of which aggregates the tracking accuracy statistics
• Tweak: The notification script and stylesheet are now only loaded on the admin pages that can actually display a Pixel Manager notification (the WordPress dashboard and the Pixel Manager settings), instead of on every admin page
• Tweak: The tracking accuracy database maintenance (creating the table after an update and scheduling the one-time backfill) no longer runs on storefront and checkout requests; until the backfill had finished, every page view asked the Action Scheduler whether it was already queued, which is a database query on the critical path
• Tweak: The tracking accuracy statistics no longer re-check whether their database table exists on …