Spam in leads: a full guide to protecting forms
Contents
Share
Spam in a lead is dubious or malicious content in the message, not every lead that did not buy. The OWASP catalog names this event Spamming: adding such information to open or closed content, or to messages. Other names on the page include form spam, comment spam, and review spam. The content may be advertising, an attempt at search optimization, or an attempt to dilute and hide other records. The page does not give a share of spam among leads or a description of Russian forms. A mass mailing through a broken form-to-email or form-to-SMS send is not part of this event.
Click fraud does not clean a form. Direct also does not treat off-target fields, a wrong contact, or a form filled in for a reward as invalid traffic. Protect the form as your own boundary, not as a way to get clicks back.
What the account will not subtract
Direct does not treat as invalid traffic repeat conversions in different visits, a repeat opening of the thank-you page, a contact entered incorrectly, off-target field values, or a form filled in for a reward. Invalid clicks are not on that list as "a bad lead." Click fraud and sklikivanie describe the click and the impression. A lead with advertising in the text can be spam in the OWASP catalog and at the same time not be Direct invalid traffic.
Who clicks ads and why does not label the form text. Whether Yandex refunds click fraud does not depend on a trap field. If the aim of the guide is fewer junk messages for a manager, configure the form. If the aim is a credit in the account, this list says off-target leads and leads filled in for a reward do not qualify.
A captcha slows and does not close
OWASP's guidance on credential stuffing says a captcha on a login attempt helps notice automation and can slow guessing, but it is not perfect: tools and services exist that solve captchas with a noticeably high success rate. IP blocking stops simple guessing and should not be the only defense: an address is easy to change, and a distributed approach through proxies keeps the rate from one address low. Client-side checks, including JavaScript, can be forged, so a second layer is required. Program names and rate thresholds are not carried over here.
On a form it reads the same way. A captcha before submit can slow a script. A passed test does not prove a person assembled the lead. A single address ban does not hold an approach that changes IP and knocks rarely.
An empty field a person is supposed to leave empty
In the honeypot section the same guidance describes a hidden form field marked to be left empty. By that description, bots fill it in and a person does not. If the field arrives non-empty, the submission is rejected. The technique is called cheap and without an effect on an ordinary visitor. The page has no catch rate and no false-reject rate. It also says a single technique is fragile. Markup, field names, and a delayed response are not carried into this guide: leave the field empty for a person, reject a non-empty submission, and do not make it the only measure.
A browser task is not a substitute for a block
Binetro can give a suspicious visit a computation task in the browser. A correct solution confirms the check and can change a "challenge" decision into "allow." A "block" decision is not cancelled by the task. The task cannot be offered instead of an allow. Difficulty, lifetime, and format are not published. For a form this means the task can confirm a visit that is still in question, and it does not turn a block already made into a submitted lead. It is not a picture captcha and not a trap field.
Order for the form
Name what you are filtering. Dubious text in the message is spam in the catalog's sense. An off-target but honest lead, and a form filled in for a reward, are not Direct invalid traffic and not a reason to expect a refund.
Put a server-side check in place. Client-side JavaScript can be forged, and it is not enough alone.
If there is a captcha, treat it as a slowdown, not a lock. Tools, services, and people solve the test.
Add a hidden field a person leaves empty, and reject the submission if it arrives filled in. Do not leave the field as the only measure: a single technique is fragile.
Do not build the defense on one IP list. The address changes, and rare visits from different addresses are not held by a simple ban.
If the visit is given a computation task, do not expect a correct answer to cancel a block. The task confirms the check and can change "challenge" to "allow." It does not cancel "block," and it cannot stand in for an allow.
Decide separately what to do with text that already arrived: spam in the catalog is the content of the message, and a filter before submit does not label it after the fact.
| Technique | What it gives | The limit |
|---|---|---|
| Captcha | Notices automation and slows guessing | The test is solved; services have a noticeably high success rate |
| IP ban | Stops simple guessing | The address is changed; the rate from one address stays low |
| Hidden empty field | Cheap; an ordinary visitor does not fill it in | A single technique is fragile; the page gives no catch rate |
| Binetro computation task | A correct answer can change "challenge" to "allow" | A block is not cancelled; it is not offered instead of an allow |
| A Direct complaint about the lead text | — | Off-target fields and a form filled in for a reward are not invalid traffic |
A teaching pass of one lead, not statistics. The comment field arrived with someone else's price list and a link. That looks like adding dubious information to a message, which is catalog spam, not a click Direct is obliged to subtract. The hidden field arrived empty: the trap let the lead through. The captcha may have been solved. What remains is a server-side rule on the content, and a decision on the visit that a browser task does not replace once a block has already been made. The sources have no figure for "how many such leads a week," and the example does not add one.
What to put on a form in one pass
Build the form so each layer covers a hole in the previous one, and do not expect Direct to pay for the junk.
The server accepts a submission only after its own check. An email field in the browser, if there is one, looks at the shape of the string, not at whether the mailbox exists, and the HTML can be changed locally — that is a neighboring topic about the contact, and here it is enough to remember that the client layer can be forged. A captcha in front of the button slows a script and notices automation. A passed test is not a person: tools and services solve captchas with a noticeably high success rate.
Next to it, a hidden field marked to be left empty. A person does not fill it in, and a non-empty submission is rejected. The technique is cheap. Alone it is fragile, so do not remove the server check once the field is in place. Leave an IP list for simple guessing: the address changes, and rare visits through proxies are not held by a ban on one address.
Put a computation task on a suspicious visit, not on every submission in place of an allow. A correct answer can change "challenge" to "allow." It does not buy off a block. If the comment already holds someone else's price list, that is the content of the message, which is spam in the catalog's sense, even when the trap was empty. Do not file an honest off-target lead or a form filled in for a reward as invalid traffic: Direct does not put them there, and do not expect a refund from this guide.
Check the assembled form with three submissions, as a teaching exercise, not as statistics. The first: empty visible fields and an empty trap. The server should reject it by its own rules, not by the hidden field. The second: a normal comment and a filled-in trap. The submission is rejected because the field arrived non-empty. The third: someone else's price list in the comment and an empty trap. The trap stays silent, the captcha may have been solved, and a rule on the content remains. If the visit already received a block, a computation task will not push this lead through. If the decision was "challenge" and the answer is correct, the visit can become an allow. None of the three submissions becomes an invalid Direct click only because of the text.
Gather that into a checklist before you turn the form on. There is a server-side check; without it a client script can be forged. A captcha, if present, is labeled on your side as a slowdown, not as proof of a person. The hidden field is empty for a person, a non-empty submission is rejected, and the field is not the only measure. IP is not the only barrier. A computation task is not offered instead of an allow and does not cancel a block. In the Direct account, off-target fields, a wrong contact, a repeat in another visit, a repeat of the thank-you page, and a form filled in for a reward are not counted as invalid traffic, so a refund dispute is not opened on them. Content the catalog calls spam is handled as the text of the message, apart from the click.
Repeat the boundary in a manager's words, with no new promises. "They sent someone else's price list" is the content of the message, catalog spam, and a rule on the text plus the layers before submit is what catches it. "The person mistyped the phone" and "they filled it in for a prize" are not invalid traffic in Direct. "The same address knocks often" is poorly closed by one IP ban: the address is changed, and through proxies the rate from one address stays low. "The captcha was passed" means the test was solved, not that a person wrote it. "The browser task was solved" can change a challenge into an allow and does not lift a block. These five sentences do not add up to one button that returns the budget. A repeat conversion in another visit and a repeat opening of the thank-you page are also left by Direct in ordinary traffic. Catalog spam can still sit in the text and not become a reason for a credit. A second layer after the captcha is still required: client-side JavaScript can be forged, and a single technique, including the empty field, is fragile. An IP ban does not replace that second layer, because an address is easy to change.