# Datahubb — full content

> Replace your fragmented lead-gen stack with one powerful platform. Lead distribution, call tracking, fraud prevention and postbacks for profit-focused teams.

This file carries the long-form content of https://datahubb.io as plain Markdown:
blog posts, help articles, changelog entries and legal pages, in full.
For a short linked index of every page on the site, see https://datahubb.io/llms.txt.

Generated from the same database that serves the site, so it does not drift.

## Blog

### Best Lead Distribution Software in 2026: 8 Platforms Compared

URL: https://datahubb.io/blog/best-lead-distribution-software
Published: 2026-08-05

> Nine lead distribution platforms compared on verified pricing, routing depth, rejection recovery, and trial access, with an honest best-for on every entry.

Lead distribution software decides which buyer gets each lead, at what price, and how fast. Pick well and every lead finds its highest bidder; pick badly and you find out at month end, in a spreadsheet, that a third of your spend went to leads nobody bought.

This guide compares nine platforms for the businesses that live on this software: lead sellers, affiliate and lead-gen agencies, performance networks, and call operations with a pay-per-lead and pay-per-call mix.

**How this list was built:** every price below was verified against the vendor's own published pricing page in August 2026. Vendors that publish nothing are listed as custom quote, not guessed. Each entry leads with what the platform genuinely does well. We also note who each platform is wrong for, including ourselves.

## The market at a glance

| Platform | Entry price (verified Aug 2026) | Trial | Leads + calls | Standout |
|---|---|---|---|---|
| Datahubb | $499/mo flat, any volume | 14-day, self-serve | Yes | Rejection recovery with missed-revenue math |
| Boberdoo | $1,075/mo at 25 leads/day (after $500 promo) | None | BYO Twilio | Two decades of routing depth |
| Phonexa | Custom quote | None listed | Yes, separate modules | Broadest suite (9 products) |
| Lead Prosper | $500/mo incl. 5,000 leads | None listed | Leads only | Fully published rate card |
| LeadsPedia | $1,500/mo Lite (usage caps) | None listed | Yes | Affiliate network management |
| LeadByte | Quote-based | None listed | Leads only | Native multi-sell, UK/EU |
| ActiveProspect | Usage-based | Self-serve PAYG | Validation layer | TrustedForm consent certification |
| Ringba | Free tier + usage | Self-serve | Calls only | Pay-per-call ecosystem |

## 1. Datahubb: best overall for lead sellers and mixed lead-and-call operations

[Datahubb](https://datahubb.io) covers the full loop in one platform: ingestion, validation and fraud screening, filtering, distribution, pay-per-call, click tracking, postback reconciliation, returns, and analytics, at a published $499/month flat for the basic feature set at any lead volume ($424/month billed annually), no setup fee, 14-day self-serve trial.

**Routing:** four strategies (Waterfall, Highest Bidder ping post auctions, Weighted with self-correcting share targets, and Advanced ordered tiers, each tier with its own sub-strategy and minimum payout floor), plus routing rules so one campaign can send different traffic slices through different strategies with a first-match-wins rule list and a simulator that shows which strategy any supplier and channel combination would get.

**Controls:** buyer caps by day, week, month, and lifetime, for both volume and budget, enforced in a single batched database check and displayed from the same service that enforces them. Schedules with timezones. Filters at four levels (global, supplier, buyer, traffic source) with 14 condition types and value lists that scale to thousands of entries. Duplicate checking at campaign or buyer scope over a configurable window.

**The differentiator, rejection recovery:** most platforms count rejections; Datahubb prices them. Every rejection records the exact rule that fired, including the filter field and the lead's actual value, the schedule window missed, or the cap that was full. Rejections roll up into 11 groups ranked by estimated missed revenue (unrecovered leads times average sold price times sell-through rate), with breakdowns across nine dimensions, an hour-of-day histogram for schedule tuning, and a generated action plan. Leads that every buyer skipped only on schedule or caps are flagged and can be redistributed to those buyers later with live re-checks. Returned leads reverse ledgers atomically, and CPA sales are held as pending until the buyer's postback confirms, so revenue never appears on your books before it is real.

**Money movement:** Postbacks v2 fires configurable, HMAC-signed webhooks per recipient with event subscriptions, rule gating, and a persisted resolution trace that answers "why did this postback fire, or not fire" in product. Affiliates can self-serve their own postback configs, including a built-in Meta Conversions API preset.

**Honest limits:** single winner per distribution run, so native multi-sell is not offered (LeadByte has it). No consumer email or SMS nurture. Feature-based tiers mean $499 covers the basic set, with advanced features in higher tiers, whereas Lead Prosper gives every feature at every volume tier.

**Best for:** lead sellers and mixed lead-and-call operations from about 5,000 leads a month up, who want a flat bill and an itemized answer for every lead that did not sell. Migration is free and done for you, with a 2 to 4 week parallel run against your current platform; see the [comparison hub](https://datahubb.io/vs).

## 2. Boberdoo: best for high-volume operations on custom routing

The most established platform in the category, with a deep reporting suite and an extensive API. Boberdoo publishes a full pricing calculator: $500/month promo for 3 months plus $250 setup, then $1,075/month at 25 leads per day, scaling to $8,375/month at 5 million per day, with LeadQC quality scoring at $0.20 per lead and consulting at $195 per hour. No trial, demo-gated signup, and rejection reasons are not logged per lead for later analysis by its own docs. Its volume-tiered model is genuinely fair at enterprise scale.

**Best for:** enterprises at hundreds of thousands of leads per day. See [Datahubb vs Boberdoo](https://datahubb.io/vs/boberdoo).

## 3. Phonexa: best for one-vendor enterprise suites

Nine products under one roof, from lead and call distribution to email, telephony, click tracking, suppression, and accounting, with managed services included. Custom quote only, no published pricing, no listed trial. The right call when you want one enterprise vendor for everything; heavy when you want the distribution loop.

**Best for:** enterprises consolidating their whole marketing stack. See [Datahubb vs Phonexa](https://datahubb.io/vs/phonexa).

## 4. Lead Prosper: best published rate card

Rare transparency: the entire rate card is on the site with a calculator. $500/month includes 5,000 leads and 200,000 pings, then per-lead tiers from $0.05 falling to $0.0005 at 5 million or more. Every feature at every tier, unlimited suppliers and buyers, lifetime storage. The meter is the trade: about $2,300/month at 100,000 leads by its own rates, and there is no call product. No trial listed.

**Best for:** data-lead sellers at modest volume who value simplicity and published rates. See [Datahubb vs Lead Prosper](https://datahubb.io/vs/leadprosper).

## 5. LeadsPedia: best for affiliate network management

A comprehensive suite for large affiliate networks with published pricing: $1,500/month Lite, $2,500/month Premium, Enterprise custom. Lite caps monthly usage at 25,000 leads, 1,000,000 pings, and 150,000 clicks. Real-time campaign analytics are advertised; margin and P&L reporting are not. No trial listed.

**Best for:** large affiliate networks wanting deep publisher management with a guided rollout. See [Datahubb vs LeadsPedia](https://datahubb.io/vs/leadspedia).

## 6. LeadByte: best for UK/EU and multi-sell

A mature UK platform with configurable validation and six distribution methods, including native multi-sell, the ability to sell one lead to several buyers simultaneously, which nothing else on this list offers natively. Quote-based pricing, 30-day rolling contract, no setup fee, no listed trial.

**Best for:** UK and EU operators, and any model built on non-exclusive leads. See [Datahubb vs LeadByte](https://datahubb.io/vs/leadbyte).

## 7. ActiveProspect: best consent and certification layer, not a distributor

ActiveProspect's TrustedForm is the industry standard for TCPA consent certification, and LeadConduit filters and routes on a pay-as-you-go, per-event basis. It is best understood as the compliance and validation layer in a stack rather than a full monetization platform; reported billing is per event including rejected leads. Many operators keep TrustedForm and run distribution elsewhere; Datahubb integrates alongside it rather than replacing it.

**Best for:** compliance-critical verticals adding certification to an existing stack.

## 8. Ringba: best for call-only businesses

The dominant pay-per-call platform, with a free tier, self-serve access, and the largest call community in the industry. No web-lead distribution, so lead-and-call shops need a second platform, and usage line items grow with scale.

**Best for:** pure pay-per-call operations.

## How to choose lead distribution software

1. **Price it at your volume, not the entry tier.** Volume-tiered and metered platforms look cheap at the door. Put your real monthly leads into Boberdoo's calculator and Lead Prosper's calculator, then compare against a flat price.
2. **Ask to see a rejection, end to end.** Have the vendor show you one rejected lead: which rule fired, what the lead's actual value was, and what that rejection class cost last month. If the answer is a raw log, budget analyst hours forever.
3. **Check the money path, not just the routing demo.** Delayed postbacks, CPA holds, returns, and payout corrections are where platforms quietly diverge. Routing a demo lead is the easy part.
4. **Count your tools.** If fraud screening, call tracking, and postback management live in three other subscriptions, a consolidated platform changes the total cost math even before the routing improves.
5. **Prefer a trial to a demo.** Two platforms here let you operate self-serve: Datahubb for 14 days with the full platform. Everyone else starts with a sales conversation.

## Frequently asked questions

**What is lead distribution software?**
Software that receives leads from your forms, suppliers, or traffic sources, validates and filters them, and routes each one to the right buyer by price, priority, weighting, or tiers, then tracks delivery, acceptance, revenue, and payouts. Mature platforms also handle ping post auctions, pay-per-call, postbacks, and returns.

**How much does lead distribution software cost in 2026?**
Verified against published pages in August 2026: Datahubb $499/month flat at any volume. Lead Prosper $500/month including 5,000 leads, metered above. Boberdoo $1,075/month at 25 leads per day after its 3-month $500 promo. LeadsPedia $1,500/month with usage caps. Phonexa and LeadByte quote custom.

**Which lead distribution platforms offer a free trial?**
Datahubb (14 days, self-serve, full platform, card required with no charge if you cancel). Boberdoo, Phonexa, LeadsPedia, LeadByte, and Lead Prosper list no trial as of August 2026.

**What is the best lead distribution software for pay-per-call?**
For call-only businesses, Ringba. For operations selling both web leads and calls, Datahubb runs both on one ledger with managed telephony, call recording, and call conversion postbacks, so you do not maintain a second platform and a second invoice.

**Which platform shows why leads were rejected?**
Datahubb records the exact rule behind every rejection, prices each rejection reason in estimated missed revenue, and redistributes recoverable leads. Boberdoo's docs state unmatched reasons are real-time only and not logged per lead. Phonexa reports reject counts and events. On the rest, expect status-level reporting.

**Can I switch platforms without dropping leads?**
Yes, with a parallel run: mirror a copy of live traffic through the new platform alongside the old one for 2 to 4 weeks, compare sold rate, margin, and rejection reasons on your own leads, then cut over. Datahubb does the import of buyers, campaigns, filters, and payout rules for you, free, and discounts your subscription until your current contract ends if you are still under one.

---

*Comparisons reflect publicly available information from each vendor's own site, last checked August 2026, and may have changed since. Datahubb is not affiliated with any company named above.*

### Best Ping Post Software in 2026: 6 Platforms Compared

URL: https://datahubb.io/blog/best-ping-post-software
Published: 2026-08-05

> Six ping post platforms compared on auction depth, verified pricing, and rejection recovery. The best ping post software is decided by what happens after the buyer says no.

Ping post is the auction that runs this industry: send buyers partial lead data (the ping), collect bids, deliver the full record to the winner (the post). Every platform on this list can run that basic sequence. The differences that decide your revenue live in the details: what happens when the winner rejects the post, whether a buyer can run validation and bidding as separate steps, how bids are extracted from messy buyer responses, and whether anyone can tell you afterward why 30 percent of your pings never became money.

**How this list was built:** pricing verified against each vendor's own published pages in August 2026. Capability claims come from vendor documentation. Where something is not documented, we say so rather than assume.

## What actually separates ping post platforms

Before the list, the evaluation criteria that matter in production:

- **Post-rejection fallthrough.** The winner rejecting the post should mean the next-highest bidder gets it automatically, not a lost lead.
- **Multi-step pings.** Real buyers often need a validation call before a bidding call. Platforms that model one ping per buyer force you to proxy that logic yourself.
- **Response mapping.** Buyers return bids and rejections in every format imaginable. Rule-based extraction beats hardcoded parsers.
- **Rejection accounting.** The pings that never became posts are your margin leak. If the platform cannot itemize them by reason and cost, you are optimizing blind.
- **Fee model.** Some platforms charge per ping. At ping post volumes, that line item compounds.

## The platforms at a glance

| Platform | Entry price (verified Aug 2026) | Per-ping fees | Trial | Post-rejection fallthrough |
|---|---|---|---|---|
| Datahubb | $499/mo flat, any volume | None | 14-day, self-serve | Yes, next-highest bidder |
| Boberdoo | $500/mo promo, then $1,075/mo at 25 leads/day | No | None | Yes |
| Lead Prosper | $500/mo incl. 200K pings | $0.0001/ping above 200K | None listed | Yes |
| Phonexa | Custom quote, packaged by ping volume | Volume-packaged | None listed | Yes |
| LeadsPedia | $1,500/mo, 1M pings included on Lite | Capped per tier | None listed | Yes |
| LeadByte | Quote-based | Not published | None listed | Yes |

## 1. Datahubb: the auction plus what happens after the no

[Datahubb](https://datahubb.io) runs ping post through a dedicated concurrent ping service: in Highest Bidder mode, every eligible buyer is pinged simultaneously, bids are collected and sorted, the full lead posts to the top bidder, and a post rejection falls through to the next-highest automatically. A circuit breaker takes a failing buyer out of rotation after 3 failures within 5 minutes and recovers it automatically, so one buyer's outage does not slow your auctions.

**The details that matter in production:**

- **Multi-step pings.** Each buyer can run multiple sequential ping steps, validation first, bidding second, each with its own URL, headers, body template, and timeout, with later steps referencing earlier responses. The last step returning a price wins.
- **Response mapping.** A rule-based mapper interprets any buyer response into accepted, rejected, duplicate, pending, or error, reading HTTP codes, headers, or any JSON or XML body path, with operators from regex to numeric ranges, and extracts the price and the rejection reason.
- **Auction strategy per traffic slice.** Routing rules let one campaign run Highest Bidder for one supplier and Weighted or tiered distribution for another, first match wins, with the route pinned at ping time so bids are always ranked under the strategy that produced them.
- **Tiered auctions.** Advanced distribution runs ordered tiers, each with its own sub-distribution and minimum payout floor, which is how premium buyers get first look and zero-bid RevShare buyers still catch the remnant.
- **Rejection accounting, the part nobody else itemizes.** Every failed ping and post is recorded with the exact rule that fired, grouped into 11 categories, ranked by estimated missed revenue, and broken down by buyer, campaign, traffic source, and hour of day. Soft rejects, leads skipped only on schedule or caps, can be redistributed to those same buyers later.
- **No per-ping fees.** $499/month flat covers the basic feature set at any lead volume. There is no meter on pings.

**Honest limits:** Datahubb picks a single winner per distribution run; native multi-sell broadcasting is not offered. Ping-to-post latency depends on your buyers' endpoints, and Datahubb does not publish a blanket latency number.

**Best for:** ping post sellers who want auction depth, no ping meter, and an itemized answer for every lead that did not sell. Trial is 14 days, self-serve, full platform.

## 2. Boberdoo: the veteran auctioneer

Boberdoo has run ping post at scale for two decades and its routing configurability is genuinely deep. Pricing is published on its calculator: $500/month promo for 3 months plus $250 setup, then $1,075/month at 25 leads per day scaling with volume. No trial, demo-gated signup, and by its own documentation, unmatched reasons are real-time only and not logged per lead for later analysis.

**Best for:** high-volume operations that value maturity over pricing flexibility. See [Datahubb vs Boberdoo](https://datahubb.io/vs/boberdoo).

## 3. Lead Prosper: metered but honest

Lead Prosper publishes everything: $500/month includes 5,000 leads and 200,000 pings plus 200,000 pre-pings, then $0.0001 per ping beyond and per-lead overage tiers. The pre-ping dupe checker is a nice touch for sellers. It is data leads only and lists no trial. At ping post volumes, do the meter math for your traffic before committing: the pings that never sell still bill.

**Best for:** lower-volume ping post sellers who want published rates. See [Datahubb vs Lead Prosper](https://datahubb.io/vs/leadprosper).

## 4. Phonexa: ping post inside a suite

Phonexa's LMS Sync runs ping post with several distribution flows (price, priority, weight, parallel pings, even distribution) inside a nine-product suite. Pricing is custom quote, packaged by ping volume, with no published figures and no listed trial. Strong if you want the whole suite; heavy if you want the auction.

**Best for:** enterprises adopting the full Phonexa estate. See [Datahubb vs Phonexa](https://datahubb.io/vs/phonexa).

## 5. LeadsPedia: ping post for affiliate networks

LeadsPedia includes ping post with published pricing at $1,500/month, with the Lite tier capped at 1,000,000 pings and 25,000 leads monthly. Built for affiliate network management first, with call tracking as a module. No trial listed.

**Best for:** affiliate networks that also need network management. See [Datahubb vs LeadsPedia](https://datahubb.io/vs/leadspedia).

## 6. LeadByte: ping post plus multi-sell, UK-centered

LeadByte runs ping post among six distribution methods, including native multi-sell, which no one else on this list offers. Pricing is quote-based, contracts are 30-day rolling, and its center of gravity is UK and EU lead selling. No trial listed.

**Best for:** European sellers, and anyone whose model requires selling one lead to several buyers at once. See [Datahubb vs LeadByte](https://datahubb.io/vs/leadbyte).

## How to choose ping post software

1. **Model your fee exposure.** Multiply your monthly ping volume by any per-ping rate. A meter that looks tiny per unit is real money at auction volumes. Two platforms here have no ping meter at all: Datahubb (flat) and Boberdoo (volume-tiered on leads).
2. **Test the ugly buyer.** Bring your worst-formatted buyer response to the trial or demo and see whether the platform can extract the bid and the rejection reason without custom code.
3. **Ask what happens to the 30 percent.** Some fraction of pings never become posts. Ask each vendor to show you, in product, why last week's failed pings failed and what they were worth.
4. **Check trial access.** Datahubb is the only platform on this list you can fully operate for 14 days without a sales conversation.

## Frequently asked questions

**What is ping post software?**
Ping post software runs a two-phase lead sale: a ping sends partial, non-identifying lead data to eligible buyers who respond with bids, then the full lead posts to the winning bidder. It maximizes revenue per lead by making buyers compete in real time rather than accepting a fixed price.

**How much does ping post software cost?**
Verified against published pages in August 2026: Datahubb is $499/month flat at any volume. Lead Prosper is $500/month including 5,000 leads and 200,000 pings, metered above. Boberdoo runs $1,075/month at 25 leads per day after its promo, scaling with volume. LeadsPedia starts at $1,500/month with a 1,000,000 ping cap. Phonexa and LeadByte quote custom.

**What is a multi-step ping?**
A buyer flow where the ping phase itself runs multiple sequential calls, typically a validation service first and a bidding endpoint second, with the later step able to reference the earlier response. Datahubb supports this natively with per-step timeouts and price inheritance across steps.

**What happens when the winning buyer rejects the post?**
On a competent platform, distribution continues to the next-highest bidder automatically. On Datahubb this fallthrough is recorded on the lead's timeline, and if every buyer skipped the lead only on schedule or caps, it is flagged soft-rejected and can be redistributed to those buyers later with live re-checks.

**Which ping post platform has a free trial?**
Datahubb offers 14 days, self-serve, full platform. Boberdoo, Phonexa, LeadsPedia, LeadByte, and Lead Prosper list none as of August 2026.

---

*Comparisons reflect publicly available information from each vendor's own site, last checked August 2026, and may have changed since. Datahubb is not affiliated with any company named above.*

### Best Phonexa Alternatives in 2026: 6 Platforms, Verified Pricing 

URL: https://datahubb.io/blog/best-phonexa-alternatives-in-2026-6-platforms-verified-pricing
Published: 2026-08-05

> Six Phonexa alternatives compared on verified pricing, trial access, and product focus, for operators who want the lead-to-revenue loop without a nine-product suite.

Phonexa is the broadest platform in performance marketing: nine products spanning lead distribution (LMS Sync), call tracking (Call Logic), email and SMS, a cloud phone system, click tracking, suppression management, user analytics, accounting, and AI call agents, with managed services included. For an enterprise that wants one vendor to run everything, that breadth is the appeal.

It is also why people search for alternatives. If what you actually run is a lead and call operation, the suite means custom-quoted pricing you cannot see up front, a demo before you can touch anything, and modules you pay for but never open.

**How this list was built:** every pricing figure was checked against the vendor's own published pricing page in August 2026. Where a vendor publishes nothing, we say so instead of inventing a range. Each entry states what the platform does well first.

## Why operators leave Phonexa

1. **Opaque pricing.** Phonexa publishes no prices. LMS Sync and Call Logic are packaged by ping and minute volume, and every path on the site ends at a custom quote. You cannot budget without a sales cycle.
2. **Suite overhead.** Distribution, calls, email, telephony, clicks, suppression, and accounting are separate products. Teams that only need the lead-to-revenue loop carry the rest as complexity.
3. **No trial.** There is a product tour and a demo, but no listed way to route a lead yourself before committing.

## The alternatives at a glance

| Platform | Entry price (verified Aug 2026) | Trial | Focus | Calls + leads together |
|---|---|---|---|---|
| Datahubb | $499/mo flat, published | 14-day, self-serve | One platform: leads, calls, clicks, fraud, postbacks | Yes |
| Boberdoo | $500/mo promo, then $1,075/mo at 25 leads/day | None | Lead distribution, deep configs | Calls need your own Twilio |
| Lead Prosper | $500/mo incl. 5,000 leads, metered above | None listed | Data-lead distribution | Leads only |
| LeadsPedia | $1,500/mo Lite, usage caps | None listed | Affiliate network suite | Yes, call tracking module |
| Ringba | Free tier plus usage | Self-serve | Pay-per-call | Calls only |
| LeadByte | Quote-based, not published | None listed | UK/EU lead distribution | Leads only |

## 1. Datahubb: the loop without the suite

[Datahubb](https://datahubb.io) covers exactly the part of Phonexa most lead businesses actually use, and publishes the price: $499/month flat for the basic feature set at any lead volume, $424/month billed annually, no setup fee, 14-day self-serve trial.

**What replaces what:**

- **LMS Sync:** lead ingestion with a staged validation pipeline, four distribution strategies (Waterfall, Highest Bidder, Weighted, and tiered Advanced), per-campaign routing rules that give different traffic slices different strategies, multi-step ping/post, buyer caps by day, week, month, and lifetime, schedules with timezones, and filters at four levels with 14 condition types.
- **Call Logic:** pay-per-call on the same platform with managed telephony, number pool management, IVR, agent routing, call recording, call logs with a full event timeline, a per-buyer minimum call duration, and a call conversion postback that updates the same ledger your leads settle on.
- **Lynx and click attribution:** click tracking with server-side conversions and blended EPC reporting, attributed back to the lead and the sale.
- **Opt-Intel style hygiene:** Blacklist Alliance DNC and litigator scrubbing enforced as a hard gate at ingest, plus Anura and IPQS fraud scoring, email and phone validation, and Array credit qualification, 14 integration providers total, each with a rule engine deciding accept or reject per lead.
- **What Phonexa's reports do not show:** every rejection in Datahubb carries the exact rule that fired, is grouped and ranked by estimated missed revenue, and recoverable leads can be redistributed to the buyers that skipped them. Phonexa's documentation shows reject counts and rejection events; the money behind them is your spreadsheet's problem.

**What stays with your current tools:** consumer email and SMS nurture, and accounting. Datahubb delivers leads to buyers; it is deliberately not a marketing automation or bookkeeping product. If you rely on those Phonexa modules daily, weigh that honestly.

**Switching is de-risked three ways:** Datahubb's team rebuilds your campaigns, buyers, filters, and payout rules from exports, free. You can mirror live traffic alongside Phonexa for 2 to 4 weeks before cutting over. And if you are still under a Phonexa contract, Datahubb discounts your subscription until it ends. Full side-by-side on the [Datahubb vs Phonexa page](https://datahubb.io/vs/phonexa).

**Best for:** lead and call operators who want published flat pricing and the distribution loop, not a nine-product estate.

## 2. Boberdoo: the deep-config veteran

Boberdoo is the most established name in lead distribution, with a deep reporting suite and an extensive API. It publishes a pricing calculator, $500/month promo for 3 months plus $250 setup, then volume tiers from $1,075/month at 25 leads per day, and remains demo-gated with no trial. Call routing requires bringing your own Twilio account, and rejection reasons are not logged per lead for later analysis, per its own docs.

**Best for:** high-volume operations that want battle-tested custom routing and accept volume-tiered pricing. See [Datahubb vs Boberdoo](https://datahubb.io/vs/boberdoo).

## 3. Lead Prosper: focused and transparent

Lead Prosper publishes its full rate card: $500/month including 5,000 leads, then per-lead overage tiers that fall with volume. Same features at every tier, unlimited suppliers and buyers, lifetime lead storage. It is data leads only, no call product, so it replaces LMS Sync but not Call Logic. About $2,300/month at 100,000 leads by its own published rates.

**Best for:** data-lead operations that do not need calls. See [Datahubb vs Lead Prosper](https://datahubb.io/vs/leadprosper).

## 4. LeadsPedia: the affiliate-network suite

Closest to Phonexa in spirit: a comprehensive suite for large affiliate networks, with published pricing at $1,500/month for Lite and $2,500/month for Premium. Watch the entry-tier usage caps (25,000 leads, 1,000,000 pings, 150,000 clicks per month on Lite) and note that margin and P&L reporting are not advertised. No trial listed.

**Best for:** large affiliate networks wanting a guided enterprise rollout. See [Datahubb vs LeadsPedia](https://datahubb.io/vs/leadspedia).

## 5. Ringba: calls, done deeply

If your Phonexa usage is really just Call Logic, Ringba is the dedicated pay-per-call alternative, with a free tier and self-serve access. It has no web-lead distribution, so mixed shops end up running two platforms, which is usually what they were trying to escape.

**Best for:** call-only operations.

## 6. LeadByte: the UK and EU option

A mature UK-based platform with configurable validation and six distribution methods including multi-sell. Quote-based pricing, 30-day rolling contracts, no setup fee, no listed trial. Strongest for UK and EU traffic and buyers.

**Best for:** European operators. See [Datahubb vs LeadByte](https://datahubb.io/vs/leadbyte).

## How to choose

- **You use two of Phonexa's nine products:** you are paying suite prices for a loop. Datahubb publishes the loop at $499 flat.
- **You use six of the nine:** stay on a suite. Compare Phonexa against LeadsPedia and negotiate.
- **Calls only:** Ringba.
- **You want to see the product before any call:** Datahubb's 14-day trial is the only self-serve full-platform trial on this list.

## Frequently asked questions

**How much does Phonexa cost?**
Phonexa does not publish pricing as of August 2026. Its pricing page describes LMS Sync and Call Logic packages sized by ping and minute volume, with every path ending in a custom quote. Any specific dollar figure you see quoted for Phonexa is either negotiated or guessed.

**What is the best Phonexa alternative with published pricing?**
Datahubb at $499/month flat, Lead Prosper at $500/month plus metered leads, and LeadsPedia at $1,500/month are the published-price options in this space. Datahubb is the only one of the three with no volume caps and a self-serve trial.

**Can one platform really replace both LMS Sync and Call Logic?**
For the distribution loop, yes: Datahubb routes web leads and pay-per-call on one ledger, with managed telephony, call recording, and call conversion postbacks. What it does not replace is Phonexa's email marketing or accounting modules; those stay with your existing tools.

**Does Phonexa offer a free trial?**
No trial is listed as of August 2026. The site offers a product tour, a demo, and a custom quote.

**How long does migrating off Phonexa take?**
The pattern that removes the risk is a 2 to 4 week parallel run: mirror a slice of live traffic through the new platform alongside Phonexa, compare sold rate, margin, and rejection reasons, then cut over. Datahubb rebuilds your campaigns, buyers, filters, and payout rules from exports for you, free, and you review every mapping before anything goes live.

---

*Comparisons reflect publicly available information from each vendor's own site, last checked August 2026, and may have changed since. Datahubb is not affiliated with any company named above.

### Best Boberdoo Alternatives in 2026: 6 Platforms, Verified Pricing

URL: https://datahubb.io/blog/best-boberdoo-alternatives
Published: 2026-08-05

> Six Boberdoo alternatives compared on verified pricing, trial access, rejection recovery, and routing depth. Every figure checked against the vendor's own published pages in August 2026.

Boberdoo has run lead distribution longer than almost anyone, and it earned its position: deep routing configs, an extensive API, and a vendor directory the industry actually uses. But its pricing scales with your lead volume, signup is still gated behind a demo, and the platform tells you that a lead went unmatched without reliably telling you why. If any of those three is the reason you are searching, this comparison is for you.

**How this list was built:** every pricing figure below was checked against the vendor's own published pricing page in August 2026, and each entry says what the platform genuinely does well before saying where it falls short. Where a vendor publishes nothing, we say "custom quote" instead of guessing. Several popular roundups in this category claim Boberdoo has no published pricing; that is out of date. Boberdoo publishes a full pricing calculator. What it does not offer is a trial or self-serve signup.

## Why operators look for a Boberdoo alternative

Three reasons come up over and over:

1. **Volume-tiered pricing.** Boberdoo's published calculator starts at a $500/month promo for 3 months (plus a $250 setup fee), then moves to $1,075/month at just 25 leads per day and climbs with volume to $8,375/month at 5 million leads per day. Growing your business raises your bill.
2. **No trial.** Boberdoo publishes its prices but gates signup behind a demo request or a sales call. You cannot route a lead before you talk to someone.
3. **Rejection blindness.** Boberdoo's own documentation states that its unmatched-reasons tool is real-time only and is "not logging the unmatched reasons for every filter set for every lead for later reference," and that the platform "cannot always recite the exact reason that the lead went unmatched." If a buyer rejected 400 of your leads last week, reconstructing why, and what it cost you, is on you.

## The alternatives at a glance

| Platform | Entry price (verified Aug 2026) | Trial | Rejection recovery | Calls + leads |
|---|---|---|---|---|
| Datahubb | $499/mo flat, any lead volume | 14-day, self-serve | Per-rule reasons, missed-revenue estimate, redistribution | Yes, one platform |
| Lead Prosper | $500/mo incl. 5,000 leads, then per-lead tiers | None listed | Lead returns, real-time analytics | Leads only |
| Phonexa | Custom quote, not published | None listed | Reject counts and events in reports | Yes, via separate modules |
| LeadsPedia | $1,500/mo (Lite), usage caps apply | None listed | Return handling | Yes, call tracking module |
| LeadByte | Not published, quote on request | None listed | Sold/unsold/error monitoring | Leads only |
| Ringba | Free tier plus usage | Self-serve | Call-side only | Calls only |

## 1. Datahubb: flat pricing plus rejection recovery

[Datahubb](https://datahubb.io) is an all-in-one lead distribution platform: ingestion, validation, filtering, distribution, pay-per-call, click tracking, postback reconciliation, and analytics in one system, at a published $499/month flat for the basic feature set at any lead volume ($424/month billed annually). There is no setup fee and the 14-day trial is self-serve with full platform access.

**Where it directly answers the three Boberdoo complaints:**

- **Pricing axis.** Datahubb prices by feature tier, not volume. 25 leads per day and 25,000 leads per day cost the same $499. Boberdoo's own calculator puts 25 leads per day at $1,075/month after the promo.
- **Trial.** Open an account in about 15 minutes, route real leads, and talk to sales only if you want to.
- **Rejection clarity.** Every rejection carries the exact rule that fired: the filter field, operator, and expected value next to the lead's actual value, the schedule window missed, or the cap that was full. Rejections are grouped, ranked by estimated missed revenue (unrecovered leads times average sold price times sell-through rate), broken down across nine dimensions including buyer, campaign, and traffic source, and paired with a generated action plan. Soft-rejected leads, ones every buyer skipped only on schedule or caps, can be redistributed to the buyers that skipped them, with schedules and caps re-checked live.

**Routing depth, the thing Boberdoo veterans worry about:** four distribution strategies (Waterfall, Highest Bidder, Weighted with self-correcting share targeting, and Advanced tiers where each tier carries its own sub-distribution and minimum payout floor), plus routing rules that let one campaign run different strategies for different traffic slices with a first-match-wins rule list. Ping/post supports multiple sequential ping steps per buyer with per-step timeouts, and a rule-based response mapper turns any buyer's response format into accepted, rejected, duplicate, pending, or error, with the price and rejection reason extracted.

**Migration is done for you.** Datahubb's team imports your buyers, campaigns, filters, and payout rules from a Boberdoo export, free, and you can mirror a copy of live traffic through Datahubb alongside Boberdoo for 2 to 4 weeks before cutting over. Teams still inside a contract get discounted pricing until that contract ends. The [Boberdoo comparison page](https://datahubb.io/vs/boberdoo) has the full side-by-side, and the [migration overview](https://datahubb.io/vs) maps each Boberdoo concept to its Datahubb equivalent.

**Where Datahubb is not the answer:** it picks a single winner per distribution run, so if you sell the same lead non-exclusively to several buyers at once, that workflow needs planning rather than a straight port. It also does not do consumer email or SMS nurture; delivery to buyers is not marketing automation.

**Best for:** operators doing meaningful volume who want a flat bill, visibility into every rejection, and leads plus calls on one ledger.

## 2. Lead Prosper: transparent metered pricing

Lead Prosper deserves real credit for transparency: its full rate card is published with a calculator, which is rare in this category. $500/month includes 5,000 leads and 200,000 pings, then each additional lead bills by volume tier, from $0.05 down to $0.0005 per lead as volume grows. Every plan gets the same feature set, suppliers and buyers are unlimited, and lead storage is lifetime.

The trade-off is the meter itself. At 100,000 leads per month, Lead Prosper's own published rates total about $2,300/month. It also lists no call product, so pay-per-call operations need a second platform, and no free trial is listed.

**Best for:** data-lead operations at modest volume that value a clean, focused tool and published rates. See the full [Datahubb vs Lead Prosper comparison](https://datahubb.io/vs/leadprosper).

## 3. Phonexa: the full-suite route

Phonexa is the broadest suite in the space: LMS Sync for leads, Call Logic for calls, plus email, a cloud phone system, click tracking, suppression management, and accounting under one vendor, with managed onboarding included. If you want one enterprise vendor for your whole marketing operation and have the budget, it is a serious option.

Pricing is custom quote only, with packages sized by ping and minute volume, and no trial is listed. You will not know your price until you have sat through the process, which is the same friction that sends people away from Boberdoo. Its documentation shows reject counts and rejection events in reports, without a missed-revenue view.

**Best for:** teams that want the whole marketing stack from one enterprise vendor. See the full [Datahubb vs Phonexa comparison](https://datahubb.io/vs/phonexa).

## 4. LeadsPedia: enterprise affiliate networks

LeadsPedia publishes its pricing, $1,500/month for Lite and $2,500/month for Premium, and is a comprehensive suite for large affiliate networks that want deep configuration and a guided rollout. Note the usage caps: the Lite plan caps monthly usage at 25,000 leads, 1,000,000 pings, and 150,000 clicks. Real-time campaign analytics are advertised; margin and P&L reporting are not. No trial is listed.

**Best for:** large affiliate networks with the budget for a bespoke enterprise rollout. See the full [Datahubb vs LeadsPedia comparison](https://datahubb.io/vs/leadspedia).

## 5. LeadByte: the UK and EU choice

LeadByte is a mature, flexible platform for UK and European lead sellers, with configurable validation and six distribution methods including multi-sell, something most platforms in this list, Datahubb included, do not offer natively. Contracts are 30-day rolling with no setup fee. Pricing is not published, you request a quote, and no free trial is listed. Its market center of gravity is the UK and EU.

**Best for:** UK and EU operators, and anyone whose business depends on selling the same lead to multiple buyers simultaneously. See the full [Datahubb vs LeadByte comparison](https://datahubb.io/vs/leadbyte).

## 6. Ringba: if your business is calls

Ringba is the loudest name in pay-per-call, with a free tier and self-serve access. It is calls only: no web-lead distribution, so lead-and-call shops need a second platform alongside it, and usage line items add up with scale.

**Best for:** call-only operations.

## How to choose

- **Route 25 to 25,000+ leads a day and hate volume-tier jumps:** Datahubb or, at lower volume, Lead Prosper.
- **Want the broadest possible suite and have enterprise budget:** Phonexa or LeadsPedia.
- **UK or EU centered, or multi-sell is non-negotiable:** LeadByte.
- **Calls only:** Ringba.
- **Want to try before you talk to anyone:** Datahubb is the only platform on this list with a 14-day self-serve trial.

## Frequently asked questions

**Does Boberdoo publish its pricing?**
Yes. As of August 2026 Boberdoo publishes a pricing calculator on its site: a $500/month promo for 3 months plus $250 setup, then volume tiers from $1,075/month at 25 leads per day up to $8,375/month at 5 million per day, with add-ons like LeadQC at $0.20 per lead and consulting at $195 per hour. What Boberdoo does not offer is a free trial or self-serve signup. Claims that its pricing is entirely custom are out of date.

**What is the best Boberdoo alternative for high volume?**
If you want your bill to stop scaling with volume, Datahubb's $499/month flat covers any lead volume on the basic feature set. Boberdoo's own tiered model is genuinely fair for enterprises at millions of leads per day, and its team should get that credit.

**Which alternatives offer a free trial?**
Datahubb offers a 14-day self-serve trial with full platform access, card required but nothing charged if you cancel during the trial. Boberdoo, Phonexa, LeadsPedia, LeadByte, and Lead Prosper list no free trial as of August 2026.

**Can I migrate off Boberdoo without downtime?**
Yes. The standard approach is a parallel run: mirror a copy of live traffic through the new platform alongside Boberdoo for 2 to 4 weeks, compare sold rate, margin, and rejection reasons on your own leads, then cut over. Datahubb does the import of buyers, campaigns, filters, and payout rules for you, free.

**Which platform shows why leads were rejected?**
Boberdoo's docs state its unmatched-reasons tool is real-time only and reasons are not logged per lead for later reference. Phonexa reports reject counts and events. Datahubb records the exact rule that fired on every rejection, prices each rejection reason in estimated missed revenue, and can redistribute recoverable leads to the buyers that skipped them.

---

*Comparisons reflect publicly available information from each vendor's own site, last checked August 2026, and may have changed since. Datahubb is not affiliated with any company named above.*

### What Happens When an Affiliate Network Decides to Own the Offer

URL: https://datahubb.io/blog/affiliate-network-own-lead-gen-brand
Published: 2026-08-04

> An affiliate network built its own auto insurance brand from scratch. What the transition involved, what took longer than planned, and what we would do differently.

**When an affiliate network launches its own lead generation brand, it stops being a middleman and becomes the advertiser. That means owning the traffic, the compliance, the buyer relationships, and the margin. This is what that transition looked like for one network in the auto insurance vertical, including the parts that took longer than planned.**

Most affiliate networks eventually have the same conversation. You are running other people's offers, taking a margin on volume you do not control, and watching the advertiser capture the difference between what a lead costs and what it is actually worth. At some point somebody asks the obvious question: why are we not running our own?

The Fellas Ads asked it in early 2025. They came to us wanting to build a branded auto insurance property they could run whitehat traffic to, owned by them, sold by them. That brand became [Quote Scouts](https://quotescouts.com/).

What follows is what the transition actually involved. Not the pitch version.

## Owning the Offer Changes What Your Business Is

A network sells access. A brand sells leads.

That sounds like a small distinction until you look at what changes underneath it. As a network you negotiate payouts and route volume. As a brand you own the landing page, the consent language, the data quality, the buyer relationships, and the reconciliation when something goes wrong. Nobody upstream absorbs the problem for you anymore.

The work split into three things: collecting the data, verifying it, and distributing it. We started with consultancy on the landing page itself, because in this vertical the form is not a formality. It is the constraint the entire business runs into.

## Why Auto Insurance Is Harder Than It Looks

Auto insurance buyers require a lot of fields in [the ping request](https://datahubb.io/platform/lead-distribution). Vehicle details, driver history, coverage status, residence, and more depending on the buyer. Each required field is another question in the funnel.

That creates a direct tension nobody warns you about. The more complete your ping payload, the more buyers can bid on it and the higher your payout. The longer your funnel, the lower your conversion rate. Every field you add to satisfy a buyer costs you consumers at the top.

You cannot resolve that tension. You can only manage it deliberately, which means knowing exactly which fields earn their place and which are there because a buyer asked once and nobody removed them.

Then there is the vehicle data itself. New models come to market constantly. If a consumer selects a car your system does not recognize, or types it in free form, the payload breaks at the buyer's API and the lead is worthless. We built a dedicated Cars API so every make and model resolves correctly before the ping goes out. Unglamorous infrastructure, and the difference between a lead that sells and a lead that fails validation.

## The Part That Took Longest Was Not Technical

If you had asked us at the start what would slow the project down, we would have guessed integrations.

It was the team.

Running an affiliate network and running an auto insurance brand are different jobs. The affiliate side knows traffic, payouts, and partner management. The brand side needs distribution configuration, margin monitoring, buyer performance reporting, quality conversations with buyers, and in many cases internal media buying. Same people, largely new discipline.

We ran education alongside the build for exactly this reason, and the learning curve was still slower than we expected. That is not a criticism of the team. It is a scheduling reality that anyone planning this transition should build into their timeline rather than discover halfway through.

The second underestimation was on the sales side: connecting the right buyers, at a payout that works, with a feedback loop you can actually use. Sales treated buyer acquisition as a contract to close. It is closer to an integration to maintain.

## Most Buyers Cannot Tell You What Is Wrong in Real Time

This is the thing we would most want a new brand owner to understand before they start.

You will send volume to a buyer. The buyer will accept it for a while. Then they will pause you, because they have run their own validation and something in your inventory did not hold up. At that point you want to know what, specifically, so you can fix it.

Most buyers cannot tell you. They do not have the systems to return granular, real-time feedback through an API. What you get is a pause, a phone call, and a general impression.

Without a tight feedback loop you are running trial and error with real money. You scale into a buyer, get paused, guess at the cause, adjust, and try again. That is a slow and expensive way to learn what your own data is worth.

The practical consequence is that buyer selection is not only about payout. A buyer paying slightly less who tells you precisely why a lead failed is worth more than a buyer paying more who tells you nothing.

## Making Rejection Legible to People Who Are Not Engineers

The Quote Scouts team could not easily see why a lead failed to sell in the ping request. That is a normal state of affairs and it is a quiet margin killer, because the people closest to the traffic are usually not the people who can read an API response.

We built a detailed ping-level view in Datahubb so the team could see, per lead, which buyers bid, which declined, and on what basis. Later we added the same for posted leads that were rejected technically at the buyer's API.

The design requirement was that a non-technical operator had to be able to read it. Not a stack trace. Plain language, per reason, aggregated so you can see whether you have one bad lead or a pattern with one buyer.

That module became the first version of what is now the [rejection analysis in Datahubb](https://datahubb.io/platform/rejection-insights), designed with the Quote Scouts team against their actual daily workflow.

## Routing the Consumer Without the Consumer Noticing

Once the buyer side was working, the front end had to reflect it. Different buyers, different consumer journeys, different next steps depending on what the consumer entered.

The platform resolves the auction and loads the corresponding thank you page or handoff in a split second, server side. The consumer sees one continuous experience. Behind it, the routing decision has already been made.

Owners got the view they actually wanted on top of that: revenue, cost, and profit, without anyone rebuilding it in a spreadsheet.

## Where It Landed

Quote Scouts was built from scratch in roughly three months and launched in 2025. Between April 2025 and February 2026 the brand connected 13 buyers and generated 2,561 leads, run by a core team of five: an affiliate manager, a sales manager, two owners, and Datahubb on the technical side.

Those are launch numbers, not scale numbers, and that is the honest framing. What the project actually produced was a working brand with a buyer base, a team that can operate it, and visibility into where leads fail. That is the foundation volume gets built on. Scaling into a stack you cannot see is how operators lose money faster.

## If You Are Considering This

Three things we would tell any network thinking about owning its own offer.

**Fix your sales process before you generate a single lead.** This gets underestimated more than anything else. Being able to sell leads, understanding what consumer data is actually worth, and maintaining real feedback loops with buyers is the whole game. Traffic is the easy part.

**Weight buyers by feedback quality, not only payout.** You are going to be diagnosing problems constantly in the first year. A buyer who cannot tell you why they rejected something is a buyer you cannot improve against.

**Look at verticals with less competition and higher payouts.** Media costs have risen sharply. You are paying Meta, TikTok, or an email provider directly now, and pulling leads out of a crowded market costs real money. The margin has to exist before you start.

## Frequently Asked Questions

### Should an affiliate network build its own lead generation brand?

It can be worth it when the network already has traffic relationships and wants to capture advertiser margin instead of network margin. The trade is control for responsibility: you take on compliance, data quality, buyer relationships, and reconciliation. It works best when the sales capability exists before launch.

### What makes auto insurance lead generation technically difficult?

Buyers require many fields in the ping request, which lengthens the consumer funnel and lowers conversion. Vehicle data also changes constantly, so unrecognized makes and models break payloads at the buyer's API. Both problems need to be solved before volume is worth chasing.

### How long does it take to launch a lead generation brand?

Quote Scouts was built from scratch in about three months before launch, with the team transition continuing well past that point. The build is rarely the constraint. Connecting buyers and retraining the team to operate a brand rather than a network takes longer.

### Why do lead buyers pause a source without explaining why?

Most buyers do not have systems that return granular, real-time rejection feedback through an API. They run internal validation, see an aggregate problem, and pause. This is why the quality of a buyer's feedback loop matters as much as their payout when you are choosing who to work with.

### What is a rejection reason in ping post distribution?

A rejection reason records why a specific buyer declined a specific lead, either during the ping auction or after the post at their API. Aggregated across buyers and sources, rejection reasons show whether a problem is one bad lead or a systematic mismatch with a particular buyer.

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

URL: https://datahubb.io/blog/pre-ping-fraud-validation
Published: 2026-07-30

> Why fraud validation belongs before the ping, not after the post. Real rejection numbers, the server-side trade-off, and what verification actually costs.

**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.

### The buyer integration playbook

URL: https://datahubb.io/blog/the-buyer-integration-playbook
Published: 2026-07-16

> Onboarding a buyer is where lead operations quietly break. A stage-by-stage playbook: the questions to ask up front, the config that bites, and how to test before you send real leads.

Every buyer you add is a new integration, a new set of expectations, and a new way for your operation to break at 2am. Most operators treat buyer onboarding as a config task — fill in the endpoint, map the fields, turn it on. Then spend the next three weeks discovering what nobody asked about during setup.

Buyer integration is a project with a predictable failure pattern. The failures are almost never exotic. They're the same eight or nine things, every time, and they're all preventable by asking the right questions before touching a form.

This is the playbook.

## Stage 1: The conversation before the config

Do this before you open any configuration screen. Most integration pain traces back to a question nobody asked here.

**Commercial terms:**

- What are they paying, and per what? Per delivered lead, or per conversion?
- If it's per conversion: what counts as a conversion, who decides, and how long do they get to decide? A conversion window you didn't agree on is a receivable you can't age.
- Is there a volume commitment in either direction?
- What's the return policy — what window, what reasons, what evidence?

**Technical terms:**

- What's the endpoint, and what does it expect? Get their documentation before you promise a timeline.
- **How do they signal acceptance versus rejection?** Ask for real example responses of both. Not the schema — the actual payloads. This is the single highest-value artifact you can get from a buyer, and it's the one most often skipped.
- Where in their response is the price, if they're bidding?
- Where in their response is the rejection reason?
- What are their required fields, and what do they do when one is missing — reject, or accept and silently drop it?
- Do they dedupe on their side? On what key, over what window?

**Operational terms:**

- What hours do they actually want leads? In what timezone?
- What's their daily capacity, and what happens when you exceed it — do they reject cleanly, or do they accept leads they can't work?
- Who do you call when something breaks, and what's their response time?

That last question about capacity matters more than it sounds. A buyer that accepts everything and works nothing looks great in your reports for about a month, and then your return rate arrives all at once.

**Write the answers down.** The rest of the playbook is executing against them.

## Stage 2: Delivery method and pricing model

Two decisions that constrain everything downstream.

**Delivery method** — how the lead gets to them:

- **Direct post** — one call, full record, they accept or reject. Simplest. Right when the price is fixed and known.
- **Ping/post** — a thin ping to get a bid or an interest signal, then a post with the full record if they win. Right when they price dynamically. Costs you a round trip and a second integration surface.
- **Email or store-only** — real, and appropriate for buyers who can't take an API. Understand you're giving up real-time everything.

**Pricing model** — when revenue is real:

- **Per delivered lead** — revenue books at delivery. Clean.
- **Per conversion** — revenue books at confirmation. The lead sits pending until they tell you what happened.

The conversion model has a consequence people don't plan for: **a pending sale is not revenue.** Between delivery and confirmation, the lead has been committed to that buyer, it isn't going anywhere else, and you've booked nothing. Your reports will show it as pending, not sold, and that's correct — booking it as revenue at delivery and reversing it later is how you get phantom revenue that your finance team eventually notices in a bad way.

The other consequence is routing: a conversion-priced buyer has no bid to compete with, so putting them in a head-to-head auction against delivery-priced buyers doesn't work. They belong in a lower tier with no price floor. That's a routing decision made at integration time, and it's easier to get right now than to unpick later.

## Stage 3: Payload mapping

You have fields. They want fields. The mapping between them is where the tedium lives.

Three distinct problems, often conflated:

**Field naming.** Their `zip_code` is your `zip`. Mechanical, template-level, boring, fine.

**Value formatting.** You hold `CA`; they want `California`. You hold a 10-digit string; they want `+1` prefixed. You hold `1990-12-31`; they want `12/31/1990`. This is transformation — the same value, reshaped.

**Value vocabulary.** You hold `Excellent`; their enum only accepts `A`. You hold `Homeowner`; they want `1`. This is a lookup table, not a format change, and it's worth keeping separate from formatting in your head because it changes for business reasons, not technical ones.

Practical rules:

- **Transform on the way out, never in the database.** The lead is the lead. What a buyer wants is that buyer's problem, and if you normalize your stored data to buyer A's vocabulary, you've made buyer B's integration harder forever.
- **Fill the blank before you map it.** A default applied after a lookup is a default the lookup never saw. Order matters in a transform chain: fallback first, then map, then type coercion last.
- **Omit rather than send empty.** Buyers that validate strictly will reject `{"middle_name": ""}` where they'd have accepted the key not being there at all. If your platform can drop a key conditionally, use it — and know that **an empty string is not null.** A field that exists and is blank will not trip an existence check. This one detail accounts for a genuinely surprising share of "why did they reject that."
- **Beware silent no-ops.** In most template engines, an unrecognized transformer name doesn't error — the value just passes through untouched. Your config looks right, the value looks wrong, nothing logs. Copy transformer names from documentation, never from memory, and verify with a test post rather than by reading your own config.

## Stage 4: Response mapping — where it actually breaks

If one stage causes more production incidents than the rest combined, it's this one.

You must teach your platform to read the buyer's answer. Which response means accepted, which means rejected, which means duplicate, which means "my server is on fire, try again." Get this wrong and the failure is silent and expensive in both directions:

- **Reading a rejection as an acceptance** — you book revenue for a lead the buyer threw away. It reconciles badly at month end.
- **Reading an acceptance as a rejection** — you fall through to the next buyer and sell a lead you already sold. Now you have a compliance problem, not a reporting problem.

The rules:

- **Match on real responses, not on the documentation.** Docs describe the happy path. Ask for a real accepted response and a real rejected response, then match against those bytes.
- **Test the rejection path explicitly.** Everyone tests acceptance. Almost nobody sends a lead they know will be rejected to confirm it reads as a rejection. Do it — deliberately send a lead that fails their validation and watch what your platform concludes.
- **Beware substring matching.** A rule looking for `"duplicate"` anywhere in the response will happily match `"no duplicate found"`. Match on structure — a specific field at a specific path — not on the response containing a word.
- **Capture the rejection reason.** If they tell you *why*, store it. Rejection reasons are the highest-signal data in your operation; a buyer who's telling you why and an operator who isn't listening is a wasted feedback loop.
- **Decide what an error means.** A timeout is not a rejection. A 500 is not a rejection. If you treat infrastructure failures as "this buyer doesn't want this lead," you'll fall through to your next buyer every time their server hiccups and never notice they were down for an hour.

## Stage 5: Postbacks and confirmation

If the buyer pays on conversion, they need to tell you when a conversion happens. That's an inbound postback, and it has three requirements:

- **An identifier that ties back to a specific record.** They post back with the id you gave them at delivery. Whatever identifier scheme you use, the buyer must echo the one you sent, and it must be unambiguous about which sale it refers to — the lead alone often isn't enough if the same lead touched multiple buyers.
- **A status, and agreement on the vocabulary.** Here's a trap: most systems normalize an *unrecognized* status to accepted. `declined` maps to rejected; `declined_pending_review` might not, and would land as an acceptance. Confirm the exact status strings they'll send, and confirm what your side does with a string it doesn't recognize.
- **Idempotency.** Networks retry. Buyers re-send. A confirmation that arrives twice must not book revenue twice. If you're building this yourself, key on the transaction and short-circuit the repeat.

Also set the expiry: if a conversion window passes with no word, the pending sale resolves to rejected on its own. Without that, pending sales accumulate forever and your pending bucket becomes a graveyard nobody trusts.

## Stage 6: Test before you send anything real

Non-negotiable. The order that works:

1. **Send a test payload to their endpoint.** Verify it's reachable, your credentials work, your headers land. You're testing plumbing, not logic.
2. **Send a lead you expect to be accepted.** Confirm your platform reads acceptance correctly, extracts the price correctly, and books it correctly.
3. **Send a lead you expect to be rejected.** Confirm you read the rejection as a rejection, and that you captured the reason. This is the step people skip.
4. **If they bid: verify the price you extracted matches the price they sent.** Off-by-a-field-path errors here are quiet and expensive.
5. **If it's ping/post: verify the post carries what the ping promised**, and that a lost ping doesn't post.
6. **If it's conversion-priced: fire a confirmation postback yourself** and watch the pending sale resolve. Then fire it twice and confirm it doesn't double-book.
7. **Read the logs, not the summary.** The request you actually sent, the response they actually returned. Summaries hide the field-level problem you're looking for.

One caution: understand exactly what your platform's test mode does. Test paths commonly bypass validation, deduplication, and fraud checks, and route to a dummy buyer — which is useful for testing *your* pipeline, and useless for testing *this buyer's* integration, because the real buyer never gets called. Those are different tools for different jobs. Make sure you know which one you're holding, or you'll conclude an integration works when nothing ever reached them.

## Stage 7: Caps, schedule, and position

Before you turn it on:

- **Caps.** Daily, weekly, monthly, and lifetime where it's available. Set them from the capacity conversation in Stage 1. A new buyer with no cap is an unbounded promise to a partner you've never worked with.
- **Schedule.** With the timezone. A buyer set to business hours in the wrong timezone gets leads at 3am, works none of them, and returns them all. Timezone bugs in delivery schedules are a genuine classic.
- **Position.** Where does this buyer sit — first in the waterfall, in the auction, in which tier, at what weight? A new buyer dropped into a weighted campaign will take a **catch-up burst** of volume on day one, because its realized share starts at zero and the engine is trying to close that gap. Expect it. Don't panic-adjust the weight while it's happening.

## Stage 8: Go live small, and watch

Don't cut full volume to a new buyer on day one.

- **Start at a fraction** of the volume you intend. A cap is the easiest throttle you have.
- **Watch the acceptance rate for the first day.** An acceptance rate near 100% or near 0% almost always means a response-mapping problem, not a quality signal. Real acceptance rates live in between.
- **Watch the rejection reasons.** A single reason dominating on day one is a mapping bug in disguise.
- **Watch latency.** A buyer that's slow in testing is slower under volume, and in an auction a slow buyer just doesn't compete.
- **Reconcile at the end of week one.** Your count against their count. Do it before it's a month of drift and a conversation about money.

Then ramp. The first week at low volume costs you a little revenue and saves you the incident.

## Common failure modes

| Symptom | Usual cause |
|---|---|
| Buyer receives nothing | Inactive, at cap, outside schedule, or filtered out before they're even considered |
| Buyer receives nothing, in a tiered setup | Their tier's price floor is above their bid — a zero-price buyer under a non-zero floor qualifies for nothing |
| Acceptance rate is 100% or 0% | Response mapping, not lead quality |
| Price comes through wrong or zero | Extraction pointing at the wrong path in their response |
| Pings time out | Their endpoint is slow; check whether repeated failures are tripping a circuit breaker and skipping them entirely |
| Header values arrive empty | Placeholder syntax wrong, or the field genuinely isn't in the payload |
| A conditionally-omitted key still sends | The field is an empty string, not null — empty is not absent |
| Multi-step ping fails on step 2 | Step 2 is referencing a field from step 1's response that isn't shaped the way you assumed |
| Conversion-priced lead "stuck" in pending | Not stuck. That's the model. It resolves when they confirm, or when the window expires |
| Revenue disagrees with theirs at month end | Returns, timezone boundaries on the reporting day, or acceptances you read as rejections |

Most of that table is Stage 1 and Stage 4 coming back around. The commercial questions you didn't ask, and the responses you mapped from documentation instead of from reality.

## The takeaway

Buyer integration fails in predictable places: the questions nobody asked before the config, and the response mapping nobody tested against a real rejection.

Get their real accepted and rejected responses before you build. Transform outbound, never in your data. Test the rejection path, not just the happy path — and know whether your test mode is actually calling the buyer or a stand-in. Go live at a fraction of volume and reconcile in week one, while a discrepancy is still a conversation instead of an invoice.

None of this is difficult. It's just work that has to happen before the leads flow, and the entire cost of skipping it is paid later, at a worse time, in front of a buyer.

### Duplicate detection and fraud gatekeeping: what to stop before distribution

URL: https://datahubb.io/blog/duplicate-detection-and-fraud-gatekeeping-what-to-stop-before-distribution
Published: 2026-07-16

> Every lead you block at the gate is a return you don't have to argue about later. Here's how to order your checks, what to reject, and what to sell cheaper instead.

A bad lead that reaches a buyer costs you three times: the payout you clawed back, the time your team spent arguing about it, and the buyer's confidence in your inventory. That last one is the expensive one, and it doesn't show up in any report.

Gatekeeping is the work of catching those leads before they leave the building. It's unglamorous, it's mostly configuration, and it's the highest-leverage thing in an operation that's growing faster than its quality controls.

This is how to think about the gate: what to check, in what order, and — the part most operators get wrong — what to *not* reject.

## Pipeline order is the whole design

Before any specific check, understand the sequence. Gatekeeping isn't a switch, it's a pipeline, and the order of stages determines what each stage can even see.

A well-built ingestion pipeline runs roughly this order:

1. **Authenticate and resolve** — verify the source's credentials, resolve which campaign this lead belongs to.
2. **Source caps** — is this source over its volume allowance?
3. **Create the record** — the lead now exists, in a pending state, so everything after this is auditable.
4. **Validate the payload** — required fields present, types correct, values in range.
5. **Blacklist / DNC scrub** — the hard gate. Cheapest and most legally consequential.
6. **Credit and eligibility checks** — where applicable to the vertical.
7. **Lead filters** — your own business rules.
8. **Duplicate check** — have we seen this person?
9. **IP and device fraud** — proxy, VPN, bot, datacenter.
10. **Phone and email validation** — is this contact reachable and real?
11. **Buyer selection and distribution** — only now does anyone outside your system see the lead.

Two things fall out of that ordering, and both matter more than they look.

**Everything through step 10 is pre-distribution.** A duplicate never reaches a buyer. A blacklisted number never reaches a buyer. If your gate is configured correctly, the failure modes your buyers complain about are ones you chose to allow.

**A check can only see what ran before it.** This is the ordering trap, and it generates more support tickets than any other gatekeeping issue. If your filters run before your fraud vendors, your filters cannot reference fraud scores — the fields don't exist yet. Operators write a filter on a fraud score, watch it never fire, and conclude the integration is broken. It isn't. The filter is just standing upstream of the data it wants.

When a filter that references enriched data won't fire, the first question is never "is the vendor working." It's "does this field exist yet at the point this filter runs."

## Duplicate detection: three decisions

Duplicate checking looks like one setting. It's three, and they're independent.

### Decision 1: Scope

What do you compare against?

- **Campaign-wide** — has *anyone* in this campaign seen this person? Prevents ever selling the same person twice, to anyone.
- **Buyer-level** — has *this specific buyer* seen this person? The same lead can go to a different buyer without issue.

This is a business decision disguised as a config field. Campaign-wide is conservative: you protect the buyer relationship at the cost of volume you could have sold. Buyer-level is permissive: the same consumer legitimately shops multiple carriers, and selling that person to a second buyer who's never seen them isn't fraud, it's the market working.

Which is right depends on what you told your buyers. If you sold exclusivity, campaign-wide is the only honest setting. If your buyers know they're getting shared inventory, buyer-level is leaving less money on the table.

Note what's *not* on the list: cross-campaign deduplication. Duplicate scope is bounded by the campaign. If you're running the same vertical across two campaigns and expecting dedupe between them, you won't get it, and that's a structural fact to design around rather than configure away.

### Decision 2: Matching strategy

- **All configured fields must match** — strict. Same phone *and* same email *and* same IP. Very few false positives, more misses.
- **Any single field matches** — loose. Same phone is enough. Catches far more, at the cost of collisions.

The loose setting has a real failure mode people underestimate: **shared IP addresses.** Put IP in a one-field-match dupe check and you will reject the second person who submits from a household, an office, a university, or a mobile carrier's NAT pool. Those are real leads. You just deleted them and logged it as a duplicate.

**IP is a fraud signal, not an identity signal.** It belongs in your fraud checks, not usually in your dupe key.

### Decision 3: Lookback window

How far back do you search? Thirty days is the common default and a reasonable starting point for most verticals.

The window is a direct expression of how long you think a consumer's intent persists. Someone who filled out an auto insurance form 25 days ago and fills one out today is arguably the same lead. At 90 days, they're arguably shopping again, and refusing to sell that is refusing revenue. At 7 days, you're selling the same person to the same buyer four times a month and they will notice.

Set it per vertical, not globally. Intent decays at different rates for a mortgage refi and a roof replacement.

## Duplicates are two different problems

Here's a distinction that changes how you act on the data.

**Pre-distribution duplicates** are ones you caught. Your dupe check fired, the lead was rejected, nobody outside your system ever saw it. These are working as designed. They cost you nothing except the source payout you may or may not owe.

**Buyer-reported duplicates** are ones you missed. The lead went out, the buyer's own CRM said "we already have this person," and they rejected it or returned it. These are the ones that matter, because each one is a gap between your dupe key and theirs.

The second number is the one to watch. A rising buyer-reported dupe rate means your matching is looser than that buyer's — usually because they're matching on something you aren't, or their lookback is longer than yours. That's a fixable configuration difference, and it's worth asking the buyer directly what they dedupe on rather than guessing at it for a quarter.

If you're only looking at your own dupe rejection count, you're measuring the leads you caught and ignoring the ones that cost you money.

## Fraud gatekeeping: gates versus enrichment

Not every check should reject. This is the distinction that separates a gate that helps from a gate that quietly destroys inventory.

**Gates** reject the lead outright. Use these where a hit is unambiguous and the consequence of being wrong is severe:

- **Blacklist and DNC scrubs.** Binary and legally consequential. If the number is on a suppression list, there is no version of this where you sell it. Run it early — it's cheap, and it's the check with actual liability attached.
- **Litigator lists.** Same logic, more so.

**Scores** are inputs to a rule, not verdicts. IP fraud scores, proxy and VPN flags, bot detection, disposable email detection — these produce a number or a signal, and the rejection threshold is yours to set:

- A fraud score above some threshold, reject.
- VPN *and* proxy together, reject; either alone, maybe not.
- A datacenter IP on a form fill at 3am, probably reject. The same signal on a legitimate corporate VPN, less obvious.

Every one of those thresholds is a dial between fraud you eat and good leads you delete. There's no correct setting, only a setting you've measured.

**Enrichment** doesn't reject anything. Some checks exist purely to add data — a credit band, a demographic signal — that your filters and your buyers can then act on. The same vendor is often both: with rules configured it's a gate, with no rules it's enrichment. Know which mode each of yours is in, because an "integration that isn't working" is very often an enrichment integration doing exactly what it was configured to do, which is nothing.

## Filters: order matters, first match wins

Your own business rules run as an ordered list. The mechanics that matter:

- **Filters evaluate in order, and the first match stops evaluation.** Order is not cosmetic. It's the logic.
- **Within one filter, conditions are AND.** All conditions must match for the filter to fire. Multiple conditions in one filter is a narrower rule, not a broader one.
- **Nothing matching means the lead passes.** The default is accept. If you intended a whitelist — only these states, only this age band — you must write the explicit reject rule at the bottom yourself. A list of accept rules with no closing reject is a list of accept rules that lets everything else through.

That last one is the single most common filter bug in lead operations. It fails open, silently, and looks fine on the screen.

## What to reject versus what to sell cheaper

The instinct is to make gatekeeping binary: good lead, bad lead. But a large share of your marginal inventory isn't bad, it's *worth less*, and rejecting it is a decision to earn zero on it.

A lead from a state where your best buyer has no coverage isn't fraudulent. A lead with a thin credit profile isn't fake. A lead from a source with a mediocre history is still a lead. All of these are candidates for **conditional pricing** — accept the lead, attach a lower payout, route it to a buyer who wants that segment at that price.

The framing that works:

- **Reject** what's illegal to contact, provably fake, or genuinely duplicate. There's no price at which these are worth selling.
- **Price down** what's real but marginal. Somebody will buy it. Your job is to find out at what number, not to decide in advance that the answer is zero.
- **Enrich and pass** what you're unsure about. Attach the signal, let the filters and the buyers decide.

Operators who tighten the gate in response to a buyer complaint usually over-tighten, because rejection is visible and lost revenue isn't. The leads you rejected don't appear in any report as a cost. They just quietly aren't there.

## Common mistakes

### Mistake 1: Ordering filters before enrichment

Covered above, but it earns its place on the list because it's so common. A filter can't see data that hasn't been fetched yet.

**The fix:** know your pipeline order. When a filter on enriched data won't fire, check the ordering before you check the vendor.

### Mistake 2: Putting IP in the duplicate key

Shared IPs are normal. Households, offices, mobile carriers. A one-field-match dupe check on IP deletes real people.

**The fix:** dedupe on identity (phone, email). Use IP for fraud.

### Mistake 3: A whitelist with no closing reject

Accept rules with nothing at the bottom means everything else passes. You built a whitelist and shipped a passthrough.

**The fix:** every whitelist ends with an explicit catch-all reject. Test it with a lead you expect to be rejected.

### Mistake 4: Tuning the gate on anecdotes

One buyer complains about one lead, and somebody tightens a threshold that afternoon. Nobody measures what that threshold now rejects.

**The fix:** change thresholds against measured rejection volume, not against the most recent complaint. Know what a change costs before you make it.

### Mistake 5: Measuring rejections instead of misses

Your dupe rejection count measures your successes. Your buyer-reported dupe rate measures your failures. Most operators only watch the first.

**The fix:** track buyer-reported dupes and returns as your gate's real scorecard. That's the number that costs money.

### Mistake 6: Treating gatekeeping as set-and-forget

Fraud patterns move. Sources degrade. The thresholds that were right last year are calibrated to traffic you no longer have.

**The fix:** review rejection reasons monthly. The distribution shifting is your early warning that something upstream changed.

## The takeaway

Gatekeeping is a pipeline, not a switch. Order determines what each check can see, and most "broken integration" reports are really ordering problems.

Reject only what has no price — illegal to contact, provably fake, genuinely duplicate. Price down everything that's merely marginal, because a lead you rejected earns exactly zero and doesn't appear on any report as a loss.

And measure the gate by what gets past it, not by what it catches. Your buyers are already measuring it that way.

### How to choose a lead routing strategy

URL: https://datahubb.io/blog/how-to-choose-a-lead-routing-strategy
Published: 2026-07-16

> Waterfall, auction, weighted, or tiered — the routing strategy you pick sets your revenue per lead. Here's how to choose, and why ping/post isn't on the list.

Routing strategy is the setting that decides what every lead in your operation is worth. Two operators can run identical campaigns, identical buyers, identical traffic, and see materially different revenue per lead — because one is routing on price discovery and the other is routing on position in a queue.

It's also the setting most operators pick once, during setup, based on whatever the platform defaulted to. Then they optimize everything else — creative, sources, filters — around a routing decision nobody revisited.

This is how to make that decision deliberately.

## First, clear up the framing error

Almost every conversation about routing starts in the wrong place: "should we do ping/post or waterfall?"

That question doesn't parse. **Ping/post is not a routing strategy. It's a transport.**

Ping/post describes *how* you talk to a buyer: a thin, anonymized ping to get a bid or an interest signal, then a post carrying the full record to whoever wins. Waterfall, auction, weighted, and tiered describe *how you decide who wins*. These are independent axes. You can run a waterfall over ping/post buyers. You can run an auction over direct-post buyers with fixed prices. Any strategy runs over either transport.

Conflating the two is how operators end up believing they "can't do ping/post because we're on waterfall," or that switching to an auction requires rebuilding every buyer integration. Neither is true, and the confusion costs real money in deferred decisions.

Separate the axes:

- **Transport** — direct post (one call, full record) or ping/post (bid first, deliver to the winner).
- **Strategy** — the rule that picks the winner.

Everything below is about the second one.

## The four strategies

### Waterfall

Buyers are ordered. The lead is offered to the first buyer; if they accept, distribution ends. If they reject, it falls to the second, and so on. All buyers reject, the lead is rejected.

**What it optimizes for:** priority. You are explicitly saying "this buyer gets first look at everything, always."

**When it's right:** you have a preferred buyer relationship — a volume commitment, a strategic partner, a parent company — where the order itself *is* the business logic. Also correct when you have one or two buyers and an auction would be theater.

**What it costs you:** price discovery. Your first buyer accepts a lead they'd have paid double for, and you never find out, because nobody else was asked.

### Highest bidder (auction)

Every eligible buyer is pinged simultaneously. Bids come back. You sort them, post to the highest, and if that buyer rejects the post, you fall to the next-highest.

**What it optimizes for:** revenue per lead. This is the only strategy that discovers what a specific lead is actually worth to a specific buyer at a specific moment.

**When it's right:** you have enough buyers to make a market — realistically three or more actively bidding — and your margin depends on price. If lead value varies meaningfully by attribute (geo, credit band, vertical intent), an auction captures variance that a flat price averages away.

**What it costs you:** it requires buyers who can actually bid. A buyer posting a static price to your ping isn't bidding, they're just quoting. An auction full of static quotes is a waterfall with extra latency.

### Weighted

Each buyer carries an integer weight. Weights define target shares of volume. Each lead goes to whichever buyer is currently furthest below its target share.

**What it optimizes for:** distribution against volume commitments. If you've promised buyer A 50% and buyers B and C 25% each, weighted is the strategy that keeps that promise without you managing it by hand.

**When it's right:** you have contractual volume splits, or you're deliberately spreading volume to keep several buyers warm.

**What it costs you:** the same thing waterfall costs you — price discovery — plus a subtlety that catches people out, below.

### Tiered

Tiers are ordered groups of buyers. Each tier runs its own sub-strategy over its own buyer subset. The lead tries tier 1; if every buyer there rejects, it falls through to tier 2, and so on.

**What it optimizes for:** mixing strategies in one campaign, which is usually what you actually want.

**When it's right:** more often than operators expect. The canonical shape: a premium tier running an auction among buyers who'll pay real money, with a fallback tier below running weighted distribution to spread whatever the premium tier didn't want. You capture price at the top and monetize the tail at the bottom.

**What it costs you:** configuration surface. Tiers introduce a floor per tier, an order per tier, and a buyer subset per tier. More knobs, more ways to misconfigure.

## The decision framework

| If your situation is… | Use |
|---|---|
| One or two buyers, fixed prices | **Waterfall** — an auction has nothing to auction |
| A preferred buyer with first-look rights | **Waterfall** |
| Three or more buyers who genuinely bid, and margin is the business | **Highest bidder** |
| Contractual volume splits to honor | **Weighted** |
| Premium buyers *and* a tail you want monetized | **Tiered** (auction on top, weighted below) |
| Buyers whose value you can't know until conversion | **Tiered**, with the conversion-priced buyers in a lower tier |

The honest summary: **waterfall and weighted optimize for relationships; auction optimizes for revenue; tiered lets you stop choosing.** If you have the buyer count to support it, tiered is usually where you end up, because real operations have both a premium segment and a tail.

## Weighted distribution deserves a warning

Two things about weighted routing are non-obvious and both have burned operators.

**Weight targets share of leads *won*, not share of leads *attempted*.** A buyer that gets offered every other lead and rejects most of them stays below its target share, so the engine keeps trying it first. Its deficit never closes. If you set weights expecting them to describe traffic allocation, and your buyers have materially different accept rates, realized volume won't match the weights — and the engine is behaving correctly.

**The counter is usually all-time.** This is the one that surprises people. Add a new buyer at weight 25 to a campaign that's been running for months, and that buyer is maximally below its target share from the moment it's created. It will receive a **catch-up burst** — a disproportionate slug of volume — until its realized share climbs to target. Same thing happens to a buyer coming back from a cap or a pause.

That's expected behavior, not a bug, but if you don't know it's coming you will interpret it as a routing failure and start changing weights mid-burst, which makes it worse. Add buyers to weighted campaigns knowing the first day is not representative.

## Where conversion-priced buyers break the model

If you work with buyers who pay on conversion rather than on delivery, routing gets a wrinkle worth understanding before you configure it rather than after.

A conversion-priced buyer has **no realized price at distribution time**. Delivery books nothing; revenue lands later, when the buyer confirms — or never, if they don't. Which means:

**Don't put conversion-priced buyers in a head-to-head auction with delivery-priced buyers.** They have no bid to compete with. Either they're excluded by any price floor you've set, or they're included at zero and structurally lose every auction. Neither is what you meant.

**Fallthrough triggers on rejection, not on non-conversion.** This is the important one. When a conversion-priced buyer *accepts the post*, distribution ends — the lead is theirs. If the conversion later fails, lower tiers are never reached. The lead doesn't come back and try again. You've committed the lead to a buyer who ultimately paid nothing.

Both of these point the same way: put conversion-priced buyers in a **lower tier with no floor**, below your delivery-priced buyers. The top tier wins guaranteed revenue first. The bottom tier monetizes what's left on a maybe. That ordering reflects the actual risk, and it's the reason tiered exists.

## Price floors are three different things

"Price floor" gets used loosely and it hides a real distinction:

- **A campaign-level bid floor** rejects bids below a threshold. Note that a bid floor only means anything when buyers are bidding — on a direct-post campaign with fixed prices there are no bids to floor, and operators regularly set one and wonder why it does nothing.
- **A per-tier floor** applies to one tier only and overrides the campaign floor for that tier's buyers.
- **A per-buyer rule** on the buyer's own response handling.

The per-tier floor has a sharp edge: **a floor above zero silently excludes zero-price buyers.** If you've built the recommended shape — premium tier on top, conversion-priced or revenue-share buyers in a fallback tier below — and that fallback tier has a floor greater than zero, your zero-price buyers qualify for nothing and the tier looks broken. Fallback tiers holding zero-price buyers need their floor explicitly set to zero.

## Common mistakes

### Mistake 1: Running an auction with buyers who don't bid

You switch to highest bidder, revenue doesn't move, you conclude auctions don't work in your vertical. The real problem is that all four of your buyers return the same static number to every ping. An auction only pays when there's dispersion in what buyers will pay.

**The fix:** before switching, check whether your buyers' bids actually vary by lead. If they don't, the auction is a waterfall wearing a costume, and your gain is in getting buyers to bid dynamically, not in the routing change.

### Mistake 2: Picking a strategy for the campaign instead of for the segment

One strategy across every lead in a campaign assumes every lead has the same economics. They don't. Your high-intent, high-credit, dense-metro leads deserve an auction. Your thin-file tail deserves to be spread across whoever will take it.

**The fix:** tier it. This is precisely the problem tiers solve.

### Mistake 3: Treating rejection as a routing failure

Buyers reject leads. That's the system working — a rejection is a buyer telling you something. When operators respond to rejection rates by reordering buyers or nudging weights, they're treating a quality signal as a routing problem.

**The fix:** read the rejection reasons before touching the routing. Most "routing isn't working" is a filter, cap, schedule, or source-quality problem wearing a routing costume.

### Mistake 4: Never revisiting the choice

The strategy that was right when you had two buyers is not right when you have twelve. Buyer count is the variable that most changes the answer, and it's the variable that changes silently as you grow.

**The fix:** revisit routing every time your active buyer count materially changes. Crossing from two buyers to four is the threshold where auction economics usually start to pay.

### Mistake 5: Changing strategy and volume at the same time

You switch to weighted on Monday and scale a new source on Monday. Revenue per lead moves. You have no idea which change did it.

**The fix:** change one variable. Routing changes need a clean baseline or you can't read the result.

## The takeaway

Routing strategy is not a setup detail. It's the mechanism that converts your buyer relationships into revenue per lead, and the four options optimize for genuinely different things: waterfall for priority, auction for price, weighted for commitments, tiered for all of the above.

Start by separating transport from strategy — ping/post is not on the menu, it's the plumbing. Then pick based on your buyer count and where your margin actually comes from. If you have a premium segment and a tail, and most operations do, you want tiers.

And when you change it, change only it. The whole point is to find out what it was worth.

### How to Choose Lead Distribution Software — A Decision Framework for the Choice You'll Live With for Years

URL: https://datahubb.io/blog/how-to-choose-lead-distribution-software
Published: 2026-07-09

> Picking lead distribution software is a high-cost decision with high switching costs. Here's the decision framework — your business stage, your real requirements, the evaluation steps, and how to avoid the most common mistakes.

Lead distribution software is one of the high-leverage decisions in any lead operation. The platform you pick will shape your daily work, your operational costs, your buyer relationships, and your ability to scale, for at least the next 3-5 years.

The decision is also high-cost in the wrong direction. Migrating from one platform to another, mid-operation, is painful — buyer integrations rebuilt, source integrations re-tested, historical data exported and re-imported, team retrained, weeks of operational risk. Most operators migrate once. Either the choice was right or they're carrying the cost of a wrong choice indefinitely.

This is the decision framework. Where you should be in your business before you start, what your real requirements are, how to evaluate options, and the mistakes to avoid.

## Stage 0: Are you ready?

Before evaluating platforms, ask whether you're ready to be on one.

A platform is worth the investment when:

- You're processing more than 100 leads per day across all campaigns
- You have at least 3 buyers across one or more campaigns
- You're spending more than 5 hours per week on manual delivery and reconciliation
- Your finance team is starting to push back on the way you book revenue
- You're getting buyer complaints you can't answer quickly
- You're considering hiring an operations person to handle the chaos

If you're processing 20 leads per day with one buyer and a spreadsheet, you're not ready. The platform's overhead exceeds its value at that scale. Wait until you've grown into needing it.

If any three of the bullets above apply, you're at the moment where the platform's value exceeds its cost. Don't wait too long — every additional month of growth on the wrong infrastructure compounds the eventual migration cost.

## Stage 1: Understand your real requirements

The mistake most operators make is starting with vendor demos. They watch three demos, pick the one that felt best, and discover after signing that their actual requirements weren't met by the impression-managing demo.

Instead, start with a written list of your actual requirements. Specifically:

### Lead types

What kinds of leads do you handle today, and what will you handle in 12 months?

- Form leads only
- Phone leads (pay-per-call) only
- Both form and phone leads
- Live transfers in addition to standard phone leads
- Other (data file imports, partner feeds, etc.)

A platform that handles only form leads can't grow into phone leads without re-platforming. A platform that handles both natively gives you optionality.

### Lead volume

What's your current volume per day? What's your projected volume in 12-24 months? Some platforms degrade at high volume; others have explicit tier-based pricing that becomes problematic at scale.

### Number of buyers and sources

How many buyers do you actively distribute to? How many sources do you ingest from? A platform optimized for "one campaign, two buyers" works differently than one designed for "fifty campaigns, two hundred buyers."

### Routing complexity

What pricing strategies do you need?

- Flat per-lead pricing only
- Real-time bidding
- Weighted distribution (volume commitments)
- Tiered routing (mixing strategies in one campaign)
- CPA (conversion-based pricing)

A platform that doesn't support all of these locks you into the subset it does support.

### Compliance requirements

What verticals are you in? Some require specific compliance handling (insurance, mortgage, healthcare, legal). What audit trail do you need to maintain?

### Integration requirements

What systems do you need to connect to?

- Accounting (QuickBooks, Xero, NetSuite)
- CRM (Salesforce, HubSpot)
- Ad platforms (Meta CAPI, Google Ads conversion API, TikTok)
- Email and marketing automation (Mailchimp, ActiveCampaign)
- Custom internal systems

A platform with the integrations you need out of the box saves you weeks of work each. A platform without them makes you build them yourself.

### Multi-tenancy

Are you a single operation, or do you serve multiple distinct businesses (different brands, sub-brokerages, white-label clients)? Multi-tenant requirements rule out platforms that aren't built for it.

### White-label requirements

Do you need the platform to appear as your own brand (custom domain, logo, theme) when buyers and sources log in?

Write all of this down. The requirements document is what you evaluate platforms against.

## Stage 2: Build the shortlist

Once you have requirements, you can build a shortlist.

**Sources of candidates:**

- Industry recommendations (other operators in your vertical)
- Vendor lists from industry events and publications
- Google searches for "lead distribution platform [your vertical]"
- The platforms your buyers and sources already use

**Initial filter:**

- Does the vendor explicitly support your lead types?
- Does the vendor explicitly support your routing requirements?
- Is the pricing in your range (rough; you'll get precise numbers later)?
- Are there reasonable client references in your vertical?

A shortlist of 3-5 platforms is the right size for serious evaluation. Fewer and you don't have alternatives; more and the evaluation becomes overwhelming.

## Stage 3: The vendor conversations

For each shortlisted platform, schedule a vendor conversation. The goal isn't to be sold to — it's to verify requirements.

**Before the call:**

- Send your requirements document
- Ask them to confirm in writing which requirements they meet, which they meet with caveats, and which they don't meet
- Ask for technical documentation (API reference, integration guides)

**During the call:**

- Walk through specific scenarios from your operation
- Ask hard questions about edge cases (see the platform comparison guide for the specific questions)
- Request a technical person on the call, not just sales
- Pay attention to how they answer questions — specifics are good, hand-waving is bad

**After the call:**

- Note which requirements were confirmed, which weren't, and which are on their roadmap
- Score the platform's responses for depth (specific = high, vague = low)
- Identify the questions you couldn't get answered

A platform that responds to your detailed questions with detailed answers is one you can build on. A platform that responds with marketing-speak is one to deprioritize.

## Stage 4: The proof of concept

Before signing a contract, run a paid pilot with the top one or two candidates.

**Pilot scope:**

- One campaign with moderate complexity
- 2-4 weeks
- Real production traffic
- Real buyers and sources

**What to measure:**

- End-to-end latency (lead arrival to sale recorded)
- Acceptance rate (does the platform's filtering match what you expected)
- Revenue per lead (does the routing produce the revenue you expected)
- Operational friction (how often do you have to ask support questions; how often does manual intervention happen)
- Integration cost (how long does it take to set up integrations you need)
- Dashboard usability (can your team actually operate the platform daily)

**What to look for:**

- Edge cases that came up that you didn't anticipate
- Support quality (when you asked questions, were they answered competently and quickly)
- Documentation quality (could you find answers without asking)
- Performance under load (did anything degrade as you ramped volume)

The pilot reveals things demos and conversations can't. A platform that demos great and pilots poorly is one to walk away from. A platform that demos well and pilots well is one to commit to.

## Stage 5: The contract

Once you've picked a platform, the contract terms matter.

**Things to negotiate:**

- **Pricing terms** — monthly vs annual, percentage of revenue vs flat fee, included features vs paywalled add-ons
- **Term length** — month-to-month, 1-year, multi-year (longer terms usually get better pricing but reduce your flexibility)
- **Volume tiers** — pricing breaks at volume thresholds
- **Service level agreements (SLAs)** — uptime, response time, escalation procedures
- **Data ownership** — you own your data, exportable on demand, retained per your specifications
- **Termination terms** — what happens if you leave (data export, transition support, contractual penalties)
- **Indemnification** — for platform failures that cause you operational losses

**Red flags to push back on:**

- Long-term contracts with no exit
- Data lock-in (your data only exists in their format)
- Vague pricing that depends on "consultation" each year
- No SLAs or extremely weak SLAs
- One-sided indemnification (they're protected, you're not)

A serious vendor will negotiate. A vendor who refuses to negotiate any terms is signaling that their contract is more important than your relationship.

## Stage 6: The migration

Once you've signed, the migration is its own project.

**The phases:**

- **Setup.** Configure the new platform — campaigns, buyers, sources, integrations
- **Testing.** Run test leads through every flow, verify outcomes match expectations
- **Parallel run.** Send a portion of real traffic to both platforms simultaneously, compare outcomes
- **Cutover.** Switch full traffic to the new platform
- **Stabilization.** Monitor closely for the first 2-4 weeks, fix issues quickly
- **Retirement.** Once stable, retire the old platform

**Common migration risks:**

- Buyer integrations break (their endpoints have to accept your new platform's format)
- Source integrations break (your sources have to push to the new platform's endpoints)
- Historical data doesn't migrate cleanly (gaps in reporting, ledger discrepancies)
- Team isn't trained on the new platform (slow operations during early stabilization)
- Compliance gaps during transition (a lead in flight on both platforms gets handled twice or not at all)

**Mitigations:**

- Build a written migration plan with timeline
- Communicate with buyers and sources before changes hit them
- Run parallel for at least a week before cutover
- Keep the old platform available for reference for at least 90 days after cutover
- Train the team thoroughly before cutover, not during

A botched migration sets you back months. A planned migration is a few weeks of focused work.

## Common mistakes in the choice

Five patterns that produce regrets.

### Mistake 1: Optimizing for current state only

You evaluate based on what you need today. The platform fits. Then your business grows in directions you didn't anticipate, and the platform doesn't follow.

**The fix:** Evaluate based on what you'll need in 24 months, not just today. Include directional growth (new verticals, new lead types, new buyer relationships) in your requirements.

### Mistake 2: Picking based on price

The cheapest platform is sometimes the right platform. It's often not. Price differences usually reflect capability differences, and capability gaps cost you operationally.

**The fix:** Compute total cost of ownership, not just platform price. Include the cost of features you'll have to build externally, integration work, operational friction, and eventual migration cost.

### Mistake 3: Listening to the salesperson, not the technical contact

Sales tells you what you want to hear. Technical contacts tell you what's true.

**The fix:** Insist on technical conversations with the vendor's engineers or solutions architects before signing. If they won't provide one, that's signal.

### Mistake 4: Skipping the pilot

"We saw the demo, it looked great, let's just sign." The pilot reveals the gap between demo and reality.

**The fix:** Always pilot. Even on a tight timeline. A 2-4 week pilot saves you from a 2-3 year mistake.

### Mistake 5: Not involving the team that'll operate it

The decision is made by leadership. The platform is used by operations. If operations wasn't involved in the evaluation, they discover the daily-use friction after the choice is locked in.

**The fix:** Bring operations into the evaluation. They'll catch usability problems leadership won't notice.

## The takeaway

Choosing lead distribution software is consequential. The right choice compounds over years; the wrong choice costs you operationally every day until you migrate.

The decision framework: know what you actually need, evaluate based on specifics (not demos), pilot before committing, negotiate contracts that protect you, and plan migration carefully.

This is unglamorous work. It's also the work that makes the difference between an operation that scales and one that fights its tools forever.

Spend the time up front. The savings compound.

## Help centre

### Array.com Integration Guide

URL: https://datahubb.io/help/arraycom-integration-guide

> Configure Credit Check Integration Rules with Array in Datahubb.



### Rejection Reasons: turn rejected leads into recovered revenue

URL: https://datahubb.io/help/rejection-reasons-turn-rejected-leads-into-recovered-revenue

> Every lead buyer knows the frustration. You send good traffic, leads come in, and a chunk of them never sell. The money quietly leaks away, and when you ask why, the honest answer is usually a shrug. Which buyers? Which reasons? Which sources? How much did it actually cost this week?

Every lead buyer loses money to rejected leads. Good traffic comes in, a chunk of it never sells, and when you ask why, the honest answer is usually a guess. Which reasons? Which buyers? Which sources? And how much did it actually cost this week?

Rejection Reasons is the Datahubb feature that answers that. It watches every rejection across your pipeline, turns thousands of scattered events into a handful of clear causes, and puts a realistic dollar figure on the loss so you can prioritize by money instead of noise. Most platforms show you a rejected count. Datahubb shows you what it cost and points you at the fix.

If there is one screen worth learning in Datahubb, this is it. It is where lost revenue becomes recoverable revenue.

![](https://dh-testing.sfo3.digitaloceanspaces.com/rich-editor/im9YuUoTTIixfA29SoKL6TiYfghXeLl2z5bfS2jH.png)

---

## What it does for you

- **Puts a dollar value on rejections,** so you work on what actually costs the most, not whatever happens to be loudest.
- **Explains the why in plain language,** grouping every rejection into a clear cause instead of a wall of raw messages.
- **Points at who and where,** so you can view the same rejections by buyer, source, affiliate, and campaign.
- **Recommends the next step,** with guidance built from your own numbers.
- **Lets you close the loop,** marking causes as handled so your view stays clean and you can confirm the drop later.

---

## Getting started

1. Open **Rejection Reasons** from the sidebar. It opens on the Analytics view.
2. Pick your **campaign** and **date range** at the top. Everything on the page follows that scope.
3. Read the summary at the top. It walks from leads received, to how many hit a rejection, to how many still sold, to how many were lost, alongside the estimated revenue you missed.
4. Switch to the **Rejection Reasons** tab to work through individual causes, open any one for detail, and mark it handled once you fix it.

That is the whole loop: see the cost, find the cause, fix it, and confirm it dropped.

---

## Terms you will see on screen

Keep this handy while you read the dashboard.

| Term | What it means |
|---|---|
| **Analyzed leads** | The leads that hit at least one rejection in your current view. The starting point for everything else. |
| **Recovered** | A lead that was rejected somewhere but still sold. Not a loss. |
| **In flight** | A lead with a sale still in progress. Not counted as lost, because it has not failed yet. |
| **Lost** | A rejected lead that never sold. The revenue you are trying to win back. |
| **Estimated missed revenue** | A realistic dollar estimate of the leads you could not sell, grounded in your own real sales data rather than a hypothetical, so you have a number to plan around instead of a raw count. |
| **Rejection group** | The plain-language cause a rejection is sorted into, such as Buyer filter, Outside schedule, Pricing, Caps, or Source quality. |
| **Occurrences** | The raw number of rejection events for a cause. One lead can produce several. |
| **Unique leads** | How many distinct leads a cause touched. Read this next to occurrences to tell "many hits on a few leads" from "a few hits across many." |
| **Status** | Where a cause sits in your workflow: Open, In Progress, Resolved, or Won't Fix. |

A couple of things that surprise people the first time:

- The rejected numbers here are meant to differ from the rejected count on your Campaign Analytics page. This screen counts rejections across the delivery pipeline. Campaign Analytics counts final outcomes. Both are right, and they answer different questions.
- Cause percentages can add up to more than 100. That is expected, because a single lead can be rejected for more than one reason at once.

---

## Frequently asked questions

**Who can see Rejection Reasons?**
It is an admin feature, available on accounts that have it enabled.

**Can I share a specific view with a teammate?**
Yes. Your campaign, dates, and view are saved in the page link, so you can bookmark or send any scoped view and they land exactly where you did.

**Why is a buyer's rejection showing as raw text instead of a clean cause?**
That buyer's response mapping is not returning a clean reason. Once their mapping is set up, the raw text becomes a proper cause, and Datahubb will flag it for you when it is worth your attention.

**The page looks empty right after a big spike.**
Rejection data is processed continuously and can land a moment after the event during a heavy burst. Give it a short moment and refresh.

---

## The bottom line

Rejected leads are not a dead end. Rejection Reasons names the cause, prices the loss in real dollars, and points you at the fix, all in one place. Open it, sort by missed revenue, and start recovering.

Want a full walkthrough? Take the built-in **Page tour** on the dashboard, or reach out to our team and we will show you around.

### Getting started with your trial

URL: https://datahubb.io/help/getting-started-with-your-trial

> You've got a live workspace and a free trial — this guide walks you through your first 30 minutes so you go from an empty dashboard to a real lead flowing end to end.

Welcome to Datahubb. Work through the steps in order; each one builds on the last.

Datahubb is a lead-distribution platform: **suppliers** (your traffic sources) send you leads, a **campaign** validates and filters them, and **buyers** purchase them. Everything you build hangs off a campaign, so most of your setup happens there.

## Step 1 — Get your bearings on the Dashboard

When you log in you land on the **Dashboard**. It shows KPI cards — Posted, Accepted, Rejected, and Profit/Revenue — plus trend graphs, your top campaigns, and an activity feed.

On day one every number reads zero. That's expected: the dashboard only fills in once leads start arriving.

One concept to keep in mind: your account is a single **workspace** (tenant) with its own isolated data, served on your own domain (`https://{yourname}.datahubb.io`). That domain runs both this portal and the public endpoints suppliers post leads to.

## Step 2 — Invite your team and set roles

Datahubb uses role-based access. The three default roles are:

- **Admin** — full access to everything in your workspace.
- **Traffic Source** — can submit leads, see conversion data, and manage their own postbacks.
- **Buyer** — can view leads sold to them and manage their bid settings.

Open **Manage Users** in the sidebar, add a user, enter an email, and pick a role. The person gets an invite email, clicks the link, sets a password, and they're in.

**Important:** if you're going to sell to a buyer, create that buyer's user account here **first**. You can't configure a buyer inside a campaign until its user account exists.

*Optional:* you can require 2FA for all users in your security settings. Not needed to get started.

## Step 3 — Create your first campaign

The campaign editor is a tabbed builder: Overview, Distribution, Response, Traffic Sources, Suppliers, Buyers, Fields, Filters, Integrations. A full setup takes about 15–30 minutes. A built-in **guided tour** anchors tips to the screen and moves you tab to tab — let it run the first time.

1. Go to **Campaigns** and click **+ Add**.
2. The Add Campaign form has only two fields:
 - **Name** — the internal display name you'll see in the campaigns list, dashboard, analytics, and notifications. Name it by what it collects, e.g. "Auto Insurance Brand", so campaigns are easy to tell apart. You can change it anytime.
 - **Campaign URL** — the page hosting the form that collects your leads. It's the campaign-wide fallback destination for your traffic sources (each one can override it with its own page later). Use a full URL, e.g. `https://yoursite.com/auto-quote`.
3. Click **Create** — you land on the campaign's Overview tab. Everything else (distribution type, ping/post, fields, buyers, filters) is configured *after* creating, on the editor tabs. Work through them left to right, then use **Save** (top right) to persist changes.

### Define your Fields (the lead schema)

On the **Fields** tab, add every piece of data a lead must contain — for example `first_name`, `email`, `phone`, `zip_code`, `state`. For each field set the **name** (the exact key suppliers send in their payload), the **type** (email, phone, string, integer, date, etc.), and whether it's **required**. You can add fields one at a time or bulk-import them from a CSV.

**Gotcha:** fields only apply to *new* leads. Adding a field later won't backfill leads you've already received.

## Step 4 — Add a buyer (who buys your leads)

Open your campaign's **Buyers** tab and click **Add Buyer**. Assign the buyer user account you created in Step 2, then configure:

- **Buyer Type:**
 - **CPL** (Cost Per Lead) — you get paid the moment the lead is delivered.
 - **CPA** (Cost Per Acquisition) — revenue is deferred; the lead sits *Pending* until the buyer confirms it converted via postback (default 30-day window).
 - **PPC** (Pay Per Call) — paid per qualified call.
 - **CPC** (Cost Per Click) — paid per click conversion.
- **Delivery Method:**
 - **Direct Post** — one HTTP POST with the full lead.
 - **Ping/Post** — two phases: ping for a bid, then post the lead to the winner. This adds a Ping Configuration section where you set the ping URL and the accept/reject conditions that parse the buyer's response.
 - Other options: One-to-One (exclusive), Email Leads, Store Leads.
- **Price** — the sale price you charge the buyer.
- **Optional:** Schedule (active days/times), Caps (daily/weekly/monthly volume or budget), and Weight (used by Weighted and Advanced distribution).

**Test it before going live:** on the buyer edit page use **Test Buyer Integration** — send a sample payload and inspect the real response to confirm the endpoint is reachable and your accept/reject conditions match.

**Gotchas:**
- CPA leads correctly show `0.00` revenue and a *Pending* status until the buyer confirms — that's by design, not a bug.
- Placeholders in custom headers use single braces `{field_name}`.

## Step 5 — Add a supplier (who sends you leads)

A **supplier** is the source that posts leads to you. It authenticates with an **API key + supplier ID**.

On your campaign's **Suppliers** tab click **Add Supplier**. The main choice is the **Source**:

- **Internal** — your own hosted landing page. Price and margin are 0 (it's your own traffic). Use this if you want per-affiliate tracking via Traffic Sources.
- **External** — a third-party publisher who host-and-posts to you. You set the price you pay them, and assign a user who holds the Supplier role.

Save, then click the supplier's name to open it and **copy its API Key and Supplier ID** — those are the credentials whoever sends leads will use.

**Traffic Sources (Internal only):** if you want to track individual affiliates under an Internal supplier and pay them revenue share, add them on the **Traffic Sources** tab. Each gets a **Traffic Source ID** that affiliates send as the `traffic_source` value on every lead, plus an optional postback URL so they get notified of sales.

**Gotcha:** leads always authenticate with the *supplier's* API key. A traffic source is identified only by the `traffic_source` value in the payload — it's not a separate credential.

## Step 6 — Pick a distribution type

Set this on the campaign's **Distribution** tab. It decides which buyer gets each lead:

- **Waterfall** — buyers are tried in a fixed order you drag; the first to accept wins. Simplest option.
- **Highest Bidder** — all eligible buyers are pinged at once and the highest bid wins. Best for max revenue; needs ping/post buyers.
- **Weighted** — leads split toward target shares you set (e.g. Buyer A 50%, B 30%, C 20%). Best for honoring volume commitments.
- **Advanced** — ordered tiers, each with its own sub-strategy and optional payout floor. For mixed setups you grow into.

**Beginner pick:** start with **Waterfall** (just order your buyers), or **Highest Bidder** if you already have bidding buyers.

**Gotchas:**
- Every mode is single-winner: one lead goes to one buyer per run. There's no "send the same lead to everyone."
- In Advanced, a tier floor of 0 (or empty) means *no floor* — you need that so zero-bid CPA buyers still qualify.

## Step 7 — Send a test lead

Leads come in when a supplier POSTs to your domain — `https://{yourname}.datahubb.io/ingest`. These are public endpoints authenticated by the **API key + supplier ID** from Step 5 (not your portal login). Every payload must include a valid `ip_address` and `user_agent`.

Two safe ways to test without touching real money:

- **`is_test: "true"`** — skips validation and dedupe checks and sells to a dummy Test Buyer for a random amount. No ledgers are affected.
- **`test_buyer_id`** — runs a real distribution against one specific buyer and returns its filter logs, ping/post steps, and final price. This is what the in-app buyer test panel uses. Don't combine it with `is_test`.

The response comes back with a `status` (ACCEPTED / PENDING / REJECTED / DUPLICATED / ERROR), a `lead_id`, a `reason`, and the `payout`. Every attempt is captured in **Ingest Logs** on the lead's detail page, so you can see exactly what happened.

**Gotchas:**
- "Invalid API key" → recheck or regenerate it in supplier settings.
- "Required field missing" → the payload is missing a field you marked required on the Fields tab.

## Step 8 — Add filters and duplicate checking

**Filters** accept or reject leads by field value, at four levels: Global, Supplier, Buyer, and Traffic Source. On the **Filters** tab, add a rule with a field, a condition, value(s), and an output of **Accept** or **Reject**.

Rules run top to bottom and **stop at the first match**, so order matters — put your most specific rules first and end with a catch-all fallback. Use the built-in **Rule Analyzer** to catch problems like an accept rule with a $0 payout or a missing fallback.

**Duplicate checking** runs as its own stage — configure the campaign's dupe checker with lookback windows for phone, email, and IP so you don't pay for repeats.

**Gotcha:** condition names are literal and case-sensitive (for example it's `HAS ONE OF`, not `IN`).

## Step 9 — Watch your results

- **Dashboard** — daily KPIs at a glance.
- **Analytics** — multi-campaign performance with per-buyer, per-supplier, and per-traffic-source breakdowns.
- **Leads** — each lead's full timeline: which buyers saw it and who accepted or rejected it, and why.

The **Notifications** page (bell icon, top right) is your in-app inbox — All / Unread / Read — where alerts like **Lead Sold**, **Cap Reached**, and rejections land in real time. In-app alerts are always on. To control which events reach you and add email or webhook delivery, open a user in **Manage Users** and edit that user's notification settings.

**Gotcha:** analytics reads from an hourly rollup, so very fresh numbers can lag a little before they settle.

## Before you go live — quick checklist

- [ ] Campaign is **active** with at least **one active buyer and one active supplier**.
- [ ] Every **required field** the supplier will send exists on the Fields tab.
- [ ] Distribution is set — buyer order (Waterfall), weights (Weighted), or tiers (Advanced).
- [ ] Buyer endpoint verified with **Test Buyer Integration**.
- [ ] Filters sanity-checked with the **Rule Analyzer**, including a fallback rule.
- [ ] Caps and schedules reviewed so nothing is accidentally throttled or offline.
- [ ] Supplier **API key + Supplier ID** (and Traffic Source IDs) shared with whoever submits leads.
- [ ] A **test lead** sent end to end and confirmed on the lead's timeline.
- [ ] **Notification settings** reviewed in Manage Users (email/webhook delivery for Lead Sold, Cap Reached).

Once every box is checked, point real traffic at your ingest endpoint and watch the Dashboard come to life. Need a hand? Reach out to support any time during your trial.

### Email Oversight Integration Setup Guide

URL: https://datahubb.io/help/email-oversight-integration-setup

> Set up Email Oversight integration to validate emails and configure global and campaign-specific rules.



### ActiveCampaign Integration Guide

URL: https://datahubb.io/help/active-campaign-integration-guide

> Integrate ActiveCampaign with Datahubb to sync lead information, map fields, and configure triggers.



### Client Onboarding Checklist

URL: https://datahubb.io/help/client-onboarding-checklist

> Follow the full onboarding flow to ensure your campaign is configured correctly before traffic goes live.



### How to Import and Map Values

URL: https://datahubb.io/help/import-and-map-values

> Import and map values via CSV or manual entry, including conflict resolution for existing mappings.



### How to Set Up Campaign Postback Overrides

URL: https://datahubb.io/help/campaign-postback-overrides

> Configure postback override settings for campaigns per traffic source user.



### Manage Notifications & Lead Sold Alerts

URL: https://datahubb.io/help/manage-notifications-lead-sold-alerts

> Set up email and in-app notifications for Lead Sold alerts and manage recipient settings.



### How to Use Activity Logs

URL: https://datahubb.io/help/activity-logs

> Track workspace activity including user actions, system changes, and detailed audit trails.



## Changelog

URL: https://datahubb.io/changelog

### 6.14.0 — v6.14.0 — July 11, 2026

Released: 2026-07-11

A ground-up rebuild of Rejection Reasons, deeper buyer filter and cap control, and a new Anura verification integration with pay-as-you-go and bring-your-own-key options.

New Features

Rejection Reasons v2, Rebuilt from the Ground Up

The Rejection Reasons page is completely rebuilt around one question: what's costing you the most revenue, and what changed? Every screen has been redesigned to lead with money and give you a clear path from "something's off" to "here's exactly what happened and how to fix it".

 A dashboard that opens with the money

The overview now leads with your missed revenue and the leads it analyzed to get there, so money is the first thing you see. Below that, a mix of charts and breakdowns show where losses concentrate, by buyer, campaign, source, and time of day. Every rejection group is shown, not just the top ones, so you never miss where revenue is leaking. Groups are ranked by missed revenue by default, so the most expensive problems sit at the top.

 Drill into any rejection reason

Click any reason to open its drill-down. The Analytics tab shows who's rejecting, where losses land, and how much it costs. The Rejected Leads tab lists every lead behind the number. A "what triggered it" panel spells out exactly which rule fired, whether it was a filter, cap, schedule, pricing rule, or integration verdict, so you know what to change. An advanced filter drawer lets you slice the drill-down by any lead field, with a searchable picker that suggests keys as you type.

 Inspect any specific rejected lead

Open any rejected lead to see filter, schedule, cap, and pricing details together with a "Datahubb System Verdict" panel that explains platform gate decisions in plain language. The full lead payload is visible, split into campaign fields, additional fields, and enriched data, matching the layout you already know from the Leads page.

 One resolve flow, four clear states

Resolving a reason used to fan out into multiple dialogs. It's now a single dialog with clear options: resolve only the current filtered slice, or resolve the reason's entire history. A separate reclassify dialog is available for when the category itself is wrong.

 Filter, export, and share the view

The advanced filter drawer supports every operator you'd expect, including greater-than and less-than for numeric fields. The export column picker offers 51 fields with saved presets. Every view (campaign, date range, reason, drill-down) lives in the URL, so you can bookmark or share a link straight to what you're looking at.

 Filters now see enriched data

Payload filters used to only see raw payload keys, so any filter targeting an enriched field from Array, IPQS, EmailOversight, or Anura IP matched nothing. They now see enriched data too, matching how the Leads page already worked, so what you filter is what actually filters.

 Guided tour, tooltips, and smoother loading

A step-by-step tour walks you through the new page. Tooltips now only show up when text is actually clipped, so you're not distracted by hover popups on things you can already read. Charts and tables show placeholders while they load, so the page no longer jumps around as data comes in.

Buyer-Level Filter Management

Manage filters right from the buyer's edit page instead of hopping over to the campaign. Each buyer now has its own Filters tab where you can see every filter attached to that buyer, override values just for them, and detach a filter without leaving the page. The whole editor is easier to work in too, with URL-based tabs you can bookmark or share, form changes preserved as you switch tabs, and clearer cap validation errors.

- Set buyer-specific overrides for shared campaign filters

- Detach a buyer from a filter with one click when it no longer applies

- URL-based tabs, bookmark or share a link straight to a specific section

- Unsaved changes preserved across tab switches

- Clearer buyer cap error handling

Live Cap Usage on Buyers and Campaigns

See at a glance how much of each buyer's cap has been used, without opening the buyer detail page. Campaign Buyers now shows "used / total" for every buyer, and unlimited caps display as "used / ∞" so you can tell at once who's throttled and who isn't.

- Cap usage visible directly in the campaign buyers table

- Unlimited caps clearly marked with an infinity symbol

- Values update live as leads flow through

Anura Integration, Pay-As-You-Go or Bring-Your-Own-Key

Wire Anura verification into your campaigns without setting up a separate Anura account. Choose pay-as-you-go and Datahubb bills you at your account's per-verification rate, or bring your own Anura API key and route billing through your own contract. A billing state notice on the integration card tells you exactly which mode you're in.

- Pay-as-you-go, no separate signup, Datahubb handles billing

- Bring-your-own-key, use your existing Anura contract

- Per-verification snapshots preserve exact charges even if pricing changes later

- Clear billing state notice keeps costs transparent

Per-Buyer Rejection Columns in Lead Export

Export lead history with a separate column per buyer's rejection message, so you can filter and pivot the data any way you need. Available in the leads export column picker as "Rejection Reasons (per buyer)", admin-only.

- One column per rejecting buyer, named after the buyer's alias, company, and ID

- Streams in the background with no row cap

- Replaces the older single-value rejection column

Improvements

Meta CAPI Hardening and Readable Postback Logs

Meta CAPI postbacks now behave the way Meta expects, even when your lead payload has value fields as strings or timestamps in odd formats. Postback activity logs are also easier to scan, showing what was sent and what came back in a readable format.

- Event time and value fields automatically coerced to numbers

- Value rounded to Meta's expected precision

- Postback config change history now readable at a glance

Campaign Analytics, Persist Modal Column Layout

The campaign analytics modal now remembers your column layout between sessions. Pick which columns you want visible, arrange them in the order that makes sense to you, and they'll be there next time you open the modal.

- Column visibility and order saved per user

- Applied ordering is respected when you reorder columns

Offer Analytics, Traffic Source Channel Name

The traffic source filter in offer analytics now shows the channel name alongside the source, so you don't have to remember which numeric ID belongs to which channel.

- Channel name visible in the filter dropdown

Offer Filter, IP-Based Country and State Fallback

When a lead doesn't carry state or country in its payload, the offer filter now falls back to their IP-derived location so geo rules still work.

- State resolved from IP when missing from the payload

- Applies across offer walls and standalone offers

Fixes

- Fixed lead exports, CSV exports are now scoped to the user who created them so downloads can't be accessed by other users

- Fixed campaign analytics, buyer breakdowns are now scoped to delivery time on every campaign view

- Fixed campaign analytics, buyer "posted" counts now match the Pings view exactly, using delivery time as the source of truth

- Fixed supplier editing, supplier API keys no longer rotate when saving unrelated edits to internal suppliers

- Fixed analytics column reordering, dragging columns now respects the applied order

### 6.13.0 — v6.13.0 — June 29, 2026

Released: 2026-06-29

Buyer billables and invoicing, lead redistribution history, offer destination data pass-through, and test ping filtering.

New Features

Buyer Billables

- See exactly what each buyer owes you, broken down by activity, with a drill-down into the underlying transactions.

- New Buyer Billables page with a matrix view of buyers and what they've consumed

- Click any cell to drill into the underlying transactions in a modal

- Export the drill-down as a CSV that streams in the background, no row cap

- The Total and Buyer columns stay locked in view as you scroll wide tables

- Timestamps in exports honor your viewer timezone

Lead Redistribution Tracking

- Manual lead redistributions now leave a trail, so you can see exactly what was tried, what landed, and what got skipped.

-  Lead logs show every redistribution attempt with status badges (pending, skipped, not selected, accepted, rejected)

- The retry button only appears when a retry could actually succeed, so you stop chasing dead ends

- Redistributed leads now merge any persisted enriched fields back into the outgoing payload

Forward Consumer Data to Offer Destination

- Pass lead consumer fields straight through to the offer's destination URL, so partners can personalize the landing experience.

- Add lead field tokens to the offer's advertiser URL, with autocomplete suggestions as you type

Test Ping Filter

- Ping and post logs now have a Test column and an advanced filter, so you can include or exclude test traffic at a glance.

Improvements

Richer Buyer-Scoped Lead Views

- Buyer users now see the full lifecycle of their leads, including returned leads, delivery sessions, and any rejection instances. No more hidden context when a buyer is investigating an issue.

Faster Lead Filtering

- Lead list queries now use a more efficient lookup strategy, so filtered lead views load noticeably faster on large datasets.

Fixes

- Fixed Edit Buyer validation, error messages now point to the right field

- Fixed supplier editing, your internal supplier API key no longer changes when you save other edits

### 6.12.0 — v6.12.0 — June 17, 2026

Released: 2026-06-17

Smarter offer wall geo-blocking, advanced filtering on offers, state-level targeting, deeper click analytics, and a more flexible lead import.

New Features

- Smarter Offer Wall Geo Block — blocked countries can't slip through when tracking params are missing
- Country auto-detected from visitor IP

- Existing allow/block lists still apply

- Mismatched state vs country gets blocked

- Geo-blocked visits show in the Click dashboard

- Offers: Filter by Any Lead Field — filter any offer on any campaign lead field
- Multi-condition rules with existing operators

- Standard and custom campaign fields

- Override values via URL params; embed snippet generator included

- New Offer tab to add and test filters inline

- State-Level Geo-Targeting — target or block states on walls and offers
- Allowed/blocked states per country

- Same state value for targeting and reporting

- "Region" relabeled "State" across targeting UI

- Click Dashboard: Full Metrics and Lead Conversions — full click metrics plus lead attribution
- Metrics bar: impressions, clicks, conversions, EPC

- Filter by valid, bot, or blocked clicks

- Click-to-lead revenue attribution

- Test Lead badge on test traffic

- Blocked-visit geo on click details

- Lead Import: Timezone and Supplier Mapping — timezone-aware dates and supplier columns
- Pick import timezone for date parsing

- Map supplier column with pre-import validation

- Date format hints on created_at mapping

- Clearing fields auto-clears stale mappings

- Custom Columns and Advanced Filter in Rejection Reasons — tailor the rejection table to your workflow
- Column picker

- Advanced filters on reason, buyer, campaign

- Per-user saved settings

Improvements

- External ID Pass-Through — external IDs flow from wall embed to clicks and leads

- Wall Link Target — open offer links in same tab or new tab

- Conversion Details — offer and wall names preserved after rename or removal

- CSV Import Robustness — more forgiving file imports
- Excel header hidden chars stripped automatically

- Bad encoding rows flagged with clear errors

- Malformed cells fail without killing the import

- Transformer Consistency — identical boolean behavior everywhere; catalog refreshed

- Rejection Reasons Insights Filters — affiliate and sub-source filters; dependent filters reset on campaign switch

Fixes

- Fixed click details — full data in modal even with hidden table columns

- Fixed leads distribution timeline — pending confirmations no longer show as "wasn't selected"

- Fixed wall offer image preview — large images render without blocking upload

- Fixed ping and post logs pagination — empty sessions excluded from page counts

- Fixed traffic source ID validation — valid IDs pass in edge cases

- Fixed CSV header import — Excel hidden chars no longer break mapping

- Fixed lead import setup — supplier excluded from upsert keys, mapped correctly

### 6.11.0 — v6.11.0 — June 8, 2026

Released: 2026-06-08

Background CSV exports, manual lead retries, lead stage scoping, postbacks for traffic-source users, system rejection analytics, and SSRF protection across outbound HTTP.

New Features

- Background CSV Export — exports now run in the background, no more browser tabs hanging on big downloads
- Kick off a CSV export from Leads, Pings, Clicks, or any list view and it queues server-side instead of crunching in your browser

- A new Exports page lists every export with its status, so you can grab the file the moment it's ready

- Large exports stream straight from the backend — no more browser memory limits or stalled downloads

- Timestamps in exports honor your viewer timezone so the file matches what you saw on screen

- Manual Lead Redistribution — re-send a lead to a buyer manually for the times the automated flow didn't get the result you wanted
- Trigger a retry from the lead detail view to push a lead through delivery again

- Useful for recovering after a transient buyer-side failure, or testing a fix without re-importing

- Postbacks for Traffic-Source Users & Meta CAPI Preset — traffic-source partners can now manage their own postbacks, safely scoped to only what they should see
- A redesigned postback experience for traffic-source users with role-based access control

- Buyer names and campaigns they don't have access to are hidden from the list, with a tooltip explaining why

- Admins can mark specific campaign scopes as inaccessible — those scopes are surfaced clearly so traffic sources know what's off-limits

- A built-in Meta CAPI preset lets traffic sources spin up Meta conversion postbacks without manual config

- Historical System Rejection Analytics — a new view into why leads were rejected by Datahubb's own gates, per buyer, over time
- See historical counts of schedule, cap, and filter rejections for each buyer

- Spot patterns — like a buyer who's repeatedly hitting their cap — without digging through individual leads

- Campaign Filter Multi-Select — filter tables now support client-side multi-select, so you can stack filters on the spot without round-tripping the server

Improvements

- Lead Stage Scoping — lead stages can now be scoped to specific campaigns and clients instead of being global across your whole account, so stages from one pipeline don't pollute another

- Lead Import — map a created_at column with pre-flight date validation, plus the system fields lead_id and click_id so existing identifiers flow through cleanly; reverts now snapshot previous values, duplicate detection runs inside each import chunk, and upserts respect ID ordering so lineage stays intact

- Postback Editor UX — value rules can be collapsed with a count badge to scan long rulesets, and the Transformer Library picked up meta_hash and hash transformers

- Security — a new SSRF protection layer validates every outbound HTTP request (postbacks, integrations, webhooks) before it leaves Datahubb

- Analytics — the campaign modal opens at top level with its own date range filter and loading states, and the advanced filter sidebar closes when you click outside it

Fixes

- Fixed ping export — missing fields are now backfilled

- Fixed ping CSV export — JSON fields no longer corrupt the delimiter so the file opens cleanly

- Fixed Lead Import upsert — response logs no longer get overwritten, and manual postback fires now carry the correct buyer context

- Fixed campaign saving — campaigns now save reliably from the editor

- Fixed Advanced Distribution test buyer — testing a buyer works again on Advanced and Hybrid Tiered campaigns

- Fixed tier reordering — reordering distribution tiers no longer overflows the order field

- Fixed analytics campaign filter — inactive campaigns are filtered correctly and the campaign filter applies as expected

- Fixed column reordering — column order is now stable when you have a filtered column set

- Fixed ping rejection messages — the rejection message now includes the ping rejection context

- Fixed rejection reasons CSV export — viewer timezone is sent so timestamps match your view

### 6.10.0 — v6.10.0 — May 21, 2026

Released: 2026-05-21

Bulk lead import with manual postback fire, weighted and advanced distribution, a reworked campaign builder, email delivery for buyers, lead stage management, and a smarter CPA flow.

New Features

- Lead Import & Upsert — bring leads into Datahubb in bulk from a file and push them straight through your pipeline
- Upload a CSV (now up to 500MB), map its columns to your lead fields, and import — with country and additional field mapping supported

- Watch live progress with an ETA, and cancel mid-run if you need to

- Review an import history of every run, and revert an import entirely if something went wrong

- Imported leads land in their own Imported stage so they're easy to spot

- Manually fire postbacks for upserted leads right from the import screen — handy for backfilling conversions or re-notifying partners

- Weighted Distribution — split leads across buyers by the proportions you set
- Give each buyer a weight and Datahubb shares leads out to match — a buyer weighted twice as high gets roughly twice the volume

- Distribution is tracked fairly over time, so each buyer reliably lands their share instead of being decided by chance

- Perfect for honoring volume commitments or running controlled splits across buyers

- Advanced Distribution — build buyer groups and give each one its own routing rules
- Organize buyers into named, ordered groups, and leads flow group by group

- Each group runs its own sub-distribution type — Waterfall, Highest Bidder, or Weighted — so you can mix strategies in a single campaign

- Set a minimum bid floor per group that overrides the campaign default, so a premium group only takes leads above a higher price

- See the whole setup at a glance in a new distribution overview, built into the reworked campaign builder

- Reworked Campaign Builder — creating and editing campaigns is now a cleaner, guided experience
- A redesigned create and edit campaign flow

- A built-in guided tour and use-case picker to help you set up the right configuration faster

- Cloning now stops you before you clone without picking a target campaign

- Lead Stage Management — define the stages a lead moves through and give each one its own color
- Create stages, pick a color for each, and see colored stage badges across your leads

- Available to both admins and buyers

- Makes it easy to see at a glance where every lead sits in your pipeline

- Email Delivery for Buyers — deliver leads to buyers over email, a brand-new delivery channel
- Configure email delivery per buyer, with a CSV attachment of the lead

- Notification emails carry your branding, with a clean fallback footer for tenants without Brand Management

- Preview the exact HTML a buyer will receive — sanitized — right inside the ping modal

- Delivery failures are logged and surfaced in the post info so nothing fails silently

- Ingest Custom Response — decide exactly what data Datahubb returns to a buyer in the ingest response (formerly "Ingest Response Mapping")
- Configure buyer-specific data-path extractions so each buyer gets back the fields they expect

- Shared validation enforces a valid mapping before you can save

- Multi-Campaign Filtering — filter Leads, Pings, Clicks, and Conversions across several campaigns at once instead of one at a time

Improvements

- CPA Lead Flow — a CPA lead no longer counts as revenue the moment it's distributed; it's held as pending until the buyer confirms the sale via postback, then becomes sold or rejected. Revenue dashboards reflect only realized money, you can set a confirmation window per buyer, and any pending CPA lead that isn't confirmed in time expires automatically

- Enriched Lead Data — enriched fields can now flow through to postback payloads and the ingest response, and buyers can view the dynamic lead columns they're permitted to see, with access role-gated

- Lead Rejection Visibility — hover any lead to see a buyer rejection overview, rejection reasons now show on accepted leads too, and the postback table shows the related campaign and buyer at a glance

- Source Payout Visibility — when a supplier or traffic-source payout filter overrides the cost side, the lead timeline now shows a "Source Filter" indicator

Fixes

- Fixed ping export — exports now generate reliably

- Fixed campaign export filtering — pings and leads now export against the correct campaign

- Fixed delivery headers — empty header values are filtered out so delivery doesn't break

- Fixed campaign cloning — you're now stopped before cloning without selecting a target campaign

- Fixed the Campaign Integrations layout — the grid now aligns correctly

- Fixed enriched fields not loading in some lead views

- Fixed price display — prices now consistently show with two decimal places

### 6.9.0 — v6.9.0 — May 11, 2026

Released: 2026-05-11

A complete Postbacks rebuild, custom columns across Leads/Pings/Clicks, more Meta CAPI polish, and a timezone overhaul.

New Features

- Postbacks v2 — a brand-new Postbacks page with a redesigned configuration model for precise control over what fires, when, and how
- Build postbacks in a dedicated drawer-based editor — pick events, sub-events, define rules, set a signing secret, and target specific buyers

- Choose your body format (form, JSON, or raw) and add custom request headers per postback

- See exactly why a postback fired (or didn't) with the new Resolution Trace view

- Filter the conversion list by event type and sub-type — drill into specific outcomes without scrolling

- Inspect the full outgoing request — body, headers, signing — for every postback log

- Custom Columns for Leads, Pings, and Clicks — choose exactly which columns appear, with the catalog auto-surfacing fields from your wired-up integrations
- Add, remove, and reorder columns across Leads, Pings, and Clicks

- Per-user preferences are saved automatically — your view stays your view

- Required columns stay visible so essential context never disappears

- Long column labels wrap cleanly instead of breaking the layout

- Per-Lead Activity Timezone — lead activity timestamps now follow your personal timezone preference instead of forcing you to convert in your head

- Conversion Filters by Event Type — filter the conversion list by event type and sub-type, useful for breaking out CPA from CPL or zooming in on a single outcome

Improvements

- Meta CAPI — refined user_data fields, custom data mapping for richer event context, smarter action source defaults, and clearer documentation, so conversion events carry more signal for better matching and reporting

- Smarter Lead Catalog — automatically discovers fields from your active validation, enrichment, and credit integrations, so the right columns show up where you'd expect without manual setup

- Performance — lead detail pages load faster by fetching only what each request needs with smarter cache invalidation; the Ping/Post Log list got a query rewrite with a dedicated detail endpoint for opening a single record

- Timezone Handling — timezones work consistently across analytics, lead activity, and filter inputs; you can pass a timezone and browser timezone with any filter request, and the default Europe timezone was switched to Europe/Berlin so frontend and backend match

- UI & UX — copy a lead ID with one click, smoother loading skeletons that match your visible columns, the Ping Modal preloads while details fetch, stale requests cancel cleanly on navigation, and the country column is no longer shown by default

Fixes

- Fixed buyer delivery — empty request bodies no longer cause errors during ingest

- Fixed required column visibility — required columns can no longer be hidden by accident

- Fixed the catalog cache — column lists now refresh when you add or change a campaign field

- Fixed the Postback config editor — the JSON editor no longer enters a reload loop

- Fixed long column labels — they now wrap cleanly instead of overflowing the table

- Fixed timezone storage — the app no longer crashes if local storage is unavailable, and stale timezone requests are cancelled when the page changes

- Fixed lead delete UX — clearer feedback when removing leads

- Fixed drawer animations — Postback test, config, and value rule drawers now exit smoothly and stop background scroll while open

- Fixed the NOC integration — a class casing issue was preventing it from loading

### 6.8.0 — v6.8.0 — May 5, 2026

Released: 2026-05-05

Dutch market expansion, lifetime caps, Meta CAPI improvements, advanced response mapping, and a refreshed Offer Wall.

New Features

- Dutch Market Support 🇳🇱 — Datahubb now officially supports the Netherlands market
- NL-specific zip code validation so Dutch postal codes are recognized and validated correctly

- NL-specific phone number validation with proper Dutch number patterns

- Country-based gating for integration providers — your integrations only fire for the countries you've configured

- Multi-country payload normalization so leads from NL flow through your pipeline cleanly

- Lifetime Caps for Buyers — set caps that span the entire lifetime of a buyer relationship, not just daily or monthly limits
- New lifetime lead volume cap — total leads a buyer can ever receive

- New lifetime budget cap — total spend with a buyer over time

- Lifetime caps work alongside existing daily, weekly, and monthly caps

- Cap evaluation honors lifetime limits across all distribution modes

- Advanced Response Mapping for Buyer Delivery — a powerful new tool for handling responses from your buyers
- Configure custom response mappings per buyer to translate their responses into Datahubb actions

- Configured response rules now take priority over legacy duplicate detection

- Cleaner response mapping UI with improved accessibility

- Clone Inside Campaign — clone entities directly within a campaign
- Clone any buyer, supplier, or traffic source from within the campaign view

- Filter configurations come along with the clone

- One-click duplication — perfect for setting up similar configurations quickly

- Saved Export Preferences — set your favorite export preset and have it apply automatically
- Mark any export preset as your default

- Default preset is auto-applied across all export flows — no more re-selecting every time

- Auto-select happens the moment you set the default

Improvements

- Meta CAPI (formerly Facebook Pixel) — renamed and significantly enhanced
- Built-in support for value and currency fields for accurate conversion tracking

- Smarter postal code handling (supports both zip_code and postal_code)

- Improved phone validation logic

- More accurate fbc (Facebook click identifier) handling

- Per-Country Phone Number Formatting — phone numbers are now formatted by country of origin, making them easier to scan and verify across lead management and agent contact views

- Country Filtering in Lead Management — filter leads by country directly from the lead management view

- "Distribution" → "Delivery Method" — the Distribution field on Campaign Buyers was renamed for clarity, with a new delivery method filter on the campaign buyers page

- Pagination Everywhere — Buyers, Suppliers, and Traffic Sources lists now load in pages instead of all-at-once
- Faster page loads even on accounts with thousands of entities

- Server-side pagination on Campaign Detail sections too

- Campaign records load dramatically faster on accounts with millions of rows

- Internal Fields on Offers — new External Offer ID and Notes fields for your own tracking, visible in the offer list and editable inline

- Clickable Lead Links in Notification Emails — "Lead Sold" emails now include a clickable link straight to the lead

- Redirect to Original URL After Login — click a deep link while logged out, sign in, and you land exactly where you intended

- Offer Wall — major polish
- New draft status for offers — work-in-progress offers no longer require a traffic source

- Tabbed UI for Create Wall (matches Edit Wall)

- Zipcode targeting with multiple modes

- Status field on wall creation

- Required validation for offer destination URLs

- Two-decimal price display

- Advertiser options and loading skeletons in the analytics dashboard

- Initial offer syncing during wall creation

- Helpful instructional notice for custom country parameter setup

- Cleaner error messaging across offer forms

- Carousel navigation only shows when there are multiple offers

- Smarter Click Tracking
- Previous click ID and lead ID are now properly validated before being stored

- Click handling and backfill jobs work together more reliably

- User-agent strings now stored without truncation

- Array Pattern Mapper
- Direct passthrough capture for single-variable expressions

- Type-aware capture probing in the expression validator

- More accurate key matching using set comparison

- Pattern matching support for array.com leads

- Virtual field placeholders default to "Not returned" when no value is provided

- User-consent URL mapping for arrays

Fixes

- Fixed buyer ordering bug in the campaign buyers list

- Fixed the "Custom Mapping" button not responding when clicked

- Fixed missing buyer rows breaking the row-numbering in CampaignBuyers

- Fixed advertiser cache not invalidating after creating a new advertiser

- Fixed tab switch state being lost between sessions

- Fixed a country-sync issue affecting integration providers

- Fixed lead pipeline events being dispatched when the context was missing a lead or campaign

- Fixed price values not consistently rendering with two decimals

- Fixed buyer ordering in the buyer-side lead query (returned leads now correctly excluded from sold-only views)

- Fixed effective revenue calculation in the offer wall to enforce the static payout amount

- Fixed redundant transaction_id placeholder being injected into URLs

- Fixed user_agent field overflowing its column on long browser strings

### 6.7.0 — v6.7.0 — April 15, 2026

Released: 2026-04-15

New postback events, ingest logs, smarter click tracking, and a refreshed documentation experience.

New Features

- Subscription Billing — manage your Datahubb subscription directly from the app
- Upgrade, downgrade, and cancel your plan at any time

- Cancellations respect the end of your billing period — you keep access until then

- Clear subscription lock screen when a plan lapses, with a one-click reactivation button

- Store Leads Delivery Method — a new delivery option for buyers who want leads captured and held rather than delivered externally
- Available alongside your existing ping and post delivery methods

- Automatically hidden in contexts where it doesn't apply, so configuration stays clean

- Handles its own session flow so stored leads are tracked just like delivered ones

- Ingest Logs — a brand-new log view that shows exactly what happened during lead ingestion
- See every ingest attempt with its request type (ping / post) clearly labeled

- Runs in the background so ingest performance stays fast

- Two New Postback Events — LEAD & CPA — report outcomes back to your buyers and click partners
- LEAD event — for buyers who want to report the final sell status of a lead (sold / not sold) back to their systems

- CPA event — for click partners, works like CPC but fires on conversion rather than click

- Both events integrate with your existing postback configuration — no extra setup required

- Cross-Click Lead Attribution — your click tracking now follows the whole journey, even across multiple hops
- Every click now carries the previous click's ID and the associated lead ID

- New {dh_click_id} placeholder you can drop into any destination URL

- Pass dh_lead_id through the SDK to tie clicks to a specific lead from the start

- Click detail modal now shows the previous click and lead ID for easy tracing

- Works seamlessly with both SDK and non-SDK click flows

- Three New Transformers for Array Payloads — powerful new tools for working with array-valued fields
- iterate_array — loop through array elements when building a payload

- json_array_to_csv — flatten a JSON array into a clean CSV string

- json_array_to_xml — convert a JSON array straight to XML

- Array body handling improved across ping and post payloads

Improvements

- Filter Rule Analyzer — more reliable warnings
- Fixed warnings referencing rules that no longer exist

- Improved warning display in the filter table

- Filter ordering now recalculates correctly when you reorder rules

- Buyer Testing — friendlier guardrails
- Delivery schedules are bypassed when testing, so you can send test leads any time of day

- Buyer test ingests now run enrichment (minus rejection rules), so you see realistic results

- Documentation Overhaul — refreshed and expanded docs across the app
- Transformer, Shortcode, and Postback documentation pages redesigned for clarity

- Supplier docs V2 with richer code examples and a dedicated testing-mode section

- New ping_status column and company_name references in supplier docs

- Improved postback documentation accuracy

- Payload Editor — cleaner validation
- Confusing "unexpected closing brace" warnings removed from the payload validator

- Buyer payload JSON is now pretty-printed with proper indentation for easier reading

Fixes

- Fixed dh_click_id not being cleanly removed from destination URL query parameters

- Fixed dh_click_id placeholder leaking into destination URLs in SDK flows

- Fixed a conversion bug affecting ping payloads

- Fixed click verification returning the wrong error when a campaign page didn't exist — now returns a proper "not found" response

- Fixed invalid click IDs being accepted on lead payloads — IDs are now validated before use

- Fixed long page URLs being truncated in click records

- Fixed visibility on uploaded assets (logos, branding, return files) so they load reliably everywhere

### 6.6.0 — v6.6.0 — April 1, 2026

Released: 2026-04-01

Smarter delivery scheduling, powerful multi-step ping, new integrations, and a cleaner UI.

New Features

- Buyer Delivery Schedules — set exact time windows for when each buyer receives leads
- Configure per-day time slots (or mark a day as 24-hour)

- Timezone is required and respected across all schedule logic

- Schedule can be set during buyer creation or updated later

- Leads arriving outside the scheduled window are skipped — clearly flagged in the lead detail view

- Schedules are preserved when a buyer is disabled and restored when re-enabled

- Validation and error highlighting built into the save flow

- Multi-Step Ping — send ping requests across multiple steps in sequence, with independent pricing per step
- Each ping step can have its own price and shortcode mapping

- TCPA consent is applied on the final step only

- Ping logs now group sessions into an expandable step hierarchy for easy debugging

- Reordering steps re-indexes real-time pricing state automatically

- Null-safe response parsing with fallback to session context pricing

- Hybrid Tiered Distribution — combine weight-based tiers with Highest Bidder selection within each tier
- Assign tier weights to buyers — higher weight tiers are offered leads first

- Within a tier, the highest bidder wins (Highest Bidder logic)

- Falls through to the next tier if the top tier doesn't accept

- Available when setting up or editing a campaign's distribution type

- Minimum Bid Price per Campaign — prevent low-value bids from winning at the campaign level
- Set a floor bid price on any ping/post campaign

- Buyers bidding below the minimum are automatically excluded

- Test buyers bypass this check so you can still test freely

- New Integrations — Blacklist Alliance & NOC — two new third-party integration providers
- Blacklist Alliance: leads are checked against the blacklist during ingestion — invalid leads are rejected automatically

- NOC (National Opinion Center): tag-based payload mapping with Lead model support and enhanced configuration options

- Both providers appear in the integration settings alongside existing providers

- Supplier Payload Defaults Editor — define static or fallback values automatically injected into supplier payloads
- New PayloadDefaultsEditor in supplier create and edit forms

- Supports always (always override) and fallback (only when field is empty) modes

- Activity logs now capture payload_defaults changes

- Dynamic Parameter Mapping — map and pass dynamic values through click tracking and postbacks
- Supports both SDK and non-SDK click flows

- Configurable per postback or per click — no hardcoded keys

Improvements

- Test Postback — multi-config support
- Lets you test all configured postback URLs for a buyer or campaign in one go

- Results shown per-config with status and response detail

- Postback Configuration — enhanced UI & JSON editor
- Full JSON editor for request body configuration

- http_method and request_body are now recorded in postback logs

- Postback now supports multiple URLs per event

- Campaign-level postback URL override works reliably

- Filter Rule Analyzer — warnings in campaign filters
- Shadowing detection: a rule that will never be reached because an earlier rule always fires first

- Five warning types surface directly in the filter table UI

- API transform ensures warnings are computed before display

- PingList — bid price source badges
- Source badges distinguish between real-time bid, session fallback, and other sources

- Helps diagnose pricing issues without digging into raw logs

- Lead & Ping Lists — more columns & better display
- New columns and display improvements across Lead and Ping views

- Grouped view for pings of same buyer session

- Test conversions now tagged with a test badge in ConversionList

- Date Range Picker — rebuilt & reusable
- Consistent apply/reset behavior everywhere

- Reset now defaults to current month

- Outside days disabled

- Full test coverage via Vitest

- Loading Skeletons — smooth loading states across forms and tables
- FormCardSkeleton and TableCardSkeleton shown while data loads

- Prevents layout shift and blank screens during navigation

- Zero Price Warning — buyers with a price of $0.00 now trigger a warning before saving
- Confirmation modal explains the risk

- Prevents accidental zero-price buyer configuration

Fixes

- Fixed integration rule modal deleting all fields instead of only the one edited

- Fixed postback failing silently when a lead was unavailable

- Fixed supplier/traffic source payout calculations for filter-based rules

- Fixed color picker not appearing in light mode

- Fixed rejection reasons not clearing when the active filter changes

- Fixed leads select state not resetting after list refresh

- Fixed redundant ID filter in PingPostLog searches causing incorrect results

- Fixed authentication loop in two-factor auth flow

- Fixed campaign analytics scoping — non-admin users now only see their own campaigns

### 6.5.0 — v6.5.0 — March 16, 2026

Released: 2026-03-16

Easier testing, better security, and cleaner data views.

New Features

- Test Buyer Mode — try buyers without real leads, via a new Test Buyer button inside buyer settings
- Lets you send fake/mock leads to any buyer to see exactly what they receive

- Shows full step-by-step results: filters, final response, logs

- Supports both regular (ping/post) and one-to-one consent buyers

- Great for testing new buyers or debugging delivery problems safely

- Stronger Security with 2FA — Two-Factor Authentication (Google Authenticator style) is now live
- Turn it on in your account settings for extra protection

- Required code from your phone on every login

Improvements

- Lead & Ping Details Pages — cleaner, more focused views for suppliers and traffic sources
- Hides sensitive buyer/financial info automatically

- Shows fraud score, lead health, email/phone validity where allowed

- Better formatting and organization of enriched data

- Traffic Source Role — full click dashboard access for publishers
- Shows clicks, conversions, payouts and basic stats — only their own traffic

- No access to financials or other people's data

- Cleaner, safer view tailored just for them

- Campaign & Integration Settings
- Postback URLs can now be customized per campaign (override global setting)

- Integration toggles stay saved reliably after changes

- Better display of ActiveCampaign and other integration fields

- Activity & Test Logs
- Admins see clearer user activity logs with more filters

- Test buyer results show detailed, easy-to-read steps and logs

Fixes

- Fixed timezone confusion — all times now show correctly in your local time

- Fixed blank/white screens after new app updates

- Fixed selected buyer sometimes not appearing in views

- Fixed small visual bugs (dropdowns overlapping, spacing, hover effects)

- Fixed campaign cloning sometimes duplicating supplier info

- Fixed integration status flipping back off after saving

### 6.4.0 — v6.4.0 — March 10, 2026

Released: 2026-03-10

Easier security, better integrations, and a cleaner buyer experience.

New Features

- Two-Factor Authentication (2FA) with Google Authenticator — turn on 2FA in your account settings
- Adds an extra layer of protection using a code from your phone (Google Authenticator or similar apps)

- Makes your account much more secure — especially important for admins and anyone handling sensitive lead data

- New Integration: ActiveCampaign — connect your Datahubb account directly to ActiveCampaign
- Automatically send new leads into your ActiveCampaign lists or automations

- Choose which events trigger the sync (lead created, validated, sold, etc.)

- Map Datahubb fields to your ActiveCampaign custom fields easily

- Buyer Logo in Responses (Optional) — new per-campaign setting: "Include buyer company logo in API response"
- When turned on, your buyer logo URL is included in postback / response payloads

- Perfect for partners who want to display your branded logo in their system or confirmation pages

- Admin Activity Log Improvements — admins can now see a full log of user actions across the platform
- Filter by user, date, or specific actions (great for troubleshooting or compliance)

- Includes more details like which campaign or lead was affected

Improvements

- Postback & Campaign Settings — set custom postback URLs per campaign (override the global/default one)
- Very useful when different campaigns need to notify different systems

- Postback sending is now more reliable — fixed cases where it wasn't firing for certain statuses

- Integration Setup & Display
- ActiveCampaign setup screen is clearer with better field descriptions and mapping hints

- Integration toggles now behave consistently (no more flipping back to off after saving)

- Cleaner display of credentials and settings in integration logs

- Buyer Portal & Views
- Leads and pings tables look cleaner for buyers

- Better column order and shorter names where it makes sense

- Removed clutter (hidden export button & docs menu for buyers)

Fixes

- Fixed timezone display issues — times now show correctly in your local zone

- Fixed blank screen / loading problems after new builds

- Fixed cases where selected buyer wasn't showing properly in views

- Fixed integration status sometimes resetting after changes

- Fixed small visual glitches (dropdown overlaps, spacing, hover effects)

- Fixed campaign cloning sometimes duplicating supplier info incorrectly

### 6.3.0 — v6.3.0 — March 2, 2026

Released: 2026-03-02

Easier views for buyers, smoother analytics & integrations, and new phone verification service.

New Features

- Refreshed buyer dashboard — leads list now shows Status & Test flag first, cleaner buyer names in tables

- Subscriber Verify — new phone check service to catch invalid or risky phone numbers during lead processing

Improvements

- Modern, flexible analytics tables with column sorting, hide/show columns, and pagination

- Default date range changed to last 30 days for more useful starting point

- Renamed confusing column names for clarity (e.g. 'Validation Status' → 'Response Status')

- Sensitive information (API keys, secrets) hidden more securely in settings

- IP quality check logs are easier to read and understand

Fixes

- Fixed occasional blank/white screen when loading a fresh build

- Fixed selected buyer not appearing correctly in some views

- Removed unwanted formatting from phone numbers in agent tables

- Buyers now only see menus and buttons relevant to them

### 6.2.0 — v6.2.0 — February 23, 2026

Released: 2026-02-23

Major lead ingestion flexibility — now supports three payload formats for easier integration.

New Features

- Multi-Format Lead Ingestion — three ways to send leads:
- Headers + Flat JSON body (recommended for most integrations)

- Everything flat in JSON body (great for scripts & Zapier)

- Nested payload (backward compatible with existing integrations)

- New campaign toggle: 'Include buyer company name in API response'

- Copy Direct Link to Lead/Ping — one-click deep-link sharing

Improvements

- Stronger request validation & automatic normalization across all schemas

- Refreshed Payload Editor with transformer suggestions, auto-completions, live highlighting, and accurate error messages

Fixes

- Fixed confusing field update messages

- Fixed user role/permission display issues

- Fixed traffic source analytics page layout & data visibility

### 6.1.0 — v6.1.0 — February 15, 2026

Released: 2026-02-15

Deeper click tracking, admin impersonation, buyer value mapping, and in-app notifications foundation.

New Features

- Click Event Tracking — detailed activity tracking per click with dedicated event drawer

- Admin Impersonation — support teams can securely access user accounts for troubleshooting

- Buyer Value Mapping — configure how values are mapped before sending to buyers

- In-App Notifications foundation — alerts, reminders, and system notifications

- Enhanced invitation management — view pending, resend, or cancel invitations

- Dashboard date filtering and improved traffic source analytics

Improvements

- Improved phone, email, and IP validation at lead ingest level

- Google login support added

- Stronger request verification and token handling

- Unsaved changes alerts when leaving pages

Fixes

- Fixed buyer and traffic source analytics issues

- Corrected timestamp inconsistencies in reports

- Fixed campaign page update and lead filtering by buyer issues

- Removed incorrect phone format errors during lead submission

### 6.0.0 — v6.0.0 — January 29, 2026

Released: 2026-01-29

Major release: advanced analytics, campaign cloning, team invitations, rejection insights, and click tracking foundation.

New Features

- Advanced ping/post filtering panel with powerful new filter options

- Multi-chart dashboard — compare different metrics side by side

- Campaign Clone — duplicate entire campaigns with one click

- Bulk import campaign fields via CSV

- Custom column views for Leads, Pings, and Clicks tables

- Team invitations with resend and cancel options

- Mandatory Terms & Conditions acceptance flow

- Light & dark theme logos + custom favicon upload

- Redesigned click tracking system with SDK-based support

- Test-lead view in rejection reasons with occurrence counts

Improvements

- Currency field added to invoices and analytics

- Better dark mode contrast and responsive design

- More accurate EPC, conversion rate, and click statistics

- Active/deleted campaign filter and better page URL validation

- Standardized API error responses and feature flagging system

Fixes

- Fixed layout & spacing issues on medium/small screens

- Corrected ping totals appearing twice

- Fixed lead multi-select and bulk actions bugs

- Fixed various export issues (leads, clicks, pings, rejections)

- Corrected calendar cutoff and positioning problems

### 4.0.0 — v4.0.0 — 2025

Released: 2025-01-01

Advanced lead tracking, enhanced analytics, improved reporting, security validation, and many reliability fixes.

New Features

- Leads can now be marked as 'pinged only' for deeper visibility

- New filters to view leads by affiliate, sub-source, and buyer

- Improved campaign, buyer, supplier, and traffic analytics in real-time

- Exit offer analytics and revenue/margin breakdowns

- Phone and email validation for reposted leads

Improvements

- More descriptive error messages and enhanced logging

- Buyers created are now inactive by default for better access control

- Improved postback reliability and payload validation

- Updated documentation for easier onboarding

Fixes

- Resolved ambiguous column errors

- Fixed campaign filter deletion for large sets

- Eliminated over-counts and duplicate analytics

- Fixed lead price picking and record updating for direct posts

- Test leads excluded from analytics where appropriate

### 4.1.0 — v4.1.0 — 2025

Released: 2025-01-01

Direct post payout enhancements, validation improvements, and analytics fixes.

New Features

- Direct post API now includes payout information for CPL buyers

- Search traffic sources by company name

- Dynamic configurable timeout values for ping buyer and direct post HTTP clients

Improvements

- Test leads now bypass IP, phone, and email validation

- One-to-one constraints ignored for leads without consent

- Added bid logging for better visibility into distribution decisions

Fixes

- Buyer criteria matching now correctly treats value 0

- Default test-lead flag restored to expected behavior

- Added missing lead_sold_price and source_payout to lead exports

- Analytics date range selection now correctly includes selected dates

- Revenue and profit calculations fixed to respect date range filters

### 5.0.0 — v5.0.0 — 2025

Released: 2025-01-01

Complete overhaul of the rejection reason system for improved accuracy, traceability, and structured tracking.

New Features

- Rejection Reason Module — complete overhaul with APIs, migrations, and mappings for structured tracking

- Resolve API with advanced search, sort, and filter capabilities

- Rejection insights enriched with campaign and buyer context

- Rejection & Error Mapper Fields for buyers

- Pinged-Only Leads Filter — view ping-only entries while hiding incomplete leads by default

Improvements

- Improved rejection request validation and error handling

- Initial export API for rejection module

- Made silence-related fields nullable for better schema flexibility

- Improved backward compatibility for older rejection data

Fixes

- Resolved input handling issues in rejection requests

- Fixed inconsistencies between old and new rejection modules

- Removed redundant 'ping was rejected' log entries

### 3.0.0 — v3.0.0 — 2024

Released: 2024-01-01

Revamped Ingest V2 API with flexible ping/post backends, highest bidder distribution, and system short codes.

New Features

- Revamped Ingest V2 API with both ping and post backends

- Highest Bidder distribution — distribute leads based on highest bid

- Traffic Source Insights — analytics by affiliate ID and sub-sources

- Global Campaign Filters — apply filters to entire campaigns

- Auto-Generated Campaign Fields — required fields created automatically

- Real-Time Price Map for dynamic ping/post pricing

- Custom Headers for ping and post requests

- Enhanced lead logs with filters, payloads, responses, headers, and bid data

- System Short Codes for data manipulation:
- $lead_id, $payload, $payload:<KEY>

- $campaign_id, $campaign_name, $traffic_source_id

- $supplier_id, $supplier_name

- $ping_response, $post_response, $buyer_sell_price

Improvements

- Buyer price field renamed to 'Default price' — acts as fallback if no real-time price is set

- Advanced logging and delegated log output for better debugging

- Improved filter checks with payout rule integration

Fixes

- Filters now function correctly alongside payout rules (global, supplier, buyer levels)

- Added missing 'Matching fields' field to Dupechecker

### 2.0.0 — v2.0.0 — 2024

Released: 2024-01-01

New lead distribution models, integrated antifraud (IPQS & Anura), Pay Per Call with Twilio, and ping/post support.

New Features

- Ingest V2 API with dynamic lead distribution models

- Antifraud System — integrated IPQS & Anura for advanced fraud detection

- Pay Per Call (PPC) via Twilio Taskrouter:
- Phone number management

- Agent management

- Call logs and call analytics

- Ping/Post and Waterfall distribution methods

- Antifraud Timeline — visualize checks and activities per lead

- Ping/Post Timeline — track lead lifecycle across events

- Lead Type Filter for enhanced analytics

Improvements

- Campaign supplier management pages

- PPC phone number selection for campaigns

- Opt-In Message field for campaigns and buyers

- Improved ping fields UI

- Buyers can now be configured for ping/post delivery

- Minimum call duration setting for buyers

- Enhanced and more detailed logs on lead view

- Improved validation error messages

Fixes

- Duplicate reset password confirmation emails resolved

- Campaign summary list now correctly displays all campaigns in analytics

- Fixed persistent CSRF token mismatch errors

## Legal

### Acceptable Use Policy

URL: https://datahubb.io/code-of-conduct

1. Introduction & Purpose

This Acceptable Use Policy ("Policy") establishes the rules for using the Datahubb platform and its related services (the "Services"). Its purpose is to ensure a secure, reliable, and ethical environment for all clients, partners, and users (collectively, "you"). By accessing the Services, you agree to be bound by this Policy, which is an integral part of our Trial Subscription Agreement.

2. Platform Usage and Responsibilities

The Datahubb platform is a proprietary Software-as-a-Service (SaaS) solution designed for managing, tracking, and distributing leads, calls, and other marketing data between partners and buyers.

You agree to:

- Provide Accurate Information: Ensure all data provided to or through the platform is accurate, complete, and lawful.

- Maintain Compliance: Comply with all applicable laws and regulations, including but not limited to data privacy laws like GDPR, CCPA, and consumer protection laws like TCPA.

- Respectful Communication: Communicate with other users and Datahubb personnel in a professional and respectful manner.

- Intended Use Only: Use the Services solely for their intended functionality and for legitimate business purposes.

3. Account Security

- Confidentiality: You are responsible for maintaining the confidentiality of your account credentials (username and password). All activities that occur under your account are your responsibility.

- Authorized Use: Datahubb will treat all activity under your credentials as authorized by you. You may not share, sell, or transfer your account to another party without our prior written consent.

- Immediate Notification: You must notify Datahubb immediately at security@datahubb.io if you suspect any unauthorized access to or use of your account.

4. Prohibited Activities

Engaging in any of the following activities ("Prohibited Activities") is strictly forbidden and will be considered a material breach of our Trial Subscription Agreement:

a) System Integrity & Security:

- Unauthorized Access: Accessing or attempting to access non-public areas of the Services, our computer systems, or the technical delivery systems of our providers.

- Automated Tools: Using any robot, spider, scraper, or other automated means to access, copy, or monitor the Services without our express written permission.

- Vulnerability Probing: Probing, scanning, or testing the vulnerability of any system or network or breaching any security or authentication measures.

- Interference: Interfering with, or attempting to interfere with, the access of any user, host, or network, including by sending a virus, overloading, flooding, spamming, or mail-bombing the Services.

- Reverse Engineering: Reverse engineering, decompiling, disassembling, or otherwise attempting to discover the source code, object code, or underlying structure of the Services.

b) Data & Content Misuse:

- Fraudulent Data: Uploading or transmitting data that is fraudulent, misleading, or obtained through deceptive means (e.g., from stolen or compromised sources).

- Sensitive Information: Transmitting Sensitive Personal Information (SPI), such as government-issued identification numbers, financial account numbers, or protected health information, unless through a designated, encrypted field intended for that specific purpose.

- Illegal Content: Uploading or distributing content that is illegal, defamatory, libelous, obscene, or promotes violence or discrimination.

- Spam & Phishing: Using the Services to send unsolicited communications (spam), phishing attempts, or other fraudulent messages.

c) Intellectual Property & Third-Party Rights:

- Infringement: Violating the intellectual property rights of Datahubb or any third party. This includes removing or altering any proprietary notices or branding on the Services.

- Privacy Violations: Violating the data privacy rights of any individual, including processing personal data without a valid legal basis (e.g., proper consent).

5. Enforcement and Consequences

Datahubb reserves the right to investigate any suspected violations of this Policy. We may, at our sole discretion, take one or more of the following actions without prior notice:

- Content Removal: Remove or disable access to any content that violates this Code.

- Account Suspension: Temporarily suspend your access to the Services.

- Account Termination: Permanently terminate your account and your right to use the Services.

- Legal Action: Pursue legal remedies and seek damages for any harm caused by the violation.

We will determine, in our discretion, whether a violation has occurred. Our failure to enforce this Policy in every instance does not constitute a waiver of our rights.

6. Reporting Violations

If you become aware of any violation of this Policy, you must promptly report it to our compliance team at compliance@datahubb.io. You agree to cooperate fully with Datahubb in any investigation of suspected violations.

7. Disclaimer

While Datahubb implements strong security measures, we cannot guarantee that the Services will be free from security breaches. You use the Services at your own risk and are responsible for implementing your own security measures (e.g., strong passwords, two-factor authentication).

8. Acceptance

By accessing or using the Datahubb Services, you acknowledge that you have read, understood, and agree to comply with this Acceptable Use Policy. This Policy may be updated from time to time, and your continued use of the Services constitutes acceptance of any changes.

### Privacy Policy

URL: https://datahubb.io/privacy

1. Introduction

Welcome to Datahubb. This Privacy Policy explains how Datahubb B.V. ("Datahubb", "we", "us", or "our") collects, uses, discloses, and protects information from and about our users and visitors ("you"). This policy applies to our website, the Datahubb platform, and all related services (collectively, the "Services").

As a company based in the Netherlands, we are committed to complying with the General Data Protection Regulation (GDPR) and other applicable data protection laws.

2. Information We Collect

We collect information in the following ways:

a) Information You Provide to Us:

- Account Information: When you register for an account, we collect your name, email address, password, company name, and contact details.

- Payment Information: When you subscribe to a paid plan, we collect payment and billing information through our secure third-party payment processor. We do not store full credit card numbers on our servers.

- Communications: If you contact us directly (e.g., for support), we may receive additional information, such as the contents of your message and any attachments.

b) Information We Collect Automatically:

- Usage Data: We automatically collect information about your interactions with our Services, such as the features you use, the campaigns you create, IP address, browser type, device information, and pages visited.

- Cookies and Similar Technologies: We use cookies and similar tracking technologies to track activity on our Services and hold certain information. Please see our Cookie Policy for more details.

c) Information Processed on Behalf of Our Clients:

- Client Data: As a data processor, we process lead, call, and marketing data that our clients upload or transmit to the Platform. This data is owned and controlled by our clients. Our processing of this data is governed by our Data Processing Addendum (DPA) with each client.

3. How We Use Your Information

We use the information we collect for various purposes, based on the following legal grounds:

To Provide and Maintain our Services (Performance of a Contract):

- To create and manage your account, provide customer support, and process transactions.

- To operate, maintain, and improve the functionality of the Platform.

For our Legitimate Interests:

- To monitor and analyze usage to improve user experience and develop new features.

- To protect the security and integrity of our Services, prevent fraud, and enforce our policies.

- To send you service-related communications, updates, and administrative messages.

With Your Consent:

- To send you marketing communications and promotional materials. You can opt-out of these communications at any time.

To Comply with Legal Obligations:

- To comply with legal requirements, such as tax laws, and to respond to lawful requests from public authorities.

4. Data Sharing and Disclosure

We do not sell your personal information. We may share your information in the following limited circumstances:

- Service Providers: We may share information with third-party vendors and service providers who perform services on our behalf, such as payment processing, hosting, data analytics, and customer support. These providers are contractually obligated to protect your data.

- Legal Compliance: We may disclose your information if required by law, subpoena, or other legal process, or if we have a good faith belief that disclosure is necessary to protect our rights, your safety, or the safety of others.

- Business Transfers: In the event of a merger, acquisition, or sale of all or a portion of our assets, your information may be transferred as part of that transaction.

5. International Data Transfers

As we operate internationally, your information may be transferred to, and maintained on, computers located outside of your state, province, country, or other governmental jurisdiction where the data protection laws may differ.

For transfers of personal data from the European Economic Area (EEA) to countries outside the EEA, we rely on appropriate safeguards, such as the European Commission's Standard Contractual Clauses (SCCs), to ensure your data is protected.

6. Data Security

We implement robust technical and organizational security measures to protect your information from unauthorized access, use, or disclosure. These measures include encryption, access controls, and regular security assessments. However, no method of transmission over the Internet is 100% secure, and we cannot guarantee its absolute security.

7. Data Retention

We will retain your personal information only for as long as is necessary for the purposes set out in this Privacy Policy, or as required to comply with our legal obligations (e.g., for tax and accounting purposes), resolve disputes, and enforce our agreements. Client Data processed on behalf of our clients is retained according to the terms of our DPA with them.

8. Your Data Protection Rights (GDPR)

If you are a resident of the EEA, you have the following data protection rights:

- The right to access, update, or delete the information we have on you.

- The right of rectification: You have the right to have your information corrected if it is inaccurate or incomplete.

- The right to object: You have the right to object to our processing of your personal data.

- The right of restriction: You have the right to request that we restrict the processing of your personal information.

- The right to data portability: You have the right to be provided with a copy of your information in a structured, machine-readable format.

- The right to withdraw consent: You have the right to withdraw your consent at any time where we relied on your consent to process your information.

To exercise any of these rights, please contact us at privacy@datahubb.io. You also have the right to complain to a Data Protection Authority about our collection and use of your personal data.

9. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. We will notify you of any changes by posting the new policy on this page and updating the "Last Updated" date. We encourage you to review this Privacy Policy periodically.

### Trial Subscription Agreement

URL: https://datahubb.io/terms

Universal Clickwrap Agreement. This agreement is accepted electronically during onboarding. No physical signature is required.

This Trial Subscription Agreement (the "Agreement") is a legally binding contract between you ("Licensee," "Customer," "you," or "your") and Datahubb B.V., a private limited liability company incorporated under the laws of the Netherlands, with its registered office at Schoolstraat 95, 5038 RJ Tilburg, the Netherlands, registered with the Dutch Chamber of Commerce (KVK) under number 91662699 ("Datahubb," "Licensor," "we," "us," or "our").

By checking the acceptance box during the onboarding process on datahubb.io/trial/signup, you confirm that you have read, understood, and agree to be bound by this Agreement. If you are accepting on behalf of a company or other legal entity, you represent and warrant that you have the authority to bind that entity to this Agreement.

IMPORTANT: This Agreement covers two consecutive phases of your relationship with Datahubb. (1) A fourteen (14) day Trial Period during which you receive full platform access at no charge. (2) A paid monthly Subscription Term, billed per the Plan you select at signup, that begins automatically at the end of the Trial Period unless you cancel before then. The Services are provided "AS IS" without any warranty of fitness, reliability, or availability.

1. Definitions

- "Agreement" means this Trial Subscription Agreement, including all terms accepted during onboarding.

- "Services" means the Datahubb SaaS platform and all associated features, APIs, integrations, and documentation made available to Licensee.

- "Trial Period" means the fourteen (14) day period starting on the Effective Date during which Licensee may use the Services at no charge.

- "Plan" means the subscription plan and billing cycle (monthly or annual) selected by Licensee during onboarding.

- "Subscription Term" means the recurring billing period under the selected Plan that begins immediately at the end of the Trial Period unless this Agreement is cancelled before that date.

- "Confidential Information" means all non-public information disclosed by Datahubb, including but not limited to the Services, software, documentation, performance data, pricing, roadmap, and the terms of this Agreement.

- "Effective Date" means the date on which Licensee accepts this Agreement via the onboarding form at datahubb.io/trial/signup.

- "Customer Data" means all data, content, and information submitted, uploaded, or transmitted by Licensee through the Services, including lead data, buyer configurations, and transaction records.

2. Trial Period

- The Trial Period grants Licensee full functional access to the Services for fourteen (14) days starting on the Effective Date, at no charge.

- Licensee may cancel this Agreement at any time before the end of the Trial Period through account settings or by emailing support@datahubb.io. If Licensee cancels before the end of the Trial Period, no Subscription Term will begin and no fees will be charged.

- If Licensee does not cancel before the end of the Trial Period, the Agreement automatically continues into the Subscription Term and the first monthly invoice will be issued per Section 5.

- Datahubb will make commercially reasonable efforts to keep the Services available during the Trial Period, but no service level agreement (SLA) applies during the Trial Period.

3. License Grant and Access

- Subject to Licensee's acceptance of this Agreement and, after the Trial Period, timely payment of applicable fees, Datahubb grants Licensee a limited, non-exclusive, non-transferable, non-sublicensable, revocable license to access and use the Services for Licensee's internal business operations.

- Access to the Services will be granted via a digital invitation sent to the email address provided during onboarding.

- This license is personal to Licensee and may not be shared with, transferred to, or used for the benefit of any third party without Datahubb's prior written consent.

4. Plan Selection and Conversion

- During onboarding Licensee selects a Plan and a billing cycle (monthly or annual). The Plan selection determines the subscription fee and billing cadence that will apply once the Trial Period ends.

- Automatic Conversion. Unless cancelled per Section 2 before the end of the Trial Period, this Agreement automatically converts into the Subscription Term at the Plan rate selected at signup, with no further action required by Licensee.

- Changing Plans. Licensee may change to a different Plan after the conversion. Upgrades take effect immediately and are prorated. Downgrades take effect at the start of the next billing cycle.

5. Fees and Payment

- Trial Period. No subscription fees are charged during the Trial Period.

- Subscription Fee. Following automatic conversion, the subscription fee is the fee associated with the Plan selected during onboarding, billed in advance per the selected billing cycle.

- Pre-Payment Requirement. All subscription fees are due and payable in advance. Continued access to the Services after the Trial Period is contingent upon receipt of payment. No new billing-period access will be maintained or restored until the applicable fees have been received in full.

- Invoicing. Licensee will be invoiced in advance at the start of each billing cycle for the subscription fee of the upcoming period. Usage-based fees (such as Anura fraud verification) will be invoiced in arrears and added to the next invoice. Payment is due upon receipt of the invoice and must be completed before the start of the billing period.

- Payment Method. Payment is processed via Stripe or such other payment processor as Datahubb may designate. All fees are invoiced in United States Dollars (USD). For tax purposes, USD amounts are converted to EUR using the European Central Bank (ECB) reference rate on the invoice date. Applicable taxes (including VAT) are determined by the location of the Licensee's billing address and added to invoices where required by law. EU-based Licensees with a valid VAT identification number may qualify for the reverse-charge mechanism under Article 44 of the EU VAT Directive.

- Anura Pay-As-You-Go Fraud Verification. Datahubb offers optional pay-as-you-go access to Anura fraud verification through its partnership with Anura. This service is opt-in and only applies when Licensee explicitly activates Anura fraud verification within the Datahubb platform. No usage-based fees are charged unless and until the service is activated by Licensee. This option is available only to Licensees who do not hold their own Anura license; Licensees who use their own Anura license are billed directly by Anura under their own contract, and this provision does not apply to them. Once activated, the Anura pay-as-you-go rate is billed in arrears based on actual usage:

 ServiceRate

 Anura Pay-As-You-Go Fraud Verification$0.05 per verification

Datahubb reserves the right to introduce additional usage-based services. Licensee will be notified of any new usage-based fees at least fourteen (14) days before they take effect.

6. Failed or Missed Payments

This Section applies once a Subscription Term has begun. If a scheduled payment fails or is not received by the due date, Datahubb will notify Licensee via email. Licensee has a grace period of twenty-four (24) hours from the time of notification to complete the payment. If payment is not received within this 24-hour grace period, Datahubb shall restrict access to the Services in accordance with the tiered suspension schedule set forth below.

7. Tiered Suspension Schedule

Upon expiration of the 24-hour grace period without successful payment, access to the Services will be restricted in stages as follows:

 StageTimeframeRestriction

 124h to 48h after grace periodLead ingestion paused; dashboard read-only

 248h to 7 daysFull platform access suspended

 3After 7 daysAccount scheduled for termination

- Restoration of Access. If Licensee completes payment during any stage of the suspension schedule, full access to the Services will be restored within four (4) business hours of payment confirmation. Any data collected during the suspension period will be retained and accessible upon restoration.

- Accumulated Fees. Suspension of access does not relieve Licensee of its obligation to pay all outstanding fees. Any usage-based fees incurred during the suspension period remain payable in full.

8. Onboarding and Support

- Trial Support. During the Trial Period, Licensee receives support via support@datahubb.io. Response times during the Trial Period are not guaranteed.

- Included Onboarding. Onboarding is provided only to paid Subscription Term customers and is not part of the Trial Period. During the first month after the Trial Period ends and the Subscription Term begins, Datahubb will provide onboarding services at no additional charge. Onboarding services include implementation of buyers, suppliers, traffic sources, and integrations, as well as training for daily platform usage. Custom programming, custom development, and bespoke feature requests are excluded from onboarding services.

- Priority Custom Work. Custom development, bespoke feature requests, and other work that Licensee wishes Datahubb to prioritize ahead of its normal product roadmap and planning are available on request. Scope, deliverables, rate, and estimated hours are agreed in writing before work begins.

9. Customer Data

- Ownership. Licensee retains all right, title, and interest in and to Customer Data. Nothing in this Agreement transfers ownership of Customer Data to Datahubb.

- License to Datahubb. Licensee grants Datahubb a limited, non-exclusive license to process, store, and transmit Customer Data solely for the purpose of providing and improving the Services.

- Backups. Licensee is responsible for maintaining independent backups of any critical data. Datahubb maintains reasonable backup procedures but does not guarantee recovery of Customer Data in all scenarios.

- Data Export. Upon termination of this Agreement, Licensee is entitled to a one-time export of their raw business data in SQL format. Datahubb will make such data available within thirty (30) days of termination.

10. Intellectual Property and Confidentiality

- Ownership of Services. All rights, title, and interest in and to the Services, including all intellectual property rights therein, are and shall remain the exclusive property of Datahubb. This Agreement does not grant Licensee any rights to Datahubb's intellectual property except for the limited license set forth in Section 3.

- Feedback. Any feedback, suggestions, ideas, or bug reports provided by Licensee regarding the Services shall become the sole property of Datahubb. Datahubb may use such feedback for any purpose without restriction or compensation to Licensee.

- Confidentiality. Licensee agrees to hold all Confidential Information in strict confidence and not to disclose it to any third party without Datahubb's prior written consent. This obligation shall survive termination of this Agreement for a period of three (3) years.

- Use Restrictions. Licensee shall not: (a) copy, modify, or create derivative works of the Services; (b) reverse-engineer, decompile, or otherwise attempt to derive the source code; (c) sell, sublicense, lease, or transfer the Services to any third party; (d) remove or alter any copyright or proprietary notices; (e) use the Services to develop a competing product; or (f) share access credentials with unauthorized persons.

11. Disclaimers and Limitation of Liability

- AS IS Disclaimer. THE SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT ANY WARRANTY OF ANY KIND, WHETHER EXPRESS, IMPLIED, OR STATUTORY. DATAHUBB EXPRESSLY DISCLAIMS ALL WARRANTIES, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, RELIABILITY, AVAILABILITY, NON-INFRINGEMENT, AND ANY WARRANTIES ARISING FROM COURSE OF DEALING OR USAGE OF TRADE.

- Limitation of Liability. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, DATAHUBB'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT SHALL NOT EXCEED THE TOTAL FEES ACTUALLY PAID BY LICENSEE TO DATAHUBB DURING THE THREE (3) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM. WHERE NO FEES HAVE BEEN PAID, DATAHUBB'S TOTAL AGGREGATE LIABILITY SHALL NOT EXCEED ONE HUNDRED EUROS (€100).

- Exclusion of Damages. IN NO EVENT SHALL DATAHUBB BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO LOSS OF PROFITS, REVENUE, DATA, BUSINESS OPPORTUNITIES, OR GOODWILL, REGARDLESS OF THE THEORY OF LIABILITY AND EVEN IF DATAHUBB HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

- Data Loss. WITHOUT LIMITING THE FOREGOING, DATAHUBB SHALL NOT BE LIABLE FOR ANY LOSS, CORRUPTION, OR UNAVAILABILITY OF CUSTOMER DATA. LICENSEE IS SOLELY RESPONSIBLE FOR MAINTAINING INDEPENDENT BACKUPS.

12. Term, Termination, and Renewal

- Trial Period. This Agreement begins on the Effective Date with the fourteen (14) day Trial Period.

- Cancellation During Trial Period. Licensee may cancel this Agreement at any time before the end of the Trial Period through account settings or by emailing support@datahubb.io, with no charge.

- Automatic Conversion to Subscription Term. If this Agreement is not cancelled before the end of the Trial Period, it automatically continues into a Subscription Term at the Plan rate selected at signup, billed per the selected billing cycle.

- Cancellation During Subscription Term. Licensee may cancel the Subscription Term at any time. Cancellation takes effect at the end of the then-current billing cycle. Fees already paid for the current billing cycle are non-refundable.

- Termination for Cause. Either party may terminate this Agreement immediately upon written notice if the other party commits a material breach and fails to cure such breach within thirty (30) days of receiving written notice.

- Effect of Termination. Upon termination: (i) all licenses granted herein shall immediately cease; (ii) Licensee shall cease all use of the Services; (iii) Licensee may request a data export within thirty (30) days; and (iv) after the export period, Datahubb shall delete Customer Data unless retention is required by applicable law.

- No Refunds. Subscription fees already paid are non-refundable, except as required by applicable law.

13. Data Protection

- Datahubb processes personal data in accordance with its Privacy Policy.

- Where Licensee is established in the European Economic Area (EEA) or processes personal data of EEA residents through the Services, the Data Processing Agreement (DPA) published at datahubb.io/dpa applies and forms an integral part of this Agreement.

- Where Licensee processes Protected Health Information (PHI) through the Services, a separate Business Associate Agreement (BAA) must be executed before any PHI is transmitted to the platform. Contact legal@datahubb.io to initiate a BAA.

- Licensee is solely responsible for ensuring that its use of the Services complies with all applicable data protection laws, including but not limited to GDPR, CCPA/CPRA, TCPA, and CAN-SPAM.

14. General Provisions

- Entire Agreement. This Agreement, together with the Privacy Policy and the DPA (where applicable), constitutes the entire agreement between the parties regarding the Services and supersedes all prior or contemporaneous agreements, representations, and understandings. This Agreement is not subject to negotiation or modification by Licensee.

- Amendments. Datahubb may modify this Agreement by posting an updated version on its website and providing at least thirty (30) days' notice via email. Continued use of the Services after the notice period constitutes acceptance of the modified terms.

- Severability. If any provision of this Agreement is held to be invalid or unenforceable, the remaining provisions shall continue in full force and effect.

- Waiver. Failure to enforce any provision shall not constitute a waiver of that provision.

- Assignment. Licensee may not assign this Agreement without Datahubb's prior written consent. Datahubb may assign this Agreement in connection with a merger, acquisition, or sale of substantially all of its assets.

- Force Majeure. Neither party shall be liable for any failure or delay due to circumstances beyond its reasonable control, including acts of God, natural disasters, pandemics, war, government actions, power failures, or internet outages.

- Notices. All notices shall be sent to the email address associated with Licensee's account or, for notices to Datahubb, to legal@datahubb.io.

15. Governing Law and Dispute Resolution

- Governing Law. This Agreement shall be governed by and construed in accordance with the laws of the Netherlands, without regard to its conflict of laws principles.

- Dispute Resolution. Any dispute arising out of or in connection with this Agreement shall first be attempted to be resolved through good-faith negotiation for a period of thirty (30) days.

- Jurisdiction. If a dispute cannot be resolved through negotiation, the competent court of Zeeland-West-Brabant, the Netherlands, shall have exclusive jurisdiction.

16. Electronic Acceptance

- This Agreement is accepted electronically. By checking the acceptance box during the onboarding process at datahubb.io/trial/signup, Licensee agrees to be bound by all terms of this Agreement.

- Electronic acceptance constitutes a valid and binding signature under applicable law, including but not limited to the Dutch Civil Code (Burgerlijk Wetboek), the EU eIDAS Regulation, and the US Electronic Signatures in Global and National Commerce Act (E-SIGN Act).

- Datahubb records the following information at the time of acceptance: the identity of the person accepting, the company name, the date and time of acceptance, the IP address from which the acceptance originated, and the version of the Agreement accepted. This record constitutes proof of acceptance.