Pull your Performance Max asset-group report. Pull your WooCommerce Analytics revenue for the same period. If the two numbers do not match, the gap is not a bug in either system — it is the entire reason your campaign is over- or under-spending on the wrong asset group. Performance Max asset-group ROAS is a faithful number, calculated against a biased sample. Smart Bidding optimizes against that sample. WooCommerce settles the actual orders. The reconciliation between the two is the part most stores never run.

How to Run the Three-Number Reconciliation Routine Every Week

Google rolled out expanded Performance Max channel-level reporting in 2026. The visibility upgrade is real — for the first time, PMax surfaces which channel (Search, YouTube, Display, Shopping, Discovery, Gmail) drove which slice of the campaign’s spend. The visibility is genuinely useful. The problem is what the visibility is built on.

Asset-group ROAS is computed from conversions Google’s tracking observed during the campaign’s attribution window. On a typical WooCommerce store, that observation set is the survivor of an eight-hop chain — and somewhere between 20% and 40% of true conversions never make it through.

The Eight-Hop Chain Behind Every PMax Conversion Number

The eight-hop tracking chain is the sequential set of systems a WooCommerce conversion must survive — browser, network, consent state, JS execution, plugin hook, server, payment redirect, ad-platform attribution window — before Smart Bidding ever sees it. Each hop has a typical leak rate. Stack them, and the median WooCommerce store loses a meaningful slice of the conversion universe before any reporting layer sees it.

31.5% of users globally run ad blockers (Statista, 2024) — the first hop. uBlock Origin, AdGuard, Brave Shields, and corporate network filters strip the conversion ping before it leaves the browser. The customer still completed the purchase; Google never sees it.

Add EU consent rejection (the second hop), Safari ITP’s 7-day cookie cap (browser restrictions, third hop), and JavaScript execution failures on slow connections or blocked CDN endpoints (fourth hop). On the merchant side, plugin hook collisions and cart-block migrations kill the on-page conversion event entirely (fifth and sixth hops). Then payment-gateway redirects and attribution-window cutoffs close out the leak (seventh and eighth hops).

What survives is the conversion sample Performance Max sees. What it misses never enters the asset-group ROAS calculation.

You may be interested in: The Eight Hops a WooCommerce Conversion Has to Survive Before Smart Bidding Sees It

Why the Asset-Group ROAS Number Is Faithful but Wrong

An asset group is Performance Max’s unit of audience-and-creative grouping; campaign-level reporting rolls up asset-group-level performance, and Smart Bidding allocates budget across asset groups based on observed ROAS. The math at the asset-group level is correct: spend divided by observed conversion value, averaged across the assets in the group.

The math is wrong only at the level of the question the merchant is asking. The merchant is asking “which asset group is making me the most money.” The number is answering “which asset group produced the highest ratio against the conversions Google could see.”

Those are different questions. If asset group A drives high-value customers who block trackers, and asset group B drives low-value customers who do not, Smart Bidding sees more conversions from B and shifts budget toward B — even though A is more profitable on the merchant’s actual order ledger. The bias is silent. It does not surface in any standard Google Ads report.

The Same Problem Just Got Bigger

Performance Max is not the only campaign type with this issue. Google AI Max for Search hit GA on April 15, 2026, auto-upgrading WooCommerce Dynamic Search Ads from September onward (Seresa coverage, 2026) — meaning the same conversion-sample bias now applies to traditional Search campaigns too. The two changes compound: PMax asset groups optimizing against a leaky sample, and the same Smart Bidding logic now governing what used to be more controllable Search campaigns.

The merchant-side reconciliation routine has gotten harder, not easier. WooCommerce 10.5 quietly replaced real-time analytics imports with 12-hour batches (Seresa coverage, 2026), so the WooCommerce dashboard the merchant uses to compare against PMax is now lagged. The day-of-day reconciliation routine that worked in 2024 does not work in 2026.

The Three-Number Weekly Routine

The reconciliation routine is simple in principle. Pull three numbers for the same period — week-over-week, ideally Monday-to-Sunday — and compare them.

• Number 1: WooCommerce orders by source. Pull from WooCommerce Analytics or directly from the orders table grouped by referrer or UTM source. This is the ground truth — every completed, paid order on your store.
• Number 2: PMax conversions. Pull from Google Ads, filtered to Performance Max campaigns. This is the sample Smart Bidding optimized against during the period.
• Number 3: GA4 source/medium revenue. Pull from GA4 Acquisition reports, filtered to Google Ads as the source. This is the third party in the conversation — neither Google’s bidder view nor your store’s order view.

The delta between Number 1 (WooCommerce) and Number 2 (PMax) is the conversion sample bias. The delta between Number 2 (PMax) and Number 3 (GA4) is the attribution-window mismatch. The delta between Number 1 (WooCommerce) and Number 3 (GA4) is the client-side tracking leak.

If all three numbers are within 5% of each other, the campaign is healthy. If Number 1 is 20-40% larger than Number 2, you have an open denominator problem and Smart Bidding is allocating budget against an incomplete sample.

Closing the Denominator with Offline Conversion Import

The Offline Conversion Import is the Google Ads API path for sending completed-order data back to Google Ads after the fact — the most reliable reconciliation method when the on-page conversion event was missed or stripped. The mechanism is direct: take the conversions WooCommerce recorded, filter to those that came from a Google Ads click (using gclid persisted at landing), and upload them to Google Ads as offline conversion events.

The result is that Smart Bidding’s denominator gets closer to the merchant’s actual order ledger. Asset-group ROAS calculations become more representative of true profitability. Budget shifts are more likely to follow real revenue rather than the conversions that survived the leakiest hops.

The implementation requires three pieces: gclid capture and persistence on the merchant side, an order-completion hook that triggers the offline event upload, and Google Ads API credentials configured with conversion adjustment permissions. None of these are turn-key in WordPress.

You may be interested in: PMax Can Now Show You Where Your Budget Went

Why Server-Side First-Party Tracking Closes the Gap Earlier

Offline Conversion Import is a reconciliation layer. It fixes the denominator after the fact. The deeper fix is preventing the leak in the first place — moving conversion capture from the browser (where it can be blocked, restricted, or stripped) to the server (where it cannot).

The reasoning is structural. The browser is the leakiest hop in the eight-hop chain. Move the conversion event off the browser, and the first three to four hops disappear from the loss equation. What remains — server reliability, payment redirect timing, attribution window — is significantly tighter than the cumulative client-side leak.

Combined with offline import as a backstop, server-side first-party tracking gets the conversion denominator within 2-5% of true revenue. Smart Bidding then optimizes against a sample that actually represents the customer base. Asset-group ROAS becomes a number that means what the merchant thinks it means.

How Seresa’s Stack Fits This

Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures order events from WooCommerce hooks and sends them via API to your Transmute Engine server, which routes them simultaneously to Google Ads enhanced conversions, GA4 Measurement Protocol, Meta CAPI, and BigQuery. The BigQuery stream becomes your independent first-party ledger — the queryable record you compare PMax asset-group ROAS against, week after week, without depending on Google’s view of which conversions Google could see.

Key Takeaways

• PMax asset-group ROAS is faithful, not wrong. The number is calculated correctly from the conversions Google could see — typically 60-80% of true WooCommerce revenue.
• The eight-hop tracking chain leaks 20-40% of conversions. Ad blockers, consent rejection, browser restrictions, plugin failures, and attribution window expiry compound across the chain.
• Run a three-number weekly routine. WooCommerce orders by source, PMax conversions, GA4 source/medium revenue. The deltas between them surface where the leak lives.
• Smart Bidding shifts budget toward the wrong asset group when the denominator is open. High-value customers who block trackers look invisible to the bidder; budget moves to lower-value customers whose conversions survived.
• Server-side first-party tracking plus offline import closes the loop. Server-side prevents the leak; offline import reconciles what slipped through. Together they get the denominator within 2-5% of actual revenue.

Frequently Asked Questions

Pull the three numbers. Reconcile the deltas. Then close the denominator. Start at seresa.io.