Your WooCommerce lead-gen form is losing 30-50% of users between when they start filling it out and when they submit it. GA4 cannot tell you which specific field is causing the abandonment, because its default form events fire only on touch and successful submit — every interaction between is invisible. The fix is a focus-and-blur event tracker that streams to BigQuery. One field, one report query, one change. It is typically the highest-ROI optimization on the site, and it does not need session replay.

How Server-Side Event Tracking Surfaces the Killer Field GA4 Cannot See

The starting position is uncomfortable. A contact form, a quote-request form, a consultation booking — every WooCommerce lead-gen surface has the same shape: traffic arrives, the form_start event fires, then a substantial slice of users disappear before form_submit. The drop-off is silent in default analytics. The conversion rate is the only number that surfaces it, and the conversion rate does not tell you why.

Why GA4 Cannot See This

GA4’s form_start event fires when any field on the form is first touched. The form_submit event fires only when the form is successfully submitted (Google Developers, 2026). Between those two moments — which is where every abandonment happens — GA4 captures nothing about the form by default.

The intent of the default events is reasonable. Google designed them for the broad analytics use case of “did people interact with the form at all?” That question gets answered. The harder question — “which field did they leave on?” — does not.

Custom GA4 events can be added to capture field-level focus and blur. The implementation is straightforward in principle: attach JavaScript event listeners to each input element, fire a custom GA4 event on every focus and blur, and reconstruct the drop-off curve from the events. The implementation is also fragile — the events are sent client-side, which means they are stripped by the same ad blockers and consent rejections that strip every other browser ping.

31.5% of users globally run ad blockers — and most session-replay tools (Hotjar, FullStory, Microsoft Clarity) are blocked alongside ad pixels (Statista, 2024). The browser-side custom-event approach loses the same share of data the rest of your tracking stack loses. Server-side capture removes the dependency.

The Focus/Blur Pattern That Works

The cleanest pattern is a thin browser-side capture layer that ships every focus and blur to a server-side endpoint, where the event is logged with field name, form ID, session ID, and timestamp. The browser layer is simple — two event listeners, one fetch call. The server-side endpoint stores the event in a streaming destination (BigQuery, in our case), where the drop-off curve can be aggregated.

The key insight is that you do not need session replay or video capture. Form abandonment is detectable from a single signal: which field did the user last blur before leaving the page without submitting? Aggregate that signal across thousands of sessions and the killer field surfaces immediately.

You may be interested in: WPForms Has 6M Sites and Zero Default Server-Side Conversions

What to Capture on Each Event

The minimum viable event payload is small.

• session_id — your first-party session identifier (not a third-party cookie).
• form_id — which form on which page.
• field_name — the input element’s name attribute (or a stable label).
• event_type — focus, blur, or change.
• timestamp — server-received time.
• page_path — for context.

That is enough to reconstruct every user’s path through the form, identify the last-blurred field for sessions that did not submit, and aggregate the drop-off counts. No PII. No field values. No keystroke timing. Just the structural signal of which field the user gave up on.

Why Session Replay Is the Wrong Tool for This Job

The instinct on hearing “find which form field is killing conversions” is to install Hotjar, FullStory, or Microsoft Clarity. Those tools work — they surface field-level drop-off through video replay and heatmaps. They also create three problems the focus/blur pattern avoids.

The consent surface is bigger. Session replay captures everything on the page — mouse movement, keystrokes (sometimes), every click. Under PECR, that level of capture typically requires explicit consent through a cookie banner. The strictly-necessary exception is harder to argue when you are recording the entire session.

The block rate is higher. Ad blocker lists explicitly target session-replay scripts. The 31.5% baseline becomes worse on the audiences most likely to be on ad blockers: B2B users, technical buyers, and privacy-conscious shoppers. The drop-off detection signal is itself biased toward users who do not block trackers — exactly the users least likely to abandon a form for technical reasons.

The cost is higher. Session replay tools price by recorded session volume. The focus/blur pattern uses your existing analytics infrastructure — a server endpoint and a BigQuery table. The marginal cost per event is fractions of a cent.

The PECR Position

The PECR analysis matters because the pattern lives in the strictly-necessary exception or it lives behind a consent banner. ICO guidance places recording user selections during checkout and functional service flows inside PECR’s strictly-necessary exception (ICO, 2026). The supporting analysis from the Data Protection Network: the strictly-necessary exception covers “recording information or selections the user makes on an online service” (Data Protection Network, 2025).

The argument is direct. Recording which field a user last interacted with — for the purpose of detecting and fixing service quality issues — is recording information the user is making on the service, in service of the user. It is not advertising telemetry. It is not analytics in the broader sense. It is functional drop-off detection scoped to the form the user was actively trying to complete.

The position is not legal advice. A specific PECR review on your own setup is recommended, particularly if your forms collect health, financial, or other sensitive categories — in which case the path itself can become an Article 9 exposure, separate from the field-level capture question.

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

The BigQuery Query That Finds the Killer Field

Once focus/blur events are streaming to BigQuery, the analysis is one query. Group sessions into “submitted” and “abandoned.” For abandoned sessions, find the last-blurred field. Aggregate by field. The field with the highest count is the one to fix first.

The query in plain English: for every session that triggered form_start but never triggered form_submit, find the most recent blur event, group by field name, and order by frequency descending. The top row is the killer. The top three rows are the priority list.

What surfaces is almost always one of three things: a phone number field where the format requirement is unclear, a company-name field on a B2C site, or a free-text question that takes too much effort to answer. Each of these has a known fix — make the field optional, remove it, or replace it with a structured question.

The lift from removing or restructuring the killer field on a typical WooCommerce lead-gen form is in the 15-30% range on conversion rate. The investment is one tracking implementation and one query. The recurring cost is a BigQuery table that holds the focus/blur events at fractions of a cent per thousand events.

Why a First-Party Server Pipeline Is the Cleaner Foundation

The pattern works on any server-side endpoint that can write to BigQuery. The reasons to run it on a first-party subdomain — instead of a third-party tag manager or analytics tool — are the same as for any other tracking signal: ad blockers do not block first-party domains, browser cookie restrictions do not apply to same-site requests, and the data does not transit a third-party processor that needs its own PECR analysis.

The focus/blur events become one more event type on an event pipeline that is already routing purchase, page_view, and add_to_cart events. The infrastructure is shared. The marginal complexity of adding form-field telemetry is small.

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 form events from the WooCommerce frontend — including custom focus and blur events from any lead-gen form — and sends them via API to your Transmute Engine server, which streams them to BigQuery alongside your purchase and page_view events. The drop-off detection query then runs against your existing first-party data warehouse, with no third-party session-replay tool involved.

Key Takeaways

• WooCommerce lead-gen forms typically lose 30-50% of users between form_start and form_submit. GA4 cannot see which field caused the abandonment because its default events fire only on touch and successful submit.
• The fix is a focus/blur event tracker. Capture every focus and blur on every field. Stream server-side to BigQuery. Aggregate the last-blurred field for sessions that did not submit.
• Session replay is the wrong tool for this job. Higher consent surface, higher block rate, higher cost. The focus/blur pattern delivers the same insight with cleaner tracking-resilience and consent profiles.
• ICO places functional in-form telemetry inside PECR’s strictly-necessary exception. Recording user selections for the user’s own service quality plausibly does not require a consent banner — though a specific PECR review on your setup is recommended.
• One field, one query, one change. The killer field surfaces immediately from the BigQuery aggregation. The lift from fixing it is typically 15-30% on form conversion rate.

Frequently Asked Questions

Wire the focus/blur events. Stream to BigQuery. Run the aggregation. Fix the field. Start at seresa.io.