Why We Validate Leads Before the Ping, Not After the Post

Pre-ping fraud validation checks an inbound lead the moment it enters the distribution platform, before any buyer receives a bid request. Rejecting a lead on the post gives you a dispute. Validating it before the ping prevents the transaction. Datahubb runs this server-side through Anura Direct at $0.035 per verification, pay as you go.

Most fraud tooling in lead generation is positioned around accuracy. How many bots it catches, how few false positives it produces, how confident the vendor is in its verdict. Those are real questions, but they are the second question. The first one is placement. A perfectly accurate verdict that arrives after money changed hands is a report, not a defense.

What Happens When You Validate After the Post

Here is the sequence most operators are actually running.

A lead arrives from a supplier. The ping fans out to eligible buyers. A buyer bids, wins, and receives the full record on the post. That buyer then runs the lead through their own validation stack, because they do not trust yours. Three days later, a rejection comes back with a reason code.

By that point you have already paid your supplier. You have already booked the revenue. You are now in a return conversation with a buyer whose confidence in your inventory just dropped a little, and neither of you has anything to gain from the discussion.

That is what post-phase detection buys you. Not prevention. A dispute.

In our own traffic across debt relief and mass tort, roughly one in five inbound leads should never have reached a buyer at all. About 15% get flagged as fraudulent. Another 5% fail on data quality, which is a different problem entirely: mistyped phone numbers, wrong state, the same person submitting twice in an hour.

That 20% is not unusual. Published estimates for combined deduplication and scrub rejection in ping post systems run somewhere between 15% and 35% of inbound volume. If your platform is not rejecting anything in that band before the auction starts, the rejections are still happening. They are just happening at your buyer, on your reputation.

Where Fraud Actually Enters a Distribution Platform

The structural problem for anyone running distribution is that you do not own the traffic.

Your supplier owns the landing page. Your supplier owns the form. Your supplier chose the traffic source, wrote the creative, and set the incentive. What reaches you is a payload, and a fraudulent payload looks exactly like a clean one. Same fields, same format, same timestamp.

The ping compounds this. A ping tells a buyer whether a lead fits their filters: state, age, debt amount, vertical. It says nothing about whether a human being was on the other end of that form. Fit and authenticity are different questions, and the ping only answers one of them.

Exclusivity does not solve it either. Exclusivity is a pricing term. Paying an exclusive price for an unverified lead means you own the only copy of something you cannot vouch for.

Why Most Fraud Tools Need a Script on a Form You Do Not Own

The strongest bot detection available today is client-side. A script sits on the form where the lead is created and watches the session: mouse movement, keystroke timing, field focus order, how long the visitor spent before submitting. That produces a genuinely rich signal, and vendors who do it well are confident enough to guarantee against false positives.

We are not going to pretend otherwise. When you can deploy client-side detection, it sees more than we do.

The problem is deployment. To run client-side detection across a distribution business, you need every supplier to install a script on every landing page and keep it there. Some will. Most will not, or will install it on the pages you asked about and not the ones you did not. What you end up with is coverage on part of your supplier base, and partial coverage of a fraud problem is not protection. It is a sample.

What Server-Side Validation Sees, and What It Misses

Datahubb runs verification server to server at intake. Anura Direct is a REST API: the platform sends the request when the lead lands, and gets back a verdict before anything else happens.

Anura is the provider we have a pay as you go arrangement with, and it is the one most customers run. IPQS is supported as an alternative integration for operators who already work with them. Customers pick one provider, not both.

What server-side validation gets you:

• Coverage across every supplier, regardless of their stack, their landing page, or their willingness to install anything
• A verdict that exists before the ping fires, so it can influence the auction instead of explaining it afterward
• No dependency on a script surviving a supplier's next page redesign

What it does not get you: interaction signal. Server-side validation cannot see how the form was filled in, because it was not there when it happened. It works from the payload and everything that can be derived from it.

That is a real trade-off and we would rather state it than bury it. We chose breadth over depth, because in distribution the supplier you cannot instrument is usually the one worth checking.

Turning a Verdict Into Something an Operator Can Act On

Anura Direct returns a binary result. A request is either SUSPECT or NONSUSPECT. IPQS returns a score. Neither of those is a decision, and neither of them means much to a person looking at a lead in a dashboard at four in the afternoon.

Datahubb normalizes both into a single lead health indicator, color coded and visible per lead. That indicator combines the fraud verdict with the platform's own validation layer, including phone validation and duplicate detection. One signal, on the lead record, in the rejection analysis, in the supplier report.

What happens next is a rules decision, and it belongs to the operator, not to us. You can block a flagged lead outright. You can route it to a different buyer tier. You can let it through at a lower bid floor. You can do nothing at all and simply tag it.

Shadow Mode: Measure Before You Change Anything

The reason most operators never turn fraud validation on is not that they doubt it works. It is that turning it on means changing routing behavior on live traffic, and nobody wants to find out at 9am that they have been blocking 30% of a supplier they depend on.

Shadow mode removes that decision from the equation. Verification runs on every inbound lead and writes a verdict to the record. Nothing is blocked. Nothing is rerouted. Distribution behaves exactly as it did the day before.

What you get is a month of your own data: fraud rate per supplier, per traffic source, per campaign, measured on your actual inventory rather than an industry average. Then you decide what rules to write, if any.

Paired with pay as you go pricing, that makes the evaluation genuinely low risk. You are not signing anything to find out what your fraud rate is.

What It Costs, and Why the Minimum Is the Real Barrier

Standalone fraud vendors price on usage and quote through their sales team. Anura is explicit about this: pricing is usage based, and you contact sales for a number. That is a normal enterprise motion and it works fine for enterprise buyers.

It works badly for everyone else. The obstacle for a mid-size lead gen operator has never been the per-lead price of fraud detection. It is the commitment attached to it. A platform-level contract is difficult to justify when you want to test one supplier in one vertical for six weeks.

Inside Datahubb, Anura verification is $0.035 per call. No contract, no minimum, no platform fee attached to it. That rate is specific to our Anura arrangement. Operators who prefer IPQS can integrate it, but they bring their own commercial terms.

Monthly inbound leads	Verification cost at $0.035
10,000	$350
25,000	$875
50,000	$1,750
100,000	$3,500

An honest note on scale. Per-unit pricing is not the cheapest model at every volume. Past a certain monthly throughput, a negotiated contract directly with a fraud vendor will beat a per-call rate, and any operator running that kind of volume should price both. Pay as you go is built for the operators below that line, and for the ones above it who want to test a new vertical without renegotiating anything.

Frequently Asked Questions

What is pre-ping fraud validation?

Pre-ping fraud validation is a check that runs when a lead enters the distribution platform, before the ping goes out to buyers. The verdict is available to the routing and bidding logic, so a flagged lead can be blocked, downgraded, or routed differently before any buyer commits a price to it.

Should I check for bot leads on the ping or on the post?

On the ping. A check that runs on the post can only produce a rejection, a return request, or a credit, all of which happen after the transaction. A check before the ping prevents the purchase instead of disputing it. ActiveProspect gives buyers in real-time auctions the same advice.

Do I need a script on the landing page to detect fraudulent leads?

No, although it helps. Script-based detection watches how a form was filled in and produces a richer signal. Server-side detection works from the lead payload and requires nothing from your supplier. Distributors who do not own the landing page usually have no realistic alternative to server-side.

How much does lead fraud detection cost per lead?

Inside Datahubb, Anura verification is $0.035 per call with no minimum and no contract. Standalone fraud vendors price on usage and quote through sales, which normally involves a monthly or annual commitment. For most operators that commitment, rather than the per-lead price, is what prevents adoption.

What percentage of inbound leads are fraudulent?

It varies by vertical and traffic source. In our own debt relief and mass tort traffic, around 15% is flagged as fraudulent and a further 5% fails on data quality. Published estimates for combined deduplication and scrub rejection in ping post systems range from 15% to 35%.

Can I run fraud validation without blocking any leads?

Yes. Shadow mode runs verification on every inbound lead and records the verdict without affecting distribution. Nothing is blocked or rerouted. It exists so operators can measure their real fraud rate per supplier before writing a single rule, which is usually the right order to do it in.