Ping/post looks like a worse deal on paper. Instead of one HTTP call per buyer you make two, which doubles your outbound volume and adds a round trip of latency to every step of the waterfall. For a three-buyer waterfall that is six calls where you used to make three.
The reason to do it anyway has almost nothing to do with efficiency.
The question you are really answering
When you post a full lead to a buyer, you hand over a name, a phone number, an email address and whatever else the form collected. If they decline, you do not get that back. They have it. Their system logged it, their suppression list has it, and depending on the buyer and the jurisdiction, their sales team may have it too.
Now run a waterfall of four buyers where three decline. You have distributed a person's contact details to four companies in order to sell it to one.
Ping/post splits that in half. The ping asks the question — do you want a lead like this, and what will you pay? — using only the parts that describe the lead rather than identify the person. State, ZIP, the qualifying answers, maybe the vertical. The post follows with the actual contact details, and only to the buyer who said yes.
Same waterfall, one company ends up holding the phone number.
What goes in a ping
This is a judgement call your system will not make for you. Nothing prevents you from putting {{phone}} in a ping template; it will send it perfectly happily.
A reasonable default is: everything a buyer needs to price the lead, nothing that would let them contact the person.
Usually fine: state, ZIP, the answers to qualifying questions, how long ago the lead was captured, which vertical it came from, a lead ID of your own.
Usually not: first and last name, phone, email, street address, anything free-text the visitor typed, since people put their phone number in comment boxes constantly.
The grey area is ZIP. It is genuinely needed for pricing in most geographic verticals, and it is also identifying in combination with other fields. Most operators send it. Know that you are making a choice.
The pricing side effect
There is a commercial reason too, and for some operators it matters more than the privacy one.
A ping response usually contains a bid. That turns your waterfall from a fixed running order into something closer to an auction: you can ping several buyers, see what each will pay for this specific lead, and post to whoever bid highest rather than whoever happens to sit at the top of your list.
That only works if your buyers actually price per lead rather than paying a flat rate per accepted lead in a category. Plenty do not. Ask before you build your routing around it.
Where the latency actually lands
The doubled call count sounds worse than it is, because of when it happens.
If your pipeline responds to the visitor first and routes afterwards — which it should, for reasons worth their own post — the person who filled in the form has already seen their thank-you page before the first ping goes out. The extra round trip costs you nothing they can perceive.
What it does cost is wall-clock time inside your routing window, and that is a real constraint. A four-buyer ping/post waterfall with ten-second timeouts has a worst case of eighty seconds. Keep per-call timeouts short. A buyer who has not answered in ten seconds is not about to give you a good answer in twenty.
When not to bother
Ping/post is worth skipping when:
- Your buyer does not support it. Many do not. A ping to an endpoint expecting a full lead just fails.
- You have one buyer. There is nobody to protect the data from. Post it.
- Your buyer pays a flat rate and accepts nearly everything. If acceptance is 90 percent, you are adding a call to avoid an exposure that happens one time in ten.
The sweet spot is exactly where lead selling usually lives: several buyers, acceptance rates well under half, and a waterfall that walks past two or three companies before it finds the one that wants this lead.
That is a lot of unnecessary copies of somebody's phone number. Ping first.