A form collects visitor details before Submit is clicked

Understand the capability before testing your form

MDN's documentation of the input event establishes the technical fact: an input event can fire whenever a field's value changes, which is before and independent of any form submission. A script listening to those events can read a partial email address, a half-typed name, or an abandoned message. Some form, analytics, and abandonment-recovery tools are built on exactly this capability.

Capability is not evidence about your site. The goal of the test is to replace a vague worry with a timeline: which field, at which event, transmitted what, to which destination. Until that timeline exists, you have a hypothesis, not a finding, and you should not yet change wording or disable scripts.

Run a controlled observation with synthetic data

Have an authorized technical person open the live form in a browser with developer tools, use dummy values that identify the test (a synthetic name and an obviously test address), and watch the network panel and script activity while typing, tabbing out of fields, closing the page without submitting, and submitting a separate test entry. Record each request's destination, trigger event, and the fields it carried. Synthetic values make the test traceable and ensure no real visitor data is involved.

Record the conditions honestly: the page URL, date, browser state, and any consent-banner choices in effect, since tag behavior can depend on consent state. One quiet observation under one set of conditions does not prove the form is always quiet, and one observed request does not prove what the receiving service stores. Mark unexamined states and unexplained requests as open, not as cleared.

Attribute each transmission to a script and a purpose

For every observed transmission, identify the responsible script: the form plugin, an analytics tag, a session-replay tool, or an abandonment-recovery service. Each has an owner and a configuration you can inspect. A transmission with no identifiable source stays unattributed until the technical owner traces it; do not guess and do not assume the most visible plugin is the sender.

Then ask what the transmission is for and whether that purpose was ever approved. Under the UK ICO's articulation of data minimisation, personal information should be limited to what the purpose requires; pre-submission capture of an abandoned form is a purpose of its own that needs its own justification, not a side effect of having a form. That principle is UK guidance under review; the applicable obligations where you operate need qualified review.

Compare behavior with what the form tells visitors

Read the form's labels, help text, and linked policy, and compare them with the timeline. A form that says nothing will be sent until you submit, while transmitting partial entries, is a representation problem regardless of the legal analysis. A form whose policy discloses analytics but whose visitors would never expect field-level capture of unsubmitted text has a subtler mismatch that the privacy owner must weigh.

Keep the categories distinct: the technical capability, the observed behavior, the disclosed practice, and the legal position are four separate questions. This process answers the first two from evidence. The third is a wording and policy decision. The fourth belongs to qualified counsel, and nothing in a network log answers it.

Assign the correction and set the follow-up boundary

Corrections route to owners: the technical owner disables or reconfigures the capturing script, the content owner corrects the form's text, and the privacy owner decides what the intended practice is, with qualified advice. If the business wants pre-submission capture, that is a deliberate decision requiring disclosure and legal review, not a default to slide into. Recheck the timeline after any authorized change under the same conditions as the original test.

Finally, set the downstream rule: data captured from unsubmitted forms is not an inquiry. Staff must not use abandoned partial entries to initiate contact, because the visitor did not send anything and no follow-up was requested. If abandonment-recovery contact is ever proposed, it goes through the policy owner and qualified review first. A scoped Prism website review can include how your forms and notices describe data handling; agree pages, scope, fees and terms before any work.

Form-event timeline

Build this from one controlled test with synthetic values, and repeat per form and per consent state. Record destinations and triggers, never real visitor data. A form is understood only when every observed request has a script, a purpose, and an owner decision.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.