PrivCaptcha.com

Click fraud and ad fraud prevention for paid campaigns

Scripts and traffic farms drive paid clicks into your landing pages, so a campaign reports conversions that never happened.

How click fraud burns an ad budget

Headless Chrome behind residential proxies follows the ad redirect to your landing page and POSTs the lead form. Tens of thousands of near-identical POSTs in hours.

What click fraud looks like in your logs
Reported click count runs well above the sessions your analytics records.
Cost per lead holds steady while those leads never open an email.
Click volume spikes after your daily budget resets.

How PrivCaptcha stops click fraud

Four steps, with the numbers the server uses. Nothing here is configured by you.

The widget goes on the paid event

A conversion is either backed by a redeemed token or it is not.

Sitekey works only on domains you list

Once you list your domains, any other Origin is refused with invalid-input-origin, so a fake conversion must come from the page you paid for.

The score climbs as the run fails

Spoofed headers, residential address: risk 20. Each wrong answer adds 8, capped at 40. 60 is level 4: 10 degrees, 6 pixels, 10 shapes.

Verified counts, not network reports

The dashboard keeps served, solved, failed and verified per site daily. Hold verified against the campaign report.

What a click fraud run costs now: Each lead needs 14 bits of proof-of-work at risk 20, about 16,000 SHA-256 hashes. Concentrating the run raises work to 17 bits (131,000 hashes) at 60.

Add PrivCaptcha to your landing page conversion form in two lines of code

Script tag, container in front of the submit button, and your existing verify call. Already on reCAPTCHA or hCaptcha? That backend code stays exactly as it is.

reCAPTCHA siteverify hCaptcha siteverify
Server SDKs
<!-- landing page conversion form -->
<script src="https://privcaptcha.com/1/api.js" async defer></script>
<div class="privcaptcha" data-sitekey="your-site-key"></div>
<!-- server side, unchanged -->
POST https://privcaptcha.com/api/v1/siteverify
Where it goes

On the lead form submit, not the landing page, where a challenge taxes every visitor.

What the backend does

Verify the token server-to-server. Write the lead and post the offline conversion only after success: true.

The usual mistake

Do not challenge only sessions carrying gclid or a utm tag. Drop the parameter and the widget disappears.

What this does not solve about click fraud

PrivCaptcha never sees the ad click, so the money is spent. Impression fraud and human click farms are untouched.

Common questions about click fraud

How PrivCaptcha prices click fraud, and what it does not do about it.

Not the click - the action the campaign pays for. Put the widget on the signup, download or enquiry at the end of the funnel, so the numbers you report come from clients that solved something.
Served, solved, failed and verified per site and per day. That is the whole telemetry surface - there is nothing about the visitor in it.
Every request is challenged - there is no invisible pass to aim a script at, and no allowlist that skips the check. What changes is the form the challenge takes and what it costs. The server scores each request and picks one of five difficulty levels, so an ordinary visitor gets a couple of seconds and a client that looks automated gets tight tolerances and a heavier proof-of-work. On the non-visual path, taken by screen-reader and keyboard visitors, there is no puzzle to solve at all: the proof-of-work is the whole challenge, at a fixed 22 bits.
No. An address is used for the length of one request and never written anywhere. What we keep is an HMAC of it under a salt that is random, lives only in Redis and rotates every day, so yesterday's hashes cannot be linked to today's. The counters under that hash expire after 24 hours.

Put PrivCaptcha in front of your landing page conversion form

10,000 verifications a month are free, and the integration is the one you already have.