Guide · RTB

What is RTB in pay-per-call? Real-time bidding call auctions explained

Real-time bidding decides who buys each inbound call and for how much — in the fraction of a second before the caller connects. Here's how a pay-per-call auction actually works, why you only ever see the auctions you win, and how to use the bids you're missing.

Updated July 2026

In pay-per-call, most inbound calls aren't sold at a fixed price — they're auctioned. Real-time bidding (RTB) is the mechanism that decides, for each individual call, which buyer gets it and what they pay. Understanding how that auction works is the difference between pricing your traffic on real demand and guessing.

What is real-time bidding (RTB)?

Real-time bidding is an automated auction that runs per call. The moment an inbound call arrives, your call-tracking platform (Ringba, Retreaver, CallGrid, TrackDrive, and others) sends a ping — a small request describing the caller — to a set of buyers at the same time. Each buyer's system evaluates the ping against its own targeting and budget and answers within milliseconds with either a bid (an amount it's willing to pay for the call) or a decline. The platform then connects the caller to a winning buyer. All of this happens before the caller ever hears a human.

How a pay-per-call auction works, step by step

  1. A call comes in. A consumer dials a tracked number from an ad, a landing page, or a click-to-call.
  2. The platform sends pings. It fans out a request to eligible buyers with what it knows about the caller — area code, state, zip, the campaign, and any qualifying data.
  3. Buyers bid or decline. Each buyer's endpoint returns a price or a reason it's passing (out of capacity, duplicate, filter mismatch, floor too high, and so on).
  4. A winner is chosen. The platform applies its routing rules — often, but not always, the highest bid — and connects the caller to that buyer.
  5. The rest disappears. Every other bid, decline, and latency figure evaporates. Your platform records only the winning bid.

The problem: you only see the auctions you win

Because the platform routes the call to a single buyer, that's the only bid it reports back to you. The buyers who bid lower, the buyers who declined, how long each took to respond, and why each one passed — that information lives in the ping traffic between the platform and each buyer, and it's never stored anywhere you can analyze. So the data you most need to price and route traffic well is exactly the data you can't see.

This matters because a single winning number hides the shape of demand. A call that sold for $18 might have had three buyers at $30 who timed out, or it might have had exactly one bidder and no competition at all. Those are completely different situations — and they call for completely different decisions — but from the winning bid alone they look identical.

What the losing bids actually tell you

Capture the full auction and every response becomes a signal:

  • Bid amount — what each buyer was willing to pay reveals the true market value of that ping, by geo and by time of day.
  • Latency — how fast a buyer responds. A strong buyer that consistently answers too slowly is losing auctions you would otherwise win, and costing you money without either of you noticing.
  • Decline reason — a duplicate, an out-of-cap condition, a filter mismatch, or a floor set too high. Patterns in the reasons point straight at the fix.
  • Coverage gaps — geographies and times where few or no buyers bid at all, so you can stop feeding traffic that has no demand behind it.

How operators use captured auction data

Once you can see every bid, a few high-leverage moves open up:

  • Price traffic on real demand. Knowing what everyone bid — not just the winner — tells you what a ping is worth, so you can negotiate and route accordingly.
  • Fix filters and floors. If a buyer is rejecting a large share of pings for one reason, you can adjust the configuration instead of guessing why volume is soft.
  • Catch slow buyers. Latency on every response surfaces buyers timing out of auctions, so you can raise timeouts, warn the buyer, or shift the traffic.
  • Prove value to partners. A complete demand picture is a far stronger basis for a conversation with a buyer or publisher than a single routed price.

How Clario captures the full auction

This is exactly what Clario's Auction Intelligence does. It sits alongside the live auction on every inbound ping and records what actually happened — the bid, the latency, the winner, and the real reason each buyer passed — including the auctions you lose. It's logging-only, so it never changes how your calls route; it just gives you the demand picture your platform was throwing away. Paired with Coverage Intelligence, you can then see which geographies pay best and route accordingly.

Auction data without caller identity

There's a line worth drawing here, because not everyone draws it. An auction ping describes a consumer who hasn't connected to your business — and on the auctions you lose, never will. Capturing the commercial shape of that auction is legitimate market intelligence. Harvesting the identity of every consumer who passes through it is a different activity with a different set of risks, and it isn't one Clario is in.

So Clario records bids, accept and reject outcomes, latency, and coverage by postal code — and replaces the caller's number at the moment of capture with a non-reversible identifier. We don't retain the number and can't reconstruct it. Your own completed calls are separate and stay complete, because those are your records. The distinction is written into our Privacy Policy, not just described here.

RTB is what makes pay-per-call efficient — buyers compete, and good calls find their highest bidder. But you can only optimize what you can measure, and the winning bid alone measures almost none of it. Capturing the whole auction turns a black box into a market you can actually read.

Frequently asked questions

What does RTB mean in pay-per-call?

RTB stands for real-time bidding. When an inbound call comes in, the tracking platform sends a 'ping' describing the caller to multiple buyers at once, each buyer responds with a bid (or a decline), and the call is routed to a winning buyer — all in a fraction of a second, before the caller is connected.

Why can't I see the auctions I lose?

Your call-tracking platform only reports the winning bid, because that's the buyer it routed the call to. The other bids, the declines, and the reasons buyers passed happen in the ping traffic between the platform and each buyer and are never persisted anywhere you can query — so the full auction is invisible by default.

What data does a losing bid contain?

For every buyer response you can capture the bid amount, how fast it came back (latency), whether it was an accept or a decline, and the decline reason — for example a duplicate, an out-of-cap condition, a filter mismatch, or a floor that was too high. Taken together across all buyers, that's the real demand curve for each ping.

How does capturing bids help me make more money?

Knowing what every buyer bid — not just the winner — tells you what your traffic is actually worth by geo and time, which buyers are timing out of auctions you'd otherwise win, and which filters or floors are quietly rejecting good calls. You can then reprice, re-route, or fix the configuration instead of guessing.

Does capturing auctions change how my calls route?

No. Auction capture is logging-only and sits alongside the live auction — it records the pings and bid responses without altering the outcome, so routing behaves exactly as it did before.

Stop operating from
scattered tabs.

Put calls, QA, auction visibility, reporting, and AI actions in one controlled operating layer.