Measurement
The observer determines CAPTCHA feedback quality
Report actual acceptance with known task identity, and keep mapping bugs, transport errors, and unobserved outcomes from contaminating solver feedback.
By the easycaptcha team · Published
A feedback API may accept success or failure, but that value needs an observation behind it. A returned result is not evidence that the downstream application accepted it. A local timeout is not evidence the solver returned an incorrect answer.
Sources of feedback
Document which component observes acceptance and which event triggers feedback. That decision is as important as the HTTP method used to send the boolean.
Keep the task association intact
Persist the remote task ID at creation and carry it through answer application and final observation. Multiple concurrently active jobs can otherwise cause feedback to attach to whichever ID a shared variable last held.
For multi-round interactions, identify the unit being reported. A failure in a later round should not automatically relabel an earlier known accepted group as incorrect.
Diagnose application errors separately
Wrong image keys, coordinate scaling, stale form state, and unsuccessful interaction dispatch can produce rejection even when a result was meaningful. Keep local failure categories so these bugs are fixed rather than reported as evidence of model behavior.
Do not force a truly unknown outcome into a negative label just to avoid missing data. Record unknown coverage in your own evaluation and send feedback only when the relevant outcome is established.
Test the delivery path
Exercise accepted and rejected observations, duplicate reporting attempts according to the contract, and a feedback transport failure. A failed report does not justify recreating the original paid solving job.
Keep credentials, proofs, and unrelated private form values out of the feedback diagnostic record. IDs, stages, and timestamps can provide traceability without copying the entire request.
Review examples with the team
Use controlled cases that demonstrate completion without acceptance, acceptance without a known final action, and a deterministic mapping failure. Agree on which event the program reports and what remains in local analytics.
Feedback instructions describes the product method, coordinate analysis separates UI bugs, and unknown outcomes preserves the missing observations that a simplistic binary-only report would otherwise misrepresent.
Frequently asked questions
When should I send recognition feedback?
After observing whether the applied result was accepted. Receiving a result or making a click alone is not acceptance evidence.
Should I send unsuccessful feedback for an unrelated form error?
Distinguish challenge rejection from application failures. Report the observed challenge outcome rather than guessing from the final form state.
How can easycaptcha fit into my integration tests?
Use the documented recognition or token API for the hCaptcha stage, preserve task IDs, and inspect terminal results. Measure verifier acceptance and application completion separately from job completion.