Why did a reader click into all 3 fields of our homepage check form in 3 seconds and never submit it? 7 clicks, 4 flagged dead by PostHog, then 9 minutes 40 seconds at the bottom of the page

Method, stated before the numbers

The reader is the one real external person whose check_form_focused event our visitor instrument lists on the homepage: person 445e98c8, printed as the instrument's 8-character prefix and never as an address. The population is every PostHog event on that person id, lifetime: 29 events, all in one session on one path, 0 events before it and 0 after it. Beside the site's own sensors (a page view, cta_viewed with position form when the form itself is on screen, scroll_depth, a page_engagement beacon carrying visible seconds and the deepest scroll, check_form_focused on the first field a reader focuses, check_step_completed when step 1 is submitted, check_started when a check runs) the table reads PostHog's autocapture clicks and its dead-click series. PostHog's documentation defines that series in one line: "Captures clicks that don't trigger a change to the page" (autocapture docs); each dead-click row names which of the detector's timeouts declared the click dead and how many milliseconds after the click it was judged. PostHog wrote 10 click rows for this session; rows within 50 milliseconds of each other on the same element, or on a field label and the field it forwards to, are one click, which leaves 7. Offsets are seconds from the page view's server timestamp.

Beside the session: the instrument's 30-day see-to-touch line by surface, its step funnel by surface with the typed column that went live on 2026-09-10, its lifetime list of real focus rows, and the engineer's walk of the same form at the same viewport on 2026-09-10 (four fresh browser contexts tagged as our own probe, so the instrument excludes them). The computation is the committed script `content/news/homepage_focus_cut.mjs`; it writes `content/news/homepage-focus-cut-2026-09-10.json` with no IPs, user agents, emails or session ids, and 18 of 18 self-checks pass, including that the session is the instrument's own focus row, that the person has no other event, and that the sensor's first row postdates the session.

The session, click by click: 7 clicks in 24 seconds, then 9 minutes 40 seconds

The form was on the first screen: at 1440×670 it sits 180 pixels from the top of the page, and the cta_viewed beacon with position form landed within a second of the page view. At 3.9 seconds the reader clicked the Pricing link in the top bar and the page jumped to 67%; at 21.8 seconds they clicked Run free check, which scrolls back to the form. At 23.7 seconds they clicked the Business name field; the site's focus event fired at 24.1 seconds. Over the next 2.8 seconds they clicked the form panel between fields, the What you do field and the City or market field, then at 27.4 seconds a line of text in the hero, "Free · no account · 60 seconds", which is not a control. After that: no click at all. Scroll to 90% at 41.3 seconds, 100% at 42.7 seconds, and the visibility counter ran to 580 seconds with the page still at the bottom, until the page-leave at 644.4 seconds.

What PostHog's dead-click detector said about the 7 clicks

4 of the 7 clicks were flagged: Business name field, the form panel (not a field), City or market field, the text "Free · no account · 60 seconds". The two navigation links were not flagged (each moved the page). The click on the What you do field was not flagged either. A dead-click flag on an input says the detector saw no page change it counts inside its window; it does not say whether a key was pressed, because a keystroke into this form changes the field's value and not the document tree the detector watches. The honest reading of the flags is narrower: 3 fields were entered in 2.8 seconds, the last click landed on plain text, and the visible 580 seconds that followed contain no click, no focus and no submit.

What the site's own sensors could and could not say

The focus sensor fires once per page load, on the first field a reader focuses, so the tape carries one focus event for three field clicks. The keystroke sensor, check_form_input, did not exist on 2026-09-09; engineering shipped it on 2026-09-10 as deploy askedabout-iv35x310l (first keystroke per field, once per field per page load, sent by beacon with the field, the placement and the surface) and read its own probe rows back from the homepage and from a /news post at 12:48 UTC. At this read it holds 3 rows, all 3 of them ours, and 0 from a real reader. So for this session, typed or not typed is unknown, and the post says so rather than guessing from the click gaps.

The same form, walked at 1440×670 on 2026-09-10

Engineering walked the homepage form the morning after, in four fresh browser contexts at the reader's 1440×670, tagged as our own probe. With only the name filled, Enter and the button behave the same: the form stays on step 1 and the browser's own bubble, "Please fill out this field.", lands under What you do, the first empty required field. With all three filled, both paths reach step 2, and there the walk found a defect: the email field on step 2 carried autofocus but nothing was focused, because React had re-used step 1's What you do input as step 2's email input and the mount-only autofocus never ran. Fixed the same day (a key per step, deploy askedabout-325vjsz62). The reader above never reached step 2, so the defect did not touch this session; the walk found no defect on the step-1 path they were on.

The site's own lines: 14 saw the homepage form in 30 days, 1 touched it, 0 ran a check

Three real readers have ever focused a check form on this site, all on the Business name field; this is the third and the only one on the homepage. The step funnel is the instrument's own line as it printed on 2026-09-10: 3 focused, 0 typed (the column is one day old), 0 step-1 completions, 0 checks; its read string is "no step-1 completion yet". Real step-1 completions since that sensor was born on 2026-09-01: 0. In the same 30 days the homepage took 26 real arrivals by 22 persons, 13 of them with no referrer, 18 with the form on screen in that session and 1 who focused it: this reader.

What this means for a business that wants to be found by AI engines

• A focus event is not a lead and not a typed field. On this site the free check asks for a name, a trade and a city; a reader entered all three boxes in 2.8 seconds and pressed nothing. Until a first-keystroke sensor sits beside the focus sensor, a "form touch" in your analytics can be a cursor.
• The reader who stays longest is not the one who converts. 580 visible seconds on one page, 100% scrolled, 7 clicks in the first 24 seconds and none after. Dwell time measured the tab, not the decision.
• Dead-click flags name the click that did nothing, not why. Of 4 flags here, one sat on plain hero text and two on inputs the reader had just entered. Read them beside the sequence and the timing, or they read as bugs that are not there: the same form walked green on the step-1 path the morning after.

Limits

• One reader, one session, 29 events. Reported because it is the first real focus on the two-step form and the complete record of it, not because one session generalises.
• Typed or not typed is unknown for this session; the keystroke sensor's first row is 2026-09-10 12:48 UTC. The click gaps are printed, not interpreted as typing speed.
• PostHog's dead-click flags are the detector's timeouts as it reported them; the docs line above is its public definition, and the detector's inner thresholds are not restated here.
• Offsets use PostHog's server timestamps. The cta_viewed beacon carries a server time 0.9 seconds before the page view it belongs to; on client capture time it follows the page view, and the table prints it as the load.
• The reader's city and country are PostHog's GeoIP; the person is the instrument's prefix; the network is not printed.

The next reading, pre-committed

2026-09-15: the pooled step funnel by surface as the instrument prints it (focused · typed · step-1 · checks, real external persons, 30 d), keyed on the check_form_input sensor live from 2026-09-10: the first real row with typed=true and step1=false names the wall inside step 1 (the name box or the button); typed=false on a focused person names the cursor alone; and the 30-d see→touch line by surface against 17 · 2 · 1 / 14 · 1 · 0 / 32 · 3 · 1. Reported as counts, whatever they are.