If feedback produces no visible change, submission decays toward zero

What it is

The first down, people still click. The second and third, the same error is still there, the control still there, nothing changed. From the fourth they stop clicking. Feedback without visible change decays means submission rate depends on a visible closed loop of “what this click changed.” If the loop never appears, the channel dies in a few repeats. What remains is not quality improving; it is people no longer speaking.

Self-selection already makes speakers few. No echo cuts that few again.

Why it happens

Feedback is instrumental: people pay a cost expecting a perceptible difference in the system or in later output. The difference can be small — this sentence marked “noted,” the same slot not repeated on the next similar request, a line “following what you flagged last time….” With no difference at all, the cost is pure loss, instrumentality vanishes, the behaviour extinguishes.

Decay is fast because generation tasks repeat densely; a few rounds suffice to learn “clicking does nothing.” Heavier feedback forms added after that only hurry out whoever has not yet left. Once the channel is dead, the product misreads “complaints fell.”

Studying it

Track the same person’s submissions over time. Compare: no echo at all, instant receipt with no later change, a visible change in the next output. Dependent variables: probability of still submitting on the nth generation, round at which submitting stops entirely. Independent variables: echo type (receipt / real change), whether the change targets the location they pointed at.

A change that hits the location should sustain submitting better than a generic “we will improve.” Split “complaints fell” from “problems fell” against an audited error rate.

Where it stops holding

One-shot users have no nth time, so decay is unobserved; they should still get a receipt so the word-of-mouth channel does not die. Safety reports must have another receipt (a ticket id) even when the product does not visibly change; otherwise decay injures a channel that must be kept. If a real change takes several versions to ship, fill the wait with “recorded, points at update X,” not a blank. This entry does not treat edits as a richer signal.

Applying it

• Every submission gets an instant receipt, and within the shortest feasible cycle the same class of error should stop appearing in front of that user.
• Receipts should be specific to location: “we will not reuse this number you marked,” not “thanks for the feedback.”
• Treat submission rate as channel health, read beside error rate. Submission down and audited errors not down is decay, not improvement.
• Check: have people meet the same class of error three times. Does the no-echo group still click on the third. If almost none do, the channel is dead. Give one location-targeted change; third-round submission should sit well above the no-echo group.

Related

• Same group: L3.13.1 Thumbs up and down collect satisfaction, not correctness · L3.13.2 Negative feedback that does not point at a location cannot localise the problem · L3.13.3 People who submit feedback are a self-selected few; extreme experiences are over-represented · L3.13.4 Edits are implicit feedback with more information than an explicit rating
• Nearby: L3.12 Editing and Taking Over Generated Content · L6.13 Negative Feedback Channels for Recommendations
• Search terms: feedback loop closure · response extinction · visible change after report