WooCommerce Pixel Manager for WooCommerce

Versión 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 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: 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
• New: Added Klaviyo as a new tracking pixel (Pro, beta). With the Klaviyo plugin installed, the Pixel Manager takes over its onsite tracking, gated on marketing consent and with a Started Checkout that works on custom checkouts, and adds the cart, collection, search and checkout step events the plugin never sends, while the plugin keeps handling orders, catalog and profile sync, forms and list consent. Every event lands on the shop's existing Klaviyo metrics. Without the plugin, the Events API reports purchases and refunds server-side (Pro)
• Fix: The filters that carry an order now always receive the WooCommerce order on the server-side purchase path too. Since 1.65.0 that path handed them the plugin's internal order object, which fatally ended the checkout request for a filter that type-hints `WC_Order`, and silently did nothing for one that checks `instanceof WC_Order`, which our own documentation recommends (Pro)
• Fix: A subscription renewal is recognised as one again on the server-side purchase path, so the renewal opt-outs take effect there. Since 1.65.0 that path handed WooCommerce Subscriptions the plugin's internal order object, which it cannot resolve, so shops that had switched renewal tracking off still saw every renewal reported to Meta as a purchase (Pro)
• Fix: The subscription renewal opt-outs now hold for Google Analytics 4, refunds included. `pmw_google_analytics_subscription_renewal_tracking` and the global `pmw_subscription_renewal_tracking` only gated the dedicated renewal handler, while the renewal reached Google Analytics through the regular purchase path all the same, so switching them off changed nothing (Pro)
• Fix: `pmw_subscription_renewal_tracking` now switches subscription renewal tracking off for every platform, as documented. Only Meta and Google Analytics read it, so renewals kept going to Google Ads, TikTok, Pinterest, Snapchat, Reddit, OpenAI, Nextdoor, Microsoft Advertising and Mixpanel, and a manually paid renewal still fired the browser pixels (Pro)
• Fix: Deposit and instalment orders are no longer reported as sales of their own by the server-side purchase events. The same internal order object stopped the split-payment classification from recognising them since 1.65.0, so every instalment counted as an order on top of the sale already reported from the parent (Pro)
• Fix: The customer identifier sent to Meta, Pinterest, Snapchat, Microsoft Advertising and Nextdoor now comes from the order's customer, not from whoever made the request, which is nobody on a payment webhook or a scheduled run, so those orders shared one identifier. Pinterest also accepts the hashed email address for a guest (Pro)
• Tweak: The Click ID Capture Quality section of the debug report now breaks the scanned orders down by what created them, and names how many of the orders that fired no browser pixel were never storefront orders to begin with. Orders written by an integration, placed in the admin or renewed on a subscription have no browser behind them, so counting them made a healthy shop look like its browser tracking had failed (Pro)
• Fix: The `pmw_send_all_s2s_requests_blocking` filter takes effect again. Since 1.42.6 the HTTP request class read the logger setting directly, so there was no way to make the server-side requests wait for the platform responses while debugging without switching the HTTP request logger on (Pro)
• Fix: Triple Whale was told about the same Contact twice on every purchase. The pixel reports a known customer when it loads and the login event reports the same identity again, and the two now share one guard, so the identity goes out once per session (Pro)
• Fix: A guest checkout no longer reports a login on the order confirmation page. That page carries the order's customer so the purchase keeps the buyer's identifiers, and the login event read that as the visitor being signed in, so Google Ads, Google Analytics, Meta, Snapchat, TikTok and Triple Whale were told about a login that never happened (Pro)