Gravity Forms compares a reCAPTCHA v3 score from 0.0 to 1.0 with the configured threshold, and a well-formed entry at or below that threshold can be sent to spam. Lowering the threshold after one lost lead may admit more abuse, while keeping it too high can continue rejecting legitimate users. Calibration needs labeled samples by form and traffic path.
Use this for sites with Gravity Forms reCAPTCHA v3 Classic or Enterprise where valid entries appear in spam, especially paid landing pages, mobile traffic, accessibility paths, embedded forms, and high-value lead flows. Do not store raw personal fields in the analysis export.
Quick answer
Collect a time-bounded sample of valid, false-positive, and confirmed-spam entries with form ID, score, current threshold, source, device class, submission path, entry note, and outcome. Compare distributions by form, test a proposed threshold on historical data, then change one form or controlled cohort at a time. Monitor false-positive and spam escape rates with a rollback value.
What to check first
- Confirm the reCAPTCHA add-on version, v3 Classic or Enterprise mode, site and key assignment, current global and per-form state, and token-expiration exposure for long completion paths.
- Export entry ID or a pseudonymous sample key, form ID, score, threshold, spam note, UTC time, source category, device class, browser family, page path, and final human classification.
- Separate confirmed spam, known valid conversions, staff tests, accessibility tests, slow completions, validation retries, and traffic sources rather than calculating one site-wide average.
- Simulate candidate thresholds against the labeled sample and report valid entries blocked, spam entries admitted, sample size, and uncertainty for every form.
- Deploy the smallest threshold change, retain honeypot and other controls, review spam entries daily during the test, and keep a documented rollback threshold.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build a privacy-safe labeled sample | Confirm the reCAPTCHA add-on version, v3 Classic or Enterprise mode, site and key assignment, current global and per-form state, and token-expiration exposure for long completion paths. | Known valid and confirmed-spam rows are labeled separately by form. |
| Segment scores by form and journey | Export entry ID or a pseudonymous sample key, form ID, score, threshold, spam note, UTC time, source category, device class, browser family, page path, and final human classification. | The proposed threshold has a measured tradeoff, not only a lower number. |
| Model candidate thresholds | Separate confirmed spam, known valid conversions, staff tests, accessibility tests, slow completions, validation retries, and traffic sources rather than calculating one site-wide average. | Production testing changes one controlled scope and keeps other spam controls active. |
| Test one controlled change | Simulate candidate thresholds against the labeled sample and report valid entries blocked, spam entries admitted, sample size, and uncertainty for every form. | Daily review tracks false positives, spam escapes, conversion completion, and rollback criteria. |
Why this usually happens
- reCAPTCHA scores represent risk signals, not a universal truth about a person.
- Different forms, traffic sources, devices, and user journeys can have different score distributions.
- Long form completion can interact with token expiry or repeated validation paths.
- A global threshold can be too strict for one form and too loose for another.
- Teams often label only obvious spam and never capture known valid false positives.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id,score,threshold,label,source,device,outcome
7,0.3,0.5,valid,paid_search,mobile,false_positive
7,0.1,0.5,spam,direct,desktop,blocked
7,0.7,0.5,valid,organic,desktop,accepted
# Model candidate thresholds on labeled rows before changing production.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build a privacy-safe labeled sample
- Segment scores by form and journey
- Model candidate thresholds
- Test one controlled change
- Monitor false positives, spam escapes, and rollback
Decision rule
Change the threshold only when the labeled sample shows a meaningful reduction in valid entries sent to spam and an acceptable increase in spam escapes for that form. If the sample is small or labels are uncertain, improve observation before making a large change.
What to tell the client or owner
Report sample dates and size, score distributions, current and proposed thresholds, projected valid loss, projected spam escape, affected forms, monitoring owner, and rollback trigger. Exclude names, email addresses, message bodies, and full IP addresses.
Production verification checklist
- Known valid and confirmed-spam rows are labeled separately by form.
- The proposed threshold has a measured tradeoff, not only a lower number.
- Production testing changes one controlled scope and keeps other spam controls active.
- Daily review tracks false positives, spam escapes, conversion completion, and rollback criteria.
Mistakes to avoid
- Do not set the threshold to zero after one false positive.
- Do not mix all forms and traffic sources into one score average.
- Do not export personal entry content for calibration.
- Do not delete spam entries before the review window and evidence policy are complete.
Questions teams ask during testing
Is a higher reCAPTCHA score always a real customer?
No. The score is one risk signal. Use entry notes, known outcomes, form context, and other controls to label samples.
Can every form use the same threshold?
It can technically be configured broadly, but calibration should examine each form's risk, traffic, completion path, and false-positive cost.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, calibrate Gravity Forms spam controls.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references