How to choose and roll out click-fraud protection
Contents
Share
Choose click-fraud protection by what it does to a visit, not by a promise that “spend will fall by a percent”. Binetro places a script on the page. The script collects data in the visitor’s browser and sends one check request. The response is a decision for that visit: let the visitor through, give a computational check in the browser, or not let them in. Separately, a ban on a repeat visit from this address to this site may be set. A site has an observation mode and a protection mode.
Click fraud is not cancelled by this scheme and is not measured “before and after”. The docs do not set a time budget for the script on page load and do not set a way to measure the effect of protection on ad spend before and after. If the script did not get a response in time, the visit is let through. Below are the criteria and the rollout order without those two promises.
First criterion: one request per visit
Protecting the site from bots and ad click fraud is built here as one check of the visit, not as a constant poll. A script on the page, one request, one decision. Click fraud and sklikivanie stay names of the problem. The choice criterion is whether the product has this loop, not a set of slogans.
If there is no response, the visit does not hang: it is let through. That boundary is worth saying before you turn anything on, so a stalled check is not read as “everyone was blocked”.
Second criterion: three decisions
Let through — the visit continues. A computational check in the browser is a task given to the visitor; in the docs it is a separate decision, not the same as refusing at once. Not letting them in — the visit does not proceed. A ban on a repeat visit from this address to this site may be set separately. The conditions under which it is set are not in the public description. The criterion is honest if you are told the three outcomes and are not promised that a live person will never see a check: these docs do not contain that promise.
Invalid clicks are decided by the platform. The script does not return what was charged and does not take part in the account’s calculation. Whether Yandex refunds the money stays a question for the platform.
Third criterion: observation first
In observation the check is calculated in full, but the visitor is always let through on the outside, a repeat-visit ban is not set, and the log records both the actual let-through and the decision that would have been made in protection. In protection the decision is applied to the visit.
For a rollout this is the main practical step. Turning protection on at once means applying “do not let in” and the computational check to live people without a log beforehand. Observation does the same calculation and leaves everyone let through. The log shows what the decision would have been. That is not a measurement of ad spend before and after: the docs do not set such a method.
What not to demand in a results agreement
Do not demand a figure “the page will get faster by this much”: a time budget for the script on load is not set. Do not demand a method “CPA before and CPA after”: a way to measure the effect on ad spend is not set. The absence of these promises is a boundary of claims, not a hidden measurement. Who clicks the ads does not fill that gap with a percentage.
The result you can accept: the script is in place, one request leaves per visit, the observation log shows three classes of decision, after the switch to protection the decisions are applied, and if the check stays silent the visit is let through.
Rollout order
Name what you are protecting the site from: bots and ad click fraud, with one script and one request per visit.
Write down the three decisions and the separate possibility of a repeat-visit ban. Do not invent the conditions of the ban.
Write down the let-through if no response arrived.
Turn on observation. Check that everyone is let through on the outside, a repeat ban is not set, and the log has both the let-through and the decision that would have applied in protection.
Read the log without a promise that the share of “do not let in” equals the share of fraud in the account. The docs do not tie that share to spend.
Switch to protection when the log is clear. Then the decision is applied to the visit.
Do not close with a comparison of ad spend before and after. That method does not exist.
Do not close with page speed. There is no time budget.
Two weeks as an example
A teaching example, not a client measurement.
The first week the site is in observation. Visits send one request each. Every visitor is let through. In the log some visits would have been “do not let in”, some a computational check, some let through. A repeat-visit ban does not appear. Direct spend for the week is not compared with the previous week as an effect: the method is not set. Page speed is not promised.
The second week protection is turned on. The same three decisions start to be applied. A visit the check did not answer is let through. A repeat-visit ban may appear; the example does not assign the conditions, because the conditions are not in the public facts.
The outcome the example is allowed to file: the mode changed, the first week’s log is kept, and spend “before and after” is not presented as a product result.
Choice checklist
There is a script and one request per visit.
Three decisions are named: let through, a computational check, do not let in.
The repeat-visit ban is not described more widely than “may be set”.
Silence from the check means a let-through.
Observation is available first, with a log of “what would have happened”.
In observation everyone is let through on the outside and a repeat ban is not set.
In protection the decision is applied.
The criteria contain no page speed and no ad spend before and after.
A money refund is not promised by the script.
How to read the observation log
The log is the only result the docs allow you to accept before the switch to protection. Read it by rows, not by a budget percentage.
A “let through” row in the observation log means both the actual let-through and that in protection the visit would have passed too. The person was let through anyway. There is no need to change mode because of such rows: they will not accumulate “do not let in”.
A row where the outside is a let-through and the decision is “would not have let in” is a reason to look at the visit, not a reason to turn protection on for the whole site at once. The docs do not tie this row to a sum in the account. Who clicks the ads may help name a motive, but will not turn a log row into the platform’s invalid click.
A row “would have been a computational check” means the third decision, not a block. In protection the visitor gets a task in the browser. In observation they do not get it: everyone is let through on the outside. Mixing the task up with a refusal is a mistake already in the log, or after protection is turned on a wave of checks will be read as a wave of refusals.
A repeat-visit ban is absent from these rows while the mode is observation. If the log marks one anyway, the mode that is on is the wrong one. That is a check of the rollout, not an argument about traffic quality.
Silence from the check does not become a log row “would not have let in”. No response — the visit was let through. In the rollout report such visits are labelled separately, so a stall is not mixed with the decision “do not let in”.
What to say at the internal acceptance
Acceptance is short items. The script is on the pages you named. One request leaves a visit. Three decisions are named and visible in the observation log. There were no refusals on the outside during the observation week, because the mode is built that way, not because the traffic turned out clean. A repeat ban was not set. Page-load time is not accepted; it is not in the docs. Ad spend this week and last week is not accepted as an effect. The date of the switch to protection is written down separately, and from that date the decision is applied.
If someone at acceptance demands a percentage, hand them the boundary: a way to measure the effect on spend before and after is not set. The percentage would have to be invented. An invented percentage cannot be signed as a Binetro result.
The second week of the example is therefore not compared with the first in money. It is compared in mode. In the first, everyone is let through on the outside, and the log stores “would have”. In the second, the same classes of decision are applied, silence still lets the visit through, and a repeat ban may appear without a public list of conditions. That is enough to treat the rollout as done. It is not enough to report to a director with the sentence “click fraud cost us less”. The docs do not support that sentence, and the checklist is there so it is not said.
A live visitor in this scheme can meet a computational check once the mode is already protection. There is no promise that this will not happen. What can be said is the benefit of the doubt for a person, and a let-through when the check is silent. “Not a single live person on a check” cannot. A choice criterion that demands an absolute is dropped here, before the purchase, not after a complaint.
Say the repeat-visit ban out loud to anyone who fears a “permanent ban”. In observation it is not set. In protection it may be set from an address onto this site, and the conditions stay outside the public description. You cannot promise a client a list of ban reasons, and you cannot promise that a ban will never happen. You can promise only what is there: three decisions on a visit, a separate possibility of a ban, a log in observation, and a let-through if there is no response.
The same conversation about speed. A developer will ask how many milliseconds the script is allowed to take. The answer from the docs: a time budget on load is not set. The rollout is not accepted on Lighthouse and not rejected on it. If the page is heavy anyway, that is a separate markup task, not a criterion of this protection. Mixing it with “do not let in” means judging the product on an axis the docs do not give it.
And the account money, a third round. A media buyer will bring two weeks of CPA. Next to the log that pair of numbers can sit as background. It is not the result of the rollout, because a method for that measurement is not set. The background is labelled “not an effect”. Otherwise in a month the argument will not be about the mode but about whose percentage is real. What stays real at acceptance is the change of mode and the decision applied to the visit.
When all three rounds have been said — the ban, the speed, the spend — the choice was made from the docs, not from a slogan. What remains is the checklist and the date observation changed to protection. Without the date, a log of “would have” is easy to mix up with refusals already applied. The date is part of the rollout, the same as the script itself.
At the acceptance itself it helps to open one visit from each log row and say it out loud. “Let through, and would have let through” — the person passed, and in protection they would have passed the same way. “Let through, but would not have let in” — the person passed because observation was on. “Let through, but it would have been a computational check” — the person passed without a task in the browser. “There was no response” — the person passed by the silence rule. Four sentences close the argument that the log “proves nothing”. It proves the mode and the class of decision. It does not prove a ruble. That split is enough so the rollout does not sprawl into a click-fraud report, for which the script has no before-and-after method.