GA4’s New Assists View Is Empty Because Your Store Never Sent the Events

What Shipped on May 4

Google built a report to credit the touchpoints before the final click. The report only works if those touchpoints exist in your data.

On May 4, 2026, Google Analytics added the Conversion Attribution Analysis report to the advertising workspace. The report includes an Assisted Conversions (Last Click) view that surfaces the channels, campaigns, and events that engaged a user before the converting click — the touchpoints that traditional last-click attribution ignores entirely.

This isn’t a minor reporting addition. It landed four weeks after the April 2026 attribution restructure that gave every conversion action in GA4 its own independent attribution settings. Before April, attribution was account-wide. After April, a form_submit conversion can use data-driven attribution while a purchase conversion uses last-click, each configured separately. The Conversion Attribution Analysis report is the interface designed to make that per-event flexibility visible.

The report answers a question WooCommerce store owners have asked for years: which marketing channels contributed to sales even when they weren’t the last click? The answer is only as complete as the events in the data stream.

Google Analytics shipped the Conversion Attribution Analysis report on May 4, 2026, with an Assisted Conversions view that surfaces upper-funnel touchpoints contributing to conversions before the final click.

What the Assists View Needs

The Assisted Conversions view reads the event stream between the first visit and the conversion. If that stream is empty, the view is empty.

Attribution analysis works by threading events together into a journey. User arrives from a Meta ad on Monday (page_view). Returns from an email on Wednesday (page_view). Views a product page (view_item). Adds to cart (add_to_cart). Leaves. Comes back from a Google branded search on Friday (page_view). Starts checkout (begin_checkout). Enters payment details (add_payment_info). Purchases (purchase).

Last-click attribution credits only the branded Google search. The Assisted Conversions view credits the Meta ad and the email too — but only because every step of that journey was an event in GA4’s data stream, and every event carried the same client_id and user_id tying them to one person.

Remove the middle events — view_item, add_to_cart, begin_checkout, add_payment_info — and the journey collapses to: page_view Monday, page_view Wednesday, page_view Friday, purchase Friday. The Assists view sees three generic page views and a purchase. It has nothing specific to credit.

Data-driven attribution, now the default model for all new GA4 conversion actions, uses machine learning to distribute credit across touchpoints. The model needs touchpoints to distribute across. Fewer touchpoints means less for the model to learn from and fewer channels getting proper credit for their contribution.

The Enhanced Measurement Gap

GA4 enhanced measurement sends six event types automatically. None of them are ecommerce funnel events.

When a WooCommerce store installs the GA4 tag and turns on enhanced measurement, GA4 auto-collects: page_view, scroll, outbound click, site search, video engagement, and file download. These are the six events GA4 considers universal enough to track without manual configuration.

Notice what’s missing. No view_item. No add_to_cart. No begin_checkout. No add_payment_info. Not even a purchase event — the purchase event requires either manual implementation via gtag.js, Google Tag Manager, or a WooCommerce GA4 plugin like Google’s own “Google for WooCommerce” extension.

Event	Auto-Collected by Enhanced Measurement	Required for Assists View
page_view	Yes	Yes — but too generic to credit a specific funnel stage
scroll	Yes	No — not a conversion-path event
outbound click	Yes	No — tracks exits, not funnel progression
view_item	No	Yes — first product-specific interaction
add_to_cart	No	Yes — intent signal the Assists view credits
begin_checkout	No	Yes — high-intent signal for attribution modelling
add_payment_info	No	Yes — near-conversion signal
purchase	No	Yes — the conversion event itself

The comparison table makes the gap obvious. Every event the Assists view needs to build a meaningful attribution path is absent from enhanced measurement. The store has to send them manually — or not at all.

Most WooCommerce stores install a GA4 plugin that handles the purchase event and maybe add_to_cart. The full recommended ecommerce event set — view_item, view_item_list, select_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase — requires either extensive GTM configuration or a plugin that explicitly maps each WooCommerce hook to each GA4 event. Few plugins do the full set. Fewer still send them with consistent user_id parameters.

You may be interested in: 912 Million Ad Blocker Users Made Client-Side Analytics a Structural Estimate

GA4 enhanced measurement sends page_view, scroll, click, and file_download by default — none of the ecommerce funnel events that the Assists view needs to credit.

The Two-Point Journey Problem

A store with only page_view and purchase in GA4 has a two-point journey. The Assists view has nothing between them to credit.

Consider what the Assists view actually sees for a WooCommerce store running enhanced measurement plus a plugin that sends only the purchase event. The user clicks a Meta ad on Monday. GA4 records a page_view with the Meta campaign parameters. The user comes back from organic search on Wednesday. Another page_view. The user returns from a Google Shopping ad on Friday, views a product, adds it to cart, goes through checkout, and purchases.

GA4 sees: page_view (Monday, Meta), page_view (Wednesday, organic), page_view (Friday, Google Shopping), purchase (Friday, Google Shopping).

The Assists view can credit Meta and organic for assisting the purchase. That part works. But it can’t tell you that the Friday session involved a product view, a cart addition, a checkout start, and a payment entry — because none of those events were sent. The funnel analysis is blind. Drop-off analysis is impossible. The Assists view knows which channels were in the path; it doesn’t know what the user did in each session.

For stores with more than one product category, the missing events make attribution worse, not just incomplete. A user who views a running shoe on Monday from Meta and buys a hiking boot on Friday from Google Shopping isn’t a Meta-assisted sale of hiking boots — it’s two separate purchase intents. Without view_item events carrying product-level detail, the Assists view conflates both sessions into one journey.

You may be interested in: GA4 vs Your WooCommerce Database — A Same-Day Revenue Comparison

The Events Your Store Needs to Send

The complete ecommerce event set that makes the Assists view — and data-driven attribution — work.

Google’s GA4 recommended ecommerce events form a sequence. Each event maps to a WooCommerce action hook:

view_item fires when a product page loads. In WooCommerce, that’s the single-product template. The event should carry item_id, item_name, item_category, price, and currency. This is the first product-specific signal in the funnel.

add_to_cart fires when the “Add to Cart” button is clicked. WooCommerce triggers the woocommerce_add_to_cart action. The event carries the same item parameters plus quantity.

begin_checkout fires when the checkout page loads. WooCommerce triggers woocommerce_before_checkout_form. The event carries the full cart contents with item-level detail.

add_payment_info fires when the user enters payment details. This one is harder to capture client-side because WooCommerce’s checkout flow varies by gateway — Stripe’s payment element, PayPal’s redirect, WooCommerce Payments’ inline form. Server-side capture at the WooCommerce hook level catches this regardless of gateway.

purchase fires when the order is created. WooCommerce triggers woocommerce_thankyou or woocommerce_order_status_processing. The event carries transaction_id, value, currency, tax, shipping, and full item-level detail.

Every event must carry the same client_id and user_id. Without identity consistency, GA4 can’t thread the events into a single journey and the Assists view treats each session as a different person.

WooCommerce stores using Transmute Engine send view_item, add_to_cart, begin_checkout, add_payment_info, and purchase server-side with consistent user identifiers — exactly what the Assists view needs.

The Server-Side Solve

Client-side event tracking fails in the places that matter most. Server-side capture sends the full funnel regardless.

The ecommerce funnel events described above can be sent client-side via gtag.js, Google Tag Manager, or a WooCommerce GA4 plugin. But client-side tracking carries the same structural vulnerabilities that affect every browser-based tag: ad blockers suppress the JavaScript, Safari ITP limits cookie persistence to 7 days for third-party-set cookies, and consent rejection in EU/UK markets prevents the tag from firing entirely.

For the Assists view specifically, client-side failure is worse than it seems. Losing a page_view is bad. Losing the add_to_cart that tied a user to a specific product — the event that would have told the Assists view “this Meta session led to a high-value cart, not just a page view” — is structurally worse. It removes the signal that distinguishes a browsing visit from a buying visit.

Transmute Engine™ captures every ecommerce funnel event at the WooCommerce hook layer — view_item, add_to_cart, begin_checkout, add_payment_info, purchase — and streams them to GA4 via the Measurement Protocol and to BigQuery via the Streaming Insert API. Each event carries the same client_id and user_id stamped server-side. Ad blockers don’t suppress it. ITP doesn’t expire it. Consent rejection doesn’t prevent it. The Assists view gets the full funnel, every session, every user.

GA4 built a report to credit the touchpoints upstream of the final click. The report is waiting for the events. The question is whether your WooCommerce store is sending them.

Key Takeaways

• GA4’s Conversion Attribution Analysis report shipped May 4, 2026: The Assisted Conversions view credits upper-funnel touchpoints that contributed to conversions before the final click — but only if those touchpoints were tracked as events.
• Enhanced measurement doesn’t send ecommerce events: GA4 auto-collects page_view, scroll, and outbound clicks. view_item, add_to_cart, begin_checkout, add_payment_info, and purchase all require manual implementation.
• A two-point journey gives the Assists view nothing to work with: Stores sending only page_view and purchase leave the entire funnel invisible — no product views, no cart signals, no checkout intent.
• Every event needs the same user identity: GA4’s data-driven attribution threads events by client_id and user_id. Without consistent identifiers, each session looks like a different person.
• Server-side capture sends the full funnel reliably: Browser-side tracking loses events to ad blockers, ITP, and consent rejection. Server-side capture at the WooCommerce hook layer delivers every funnel event regardless of browser conditions.

References

• Google Analytics What’s New, Conversion Attribution Analysis report, May 4, 2026
• ALM Corp, “April 2026 GA4 Attribution Restructure Analysis,” April 2026
• Google Analytics Help, “Enhanced measurement events,” updated 2026
• Google Developers, “GA4 recommended ecommerce events reference,” updated 2026
• Google Analytics Help, “About attribution and attribution models in GA4,” updated 2026
• Colorlib, “WooCommerce Statistics 2026: Stores, Revenue and Market Share,” March 2026
• Google Analytics Help, “About data-driven attribution,” updated 2026
• WooCommerce developer documentation, “Action and filter hook reference,” 2026
• Google Developers, “GA4 Measurement Protocol reference,” updated 2026

GA4 built the report. Your store needs to send the events. See how Transmute Engine streams the full WooCommerce funnel to GA4 server-side.