Formhawk

Stop guessing what happens to your WordPress forms

A form can look perfectly fine while quietly losing leads.

Visitors may:

• See the form but never start it.
• Start filling it out and abandon it.
• Get stuck on a specific field.
• Hit repeated validation errors.
• Submit the form while email sending fails.
• Stop converting as well as they did before.

Formhawk shows you what happens between a form view and a successful submission.

Track form conversions, discover where visitors abandon forms, find problematic fields, monitor Contact Form 7 failures, and see the health of every tracked form from your WordPress dashboard.

No external analytics account. No tracking cookies. No visitor profiles.

Just actionable form analytics stored inside WordPress.

See where your forms are losing conversions

Formhawk tracks separate aggregate signals:

Views → Starts → Browser submit attempts, plus provider-confirmed successes where available.

For every tracked form you can see:

• Form views.
• Form starts.
• Browser submit attempts.
• Abandonments.
• Provider-confirmed successes and confirmed conversion where supported; otherwise N/A.
• Abandonment rate.
• Browser validation friction and separate provider validation rejections.
• Submission failures.
• Average completion time.
• Last confirmed success.
• Last detected failure.
• Conversion changes compared with the previous comparable period.

Instead of knowing only how many submissions you received, you can see where potential conversions are being lost.

Find the fields that make visitors leave

A form may have traffic and still convert poorly because one field creates unnecessary friction.

Formhawk tracks field-level interactions without reading the values visitors enter.

See:

• Which field was interacted with last before abandonment.
• Which fields generate validation errors.
• How often individual fields create friction.

This helps you identify fields that may be confusing, unnecessary, incorrectly configured, or hurting conversion.

Field ROI — Business Value Intelligence

Field ROI answers a harder question than “where do visitors abandon?”: is a field worth asking at all?

When provider-confirmed submissions are linked to qualified, won, lost, spam or duplicate outcomes, Formhawk evaluates both sides of the trade-off:

• Conversion cost and validation friction.
• Qualified leads per visitor.
• Won leads per visitor.
• Revenue per visitor and expected value contribution.
• Outcome and revenue coverage.
• Sample size, maturity and confidence.
• A deterministic recommendation and Field Value Map verdict.

Verdicts include Money Maker, Conversion Killer, Qualifier, Free Value, Neutral and Unknown. A field may reduce raw submissions and still be worth keeping when it improves business value per visitor.

Formhawk never turns correlation into causation. Historical friction is labelled observational and uses “associated with” language. Measured causal lift appears only for a valid controlled Autopilot field-presentation experiment that explicitly targets the field; it describes the current configuration versus that tested alternative, not an untested removal. Large experiments that also pass sample, coverage and directional-probability thresholds are labelled strong experimental evidence.

Field ROI includes an onboarding flow, protected Outcome REST API, manual outcomes, hashed/revocable API keys, immutable decision history, Field Value Map and a Business Value Intelligence card on each form detail screen.

Know when a form stops working

A broken form can cost leads without producing an obvious WordPress error.

Formhawk continuously evaluates tracked forms and assigns a clear health state:

• Collecting — not enough data yet.
• Healthy — the form is receiving normal successful activity.
• Warning — suspicious behavior has been detected.
• Critical — a newer failure exists after the last confirmed success.

Formhawk can also warn about situations such as:

• Visitors starting a form but no submissions being recorded.
• Forms being viewed but never started.
• Conversion dropping compared with the previous comparable period.
• Provider-confirmed outcomes and submit attempts that receive no matching success signal.
• WordPress mail failures.

You do not need to manually test every form on your website just to know whether it still appears to be working.

First-class supported form providers

Formhawk automatically distinguishes these providers before the standard HTML fallback:

• Contact Form 7.
• WPForms Lite and WPForms Pro.
• Elementor Pro Forms.
• Standard HTML forms.

Contact Form 7, WPForms and Elementor Pro Forms combine frontend behavior analytics with provider lifecycle hooks. A browser submit is an attempt; Formhawk records a confirmed successful submission only when the provider reaches its accepted/success lifecycle.

Contact Form 7 analytics

Formhawk combines frontend behavior analytics with Contact Form 7 server-side hooks to track:

• Confirmed successful submissions.
• Mail sending failures.
• Validation failures.
• Validation errors by field.
• Aborted submissions.
• Form abandonment.
• Field-level friction.
• Conversion rates.
• Form health.

This allows Formhawk to distinguish between a visitor merely attempting to submit a Contact Form 7 form and WordPress actually reporting a successful submission.

WPForms Lite and Pro analytics

Formhawk uses WPForms’ successful processing lifecycle to confirm accepted submissions. This works when WPForms Lite supplies an entry ID of zero and does not require entry storage.

WPForms analytics include:

• Stable WPForms form and field IDs.
• AJAX and non-AJAX submit attempts.
• Provider-confirmed successful processing.
• Validation failures and affected fields.
• Compound field normalization.
• Multiple and dynamically inserted forms.

Elementor Pro Forms analytics

Elementor Pro Forms are identified by their document context and stable form widget ID. Formhawk observes Elementor’s validation and post-action record lifecycle without modifying the form record, AJAX response or Actions After Submit. A post-action record is confirmed only when Elementor’s handler still reports a successful outcome.

Elementor’s mail_sent hook is treated as evidence about the Email action and becomes a separate mail-action success metric only after the overall action pipeline succeeds. It is not the universal definition of a successful form, because an Elementor form may use other actions or no Email action at all.

Works with standard HTML forms too

Formhawk also automatically discovers eligible standard HTML <form> elements.

This includes forms that are:

• Present when the page loads.
• Added dynamically with JavaScript.
• Loaded through AJAX.
• Opened inside popups or modals.

For generic HTML forms, Formhawk records the browser submission event as an observed submission attempt.

Because arbitrary custom form handlers cannot universally be verified from the browser, Formhawk does not claim a server-confirmed success where one cannot actually be verified.

Zero complicated setup

Install Formhawk and activate it.

That’s it.

There is:

• No tracking snippet to install.
• No external Formhawk account to create.
• No analytics service to connect.
• No JavaScript configuration.
• No cookie banner integration required specifically for Formhawk analytics.
• No form-by-form setup for supported forms.

Formhawk automatically discovers supported frontend forms and starts collecting aggregate analytics when visitors interact with them.

Open Formhawk in your WordPress dashboard to see the results.

Autopilot CRO — self-optimizing forms

Enable Autopilot once. Formhawk uses existing aggregate analytics to find a
high-confidence opportunity, creates one reversible runtime variant, measures it,
protects the form with guardrails, promotes a credible winner and monitors it for
regression before continuing.

Autopilot is not a manual A/B-test builder. Its standard loop is automatic:

Observe → find friction → create hypothesis → experiment → measure → protect → promote or reject → continue.

Safety remains the first constraint:

• The original CF7, WPForms or Elementor form definition is never rewritten.
• Required, conditional, legal, consent, payment, password, CAPTCHA, security and upload fields fail closed from structural experiments.
• Contact Form 7, WPForms and Elementor winners use provider-confirmed conversions.
• Generic HTML uses advisory observed submit rate, with manual decisions in Observe/Approve mode. It cannot autonomously promote a winner from browser reports.
• Low-traffic experiments remain collecting; minimum sample, conversions and runtime all apply.
• Harmful variants return new traffic to control automatically.
• Promoted winners are monitored and can be rolled back automatically.
• Assignment is scoped to the current page/form lifecycle, with no cookie or browser storage. Short-lived hashed server state prevents unlimited event replay.
• Server-issued assignments are counted before the browser can selectively report views; automatic decision rates use these assignments, not browser view reports.

For Qualified Leads, Won Leads and Business Value objectives, a raw-submission
decline is not treated as terminal harm by itself: a useful qualifier may reduce
volume while increasing value per visitor. Server-confirmed provider failures and
validation retain automatic guardrail authority. Browser JavaScript errors, client
validation and latency request review; they cannot independently reject an
experiment or roll back a baseline. Delayed business-outcome regression is
reported in immutable evidence history; automatic post-promotion rollback on that
delayed signal is not included in 0.5.2.

Choose Observe, Approve or Full Autopilot mode. Approve is the safe default. The
form detail screen explains the opportunity, live result, evidence, optimization
history and compounded measured impact. With Field ROI enabled, Autopilot can
optimize submissions, qualified leads, won leads or business value. Revenue per
visitor is preferred when mature revenue coverage is sufficient; qualified leads
per visitor is the fallback.

Privacy-first form analytics

Form analytics should not require building profiles of your visitors.

Formhawk is intentionally designed without visitor-level analytics.

Formhawk does not intentionally store:

• Form field values.
• Names entered into forms.
• Email addresses entered into forms.
• Phone numbers entered into forms.
• Message contents.
• IP addresses.
• Persistent visitor IDs.
• Persistent session IDs.
• User agents.
• Email recipients.
• Email subjects.
• Email message bodies.

Formhawk also creates:

• No analytics cookies.
• No localStorage tracking.
• No sessionStorage tracking.
• No persistent browser identifier.

For supported provider-confirmed submissions, Field ROI creates one cryptographically
random opaque fh_… submission ID. It contains no email, phone, user ID, IP or
fingerprint, is scoped to that submission, is removed from provider payloads before
entry/mail processing, and exists only to attach later business outcomes.

Repeated AJAX submissions from the same form receive separate IDs after the
previous terminal response. In-flight requests and validation/error retries keep
their existing ID. Form views, starts and the CRO experiment arm remain scoped
to the current page lifecycle; each new submission can record its own attempt.

CRO contexts use a random 128-bit assignment ID and signed issuance/expiry times.
The server stores only its SHA-256 hash, structural attribution and bounded event
state, not the raw token or a visitor profile. View, start, client validation,
JavaScript error and abandonment are accepted at most once. Up to 50 sequenced
submit attempts are allowed per context; observed submit and latency cannot be
replayed into extra samples. Contexts expire after two hours by default (maximum
24 hours), with expiry cleanup on issuance and every 15 minutes via WP-Cron.
The registry is capped at 50,000 rows per site; failed admission preserves the
original form. Hosts disabling WP-Cron should provide a regular system cron.

Field ROI stores only structural field presence/requiredness, provider structural
IDs, outcome transitions, integer minor-unit value, ISO currency and a hash of an
optional external reference. It never stores the CRM payload or submitted field
values. Temporary form state exists only in JavaScript memory for the current page.

Analytics and the time-bounded Field ROI attribution journal are stored locally in
your WordPress database. Daily aggregates and immutable decision snapshots survive
linkage expiry.

No Formhawk analytics data is sent to an external Formhawk analytics service.

Your analytics stay in WordPress

Formhawk stores daily aggregate analytics locally in WordPress.

You control how long analytics are retained:

• 30 days.
• 90 days.
• 180 days.
• 365 days.

Expired analytics are cleaned automatically.

You can also choose whether Formhawk data should be completely removed when the plugin is uninstalled.

Monitor WordPress email health

Forms often depend on WordPress email.

Formhawk monitors the WordPress wp_mail_failed and wp_mail_succeeded hooks without storing recipients or email contents.

You can:

• See WordPress mail success and failure health signals.
• See recent mail failures.
• Run a manual wp_mail() diagnostic test.

A successful wp_mail() event means WordPress/PHPMailer accepted the message for sending without an immediate error.

It does not guarantee that the message ultimately reached the recipient’s inbox.

Designed for useful data, not visitor surveillance

Formhawk uses:

• Local daily aggregate storage.
• Batched frontend event delivery.
• A dependency-free frontend tracker.
• Same-origin REST event ingestion.
• A public, site-bound routing token. It is not authentication or a secret.
• Atomic site-wide request, event-cost and structural cardinality budgets without visitor identifiers.
• IntersectionObserver for actual form-view detection.
• MutationObserver for dynamically inserted forms.

The goal is simple:

Show you whether your forms work and where they lose conversions — without collecting the contents of your visitors’ submissions.

What Formhawk tracks

Form analytics

• Views.
• Starts.
• Interactions.
• Submissions.
• Abandonments.
• Failures.
• Conversion rates.
• Abandonment rates.
• Average completion time.

Field analytics

• Last interacted field before abandonment.
• Validation errors by field.
• Field interaction signals.

Form health

• Collecting, Healthy, Warning and Critical states.
• Last confirmed success.
• Last failure.
• Conversion-drop detection.
• Started forms with no submissions.
• Viewed forms with no starts.

Contact Form 7

• Confirmed submission success.
• Mail failures.
• Validation failures.
• Aborted submissions.
• Field validation errors.

WPForms Lite / Pro

• Provider-confirmed successful processing.
• Validation failures and fields.
• Stable form and compound-field identity.
• Dynamic and multiple-form discovery.

Elementor Pro Forms

• Provider-confirmed accepted records after form actions.
• Validation failures and fields.
• Separate Email-action success signals.
• Popup, dynamic and multi-step form discovery.

WordPress mail

• wp_mail() success signals.
• wp_mail() failure signals.
• Manual mail diagnostic test.

Privacy

• No analytics cookies.
• No persistent browser storage.
• No persistent visitor IDs; Field ROI uses only a per-submission opaque linkage.
• No IP address storage.
• No user-agent storage.
• No submitted field values.
• No external Formhawk analytics service.

Developer controls

Individual forms can be excluded with:

data-formhawk-ignore

Generic forms can receive readable identifiers using:

data-formhawk-title

and:

data-formhawk-id

Tracking can be disabled programmatically with the:

formhawk_tracking_disabled

filter.

Developers can integrate with recorded aggregate events using the:

formhawk_event_recorded

action.