Written for somebody deciding whether to trust this with their advertising budget. It says what is measured and how a conclusion is reached, including the parts that are estimates rather than facts.
Almost every tool in this category blocks IP addresses, and an IP address is a poor way to name a person. A phone changes its address by switching between WiFi and mobile data, and often just by moving between cell towers. Someone told they are blocked turns mobile data off and on, comes back a minute later, and is a new visitor with a clean history.
ClickHelm identifies the device instead. The browser reports a set of characteristics, and the combination of them is stable enough to recognise the same device again after it has cleared its storage, switched browser or moved to a different network. That recognition is what makes a block hold.
It is a match, not an identification. Two identical phones on the same model and the same browser version can look alike, so every match carries a confidence figure, you set how confident it has to be before a block carries across, and any single match can be rejected by hand. Nothing here claims to know who somebody is.
Some of it comes from the browser, and some from the request itself, which the browser cannot alter:
The network classification is the one item that needs an outside service, and it is switched off until you switch it on. Everything else is measured on your own server or in the visitor’s own browser.
Each check that fires adds to a risk score, and every one of them is named on the visitor it fired on. There is no single number handed down without a reason attached. The checks are:
The score orders the list; it does not decide anything. A high score means “look at this one first”, which is a different claim from “this was fraud”, and the difference is deliberate.
When Google sends someone to your site it adds an identifier to the URL. ClickHelm records that identifier against the visit it produced, and separately reads from your Google Ads account which clicks you were charged for. Lining the two up answers a question no tool outside your site can answer: which of the clicks on your invoice ever loaded a page.
It also makes the identifier checkable. Anybody can add a fake one to a URL, so an identifier that does not appear in your account is treated as manufactured rather than counted.
A blocked visitor is stopped on your server before the page is built, so they never see your site and the request costs you almost nothing. That is the first layer, and it works from the address they last used.
Someone arriving with cleared storage from an address never seen before cannot be recognised that early — there is nothing yet to recognise them by. The second layer covers this: the page loads, the fingerprint reaches your server, the device is matched against someone already blocked, and the block is applied. There is a brief moment where content is visible, which is why there is a stricter mode that holds the page until the answer comes back.
Both layers only ever act on a decision you have already made. Nothing is blocked automatically unless you wrote a rule that says so, and a rule you wrote can be switched off in one click.
It will, occasionally. A device match can catch the wrong person, and a real customer on a corporate VPN can look like datacenter traffic. Both are visible: matches that carry a block across appear on a Possible duplicates screen with the evidence and the confidence behind them, and rejecting one lifts the block immediately.
This is the reason nothing blocks on its own by default. A tool that acts silently on an uncertain judgement will eventually turn away a paying customer and never tell you it did.