Ping Post Lead Distribution: How Insurance Leads Are Auctioned

Meridian Exchange is an invented Denver-based lead platform we will use to make this concrete. On a normal weekday it runs a few hundred thousand pings. When its engineering team cut the tier-one timeout from 1,200 milliseconds to 800 last winter, revenue dropped about four percent overnight and nobody connected the two events for nine days. That is ping post lead distribution in one anecdote: a config value nobody thinks of as a business decision, quietly repricing the whole inventory.

Anatomy of a ping and a post

The consumer hits submit. Before the thank-you page renders, the platform fires a ping to every eligible buyer — a stripped record with no name, no phone, no email. Enough to price the lead, not enough to work it.

A typical ping payload carries ZIP or state, date of birth or age band, current insurance status and carrier, vehicle year and make, driver count, incident history flags, coverage type sought, and a lead ID. Buyers answer with accept or reject, a bid, and sometimes a buyer-side reference. Then the platform picks a winner and fires the post: the same record plus contact details and the consent certificate URL.

Two calls, two failure modes. A ping that carries too little data gets low bids because buyers price uncertainty. A ping that carries too much lets a buyer reject on the ping and still have learned something. Good ping post lead distribution design sits between those.

How the tree is ordered

The tree is a prioritised list of buyers, usually grouped into tiers. Tier one gets asked first, at the highest floor price. If nobody accepts, the ping cascades to tier two at a lower floor, and so on until either someone buys or the lead goes unsold.

The honest caveat: performance weighting sounds obviously correct and is genuinely hard to run. Return data arrives weeks after the sale, so your weights are always describing a panel that has since changed. Meridian tried it, over-corrected against a buyer having a bad month, and lost the relationship.

Timeout budgets and latency

Every tier costs wall-clock time. The consumer is watching a spinner. Blow past two or three seconds and abandonment rises, which costs you more than the incremental bid you were waiting for.

Pricing out a ping post timeout change

Meridian's four percent is worth reconstructing, because it is the clearest case of a config value behaving like a price change. The arithmetic below is illustrative, but the mechanism is not. Most ping post revenue leaks look exactly like this one: invisible in every report except the total.

Take a tier-one panel of nine buyers responding with a p50 of 340ms, a p90 of 760ms and a p95 of 1,150ms. At a 1,200ms window, essentially the whole tier gets to bid. Cut to 800ms and you still keep the p90 — but you lose the slowest tenth, and in Meridian's panel the two slowest endpoints were also the two highest bidders, because their pricing logic did more work per ping. Losing roughly eight percent of tier-one bids on records that then cleared in tier two at a lower floor is enough to produce a four-point revenue gap with no visible change in traffic, accept rate, or sold volume.

The lesson generalises past this one config. Latency and bid quality tend to correlate in the wrong direction, so a timeout cut never removes a random slice of demand — it removes the slice that thinks hardest about price.

How to measure it before you ship it

• Log every ping response with buyer, latency and bid, not just the winning one
• Replay a week of those logs against the proposed timeout and total the bids you would have lost
• Compare that number to measured abandonment at your current thank-you delay, not an assumed one
• Ship timeout changes on their own, never bundled with a tier reorder, so revenue movement stays attributable
• Alert on p95 per buyer, so a degrading endpoint surfaces before it quietly reprices a whole tier

Duplicate logic and caps

Duplicate rules decide whether the same consumer can be sold again, to whom, and after how long. Get them wrong in one direction and you sell the same person to the same buyer twice in a week, which triggers returns. Get them wrong the other way and you suppress legitimate re-shopping.

• Define the dedupe key explicitly: phone, email, or a hash of both
• Set the window in the contract, not just in the config — 30 and 90 days are common
• Decide whether dedupe is per-buyer or platform-wide before launch
• Handle caps as first-class objects: daily, hourly, per-state, per-sub-ID
• Log every suppression with a reason so disputes are answerable

Caps also cause the most predictable revenue leak in ping post lead distribution. Buyers fill their daily volume by mid-afternoon, the tree cascades downward, and the same traffic clears materially lower after 3pm. Dayparting your media against your buyer caps is free money that most publishers never collect.

Accept rate as a health metric

Accept rate — pings that produce at least one bid — is the fastest read on ping post health. When it drops, three causes cover almost everything: a buyer paused without telling you, a traffic source shifted into geography your panel does not want, or a field mapping broke and buyers are rejecting on malformed data.

Where integrations break

Almost never in the interesting places. The recurring list is mundane: a buyer changed a required field and did not send a spec update, a state code arrives as a full name instead of an abbreviation, a date format flips between endpoints, a certificate URL is passed but never fetched, or a buyer's sandbox accepts everything and their production endpoint accepts nothing.

Start with a waterfall if you have three buyers. Move to ping post lead distribution when you have eight and can see the spread between what your best and worst buyers will pay for the same record. The return terms that sit alongside all of this are covered in designing a return policy both sides will sign, and the wider chain in the US operator guide.