The price of a single verification attempt says nothing about real spend if half the codes never arrive. A route can cost pennies per attempt and still cost more than a competitor priced three times higher — simply because its code arrives several times more often. Here is how to calculate verification conversion, work out the real cost of a successful code, and find the routes that are due to be switched off.

Delivery rate, not attempt price, is the metric that matters

The activation price is fixed and known upfront, so it is easy to compare between routes. The delivery rate — the share of attempts where the code actually arrived and was entered — only becomes visible after the fact. That is why cheap routes with a low delivery rate look profitable on the price list and turn out lossy in the report: every successful verification is paid for not with one attempt, but with several.

If a route delivers the code on 9 attempts out of 10, the attempt price is almost the whole real cost. If only 2 out of 10 land, you pay for five attempts to get one working code — a completely different economics.

The formula for the real cost of a successful verification

Real cost = attempt price ÷ share of successful attempts. The share is calculated as the ratio of verifications completed by entering the code to the total number of numbers requested over the period.

Example. Route A costs $0.03 per attempt at a 20% delivery rate: the real cost of a successful verification is 0.03 ÷ 0.2 = $0.15. Route B costs $0.04 per attempt — a third more on the price list — at an 80% delivery rate: 0.04 ÷ 0.8 = $0.05. Route A, which looked cheaper, ends up three times more expensive than Route B per code actually received. The attempt price is not a cost on its own — it is only the numerator; the denominator decides everything.

Which breakdowns to track for the formula to work

An average delivery rate across the whole catalogue is useless — it blends failing and working routes into one figure. Slice the statistics along at least three axes:

  • By country — the delivery rate of the same service varies several times over between countries: each has its own network load and carriers.
  • By service type — a messenger, a social network, a payment service and a marketplace run filters of very different strictness, so a number's delivery rate does not carry over between them.
  • By time of day — delivery drops during peak load on the carrier's network and overnight in the number's local time.

Without these breakdowns, one bad hour or one problem country quietly drags down the average for the whole route, and the decision to disable it ends up made on the wrong data.

When it is time to disable a route

A low figure means nothing on its own without comparing it to that route's own history. The signal to disable is a sustained drop against its own average over previous weeks, not a single bad spell: temporary dips happen from carrier congestion and usually recover on their own.

Check not only the share of successful codes but also the real cost from the formula above: a route can hold a steady 30% and still cost more than an alternative at 70%, if the price gap is not big enough to offset the delivery gap. For weighing a cheap route against a reliable one when the account itself also needs to be kept afterward, see the article on backing up account access.

Where to check the operation history

The decision is made on numbers for a period, not on a feeling that "something has not been arriving lately." The full history of requests, statuses and prices is stored in the operation history section and visible in the dashboard — letting you calculate delivery rates by your own breakdowns instead of relying on averaged catalogue figures.

Frequently Asked Questions

How do I calculate the share of successful verifications if some attempts are not finished yet?

Use a closed period — say, yesterday or the day before, where every attempt already has a final status. Unfinished requests distort the denominator of the formula in both directions.

Can delivery rates of different routes be compared directly?

Yes, but only for the same period and the same breakdown — country, service and hour. Comparing one route's monthly average with another route's figure for today does not show a quality difference, it shows a sampling difference.

What should I do if a cheap route suddenly loses its delivery rate?

First recalculate the real cost from fresh numbers, not from the attempt price. If the formula shows the cost of a successful code rising above an acceptable threshold, switch temporarily to a route priced higher on the list but with a higher delivery rate, and go back to the cheap one once the numbers recover.

Calculating delivery rates and the real cost of a successful verification per route is easy using the operation history in turbon.rent OTP activations — switching between routes needs no manual price recalculation.