False positives: what to do when a real client is blocked
Contents
Share
A wrong decision against a real person is treated as worse than a missed bot. One weak signal, including request rate by itself, is not enough to turn a visitor away. If a client was stopped anyway, first find out whether this was a one-off block or a repeat-visit ban, which is stored separately and can be lifted from the cabinet.
Click fraud and invalid clicks are not the same decision: the ad platform decides its own charges, and the site decides whether to allow the visit. Click fraud and sklikivanie do not explain why a particular person was stopped. Below is what to check before you loosen protection as a whole.
What one signal is not enough for
Doubt is resolved in favor of a real person. A weak signal, including request rate on its own, does not justify a block. The public description does not set a number for how weak a signal must be. A complaint that someone was turned away after a couple of page reloads does not by itself prove that a rate rule fired. Look at which observations actually happened.
If some check has no data, that gap counts neither as a clean result nor as evidence. Only observations that took place enter the decision. An empty cell in the log is not a reason to clear the visit or to confirm a bot.
When a visitor is allowed without your asking
If the script received no answer — an error, a timeout, or a 5xx response — the visit is allowed. The check itself has no such mode: the allow-on-failure is done by the script on the site. If the answer could not be assembled, the visitor is allowed too. A failed check does not turn into a silent block. The reverse also matters: a client who "could not get in" may have hit a page that did not wait for an answer, rather than a block from the check. An allow on failure is an allow, not a ban.
An address on the site's exclusion list is allowed before the main check. The list size and the record format are not published. If a real client comes from a known office address, that address belongs on this list, not in a general weakening of the rules. Who clicks ads and why does not change an address exclusion: the list is yours, and it runs before the main check.
The repeat-visit ban
A repeat-visit ban is stored separately from the moment of the check and can be lifted from the cabinet. Someone else's ban does not by itself close the visit. If a person says they are turned away again and again, lift the ban in the cabinet and ask them to try once more. The public descriptions do not set a procedure for the case where a real person was stopped by a one-off check with no stored ban. Then look at that visit's log, rather than hunting a "lift the ban" switch that a one-off block may not have.
Whether Yandex refunds click fraud is not decided by lifting a ban on the site. Money for a click and access to the page are different decisions.
What the check knowingly can miss
The current check does not use a TLS fingerprint or an HTTP/2 fingerprint. A replay of someone else's visit description is not recognized from the first copy. Some automatic browsers can be let through. These are known gaps, not a promise of complete protection. Tool names and thresholds are not published. Loosening the check "because bots get through anyway" does not follow from those gaps: letting some automatic browsers through is already a stated boundary, and a wrong block of a real person is treated as worse.
What to do if a client did not get through
Find out whether the visit failed to collect an answer or received a block. On an error, a timeout, a 5xx response, or an answer that could not be assembled, the script allows the visitor.
Check whether the address is on the exclusion list. A record there is allowed before the main check. A regular client from a known address is added there.
See whether there is a separate repeat-visit ban. The cabinet lifts it. Someone else's ban does not close the visit by itself.
If there is no ban, this was a one-off block. One weak signal, including rate alone, is not enough for a block, and missing data is not evidence.
Do not expect lifting the ban to return money in the ad account. The refund is the platform's decision, not page access.
One complaint, taken apart
A client writes that the site turned them away and asks you to "loosen the antibot." Sort the complaint by the records, not by the feeling.
Ask for the time of the visit first. If the script received no answer then, the visit should have been allowed: an error, a timeout, a 5xx response, and an answer that could not be assembled do not become a block. A complaint of "I could not get in while the site was down" is not a decision of the check.
If there was an answer and it was a block with no stored ban, look at what it was built from. An empty check is not evidence. Request rate alone is not enough to turn a person away: doubt stays with the living visitor. How weak a signal must be is not set as a number, so do not promise the client a threshold of "after three reloads you will definitely get in."
If the block repeats, look for a separate repeat-visit ban and lift it in the cabinet. Someone else's ban does not close the visit by itself. Add a permanent office or warehouse address to the exclusion list: that record is allowed before the main check. The list size is not published, so do not promise an unlimited list.
Do not end the conversation by saying bots get through anyway. The check does not look at a TLS or HTTP/2 fingerprint, a replay of someone else's visit description is not caught from the first copy, and some automatic browsers can be let through. That is a boundary, not a reason to turn the decision off for everyone. This conversation does not return money for a click: access to the page and a charge in the ad system are decided separately.