Everything worth knowing, nothing that isn't.
Is OTP delivery rate the same as conversion rate?
No. A delivery receipt tells you the operator handed the SMS to the handset; it does not tell you that the user read it or typed the code. Track the verification rate separately: codes entered correctly divided by codes requested. A high delivery rate next to a low verification rate points at the user journey (codes that expire too soon, a resend button that appears too late, a code that arrives after the user gave up), not at the route. See /answers/what-is-dlr.
How do you measure OTP delivery rate?
Count final operator receipts only: delivered divided by submitted, per country and per operator, over a rolling window. Leave messages that are still pending out of the calculation, and count expired, rejected and undeliverable receipts as failures. The submit response from the API or SMSC is not a delivery: it only means the message entered the network. Measure latency from submit to the delivered receipt at the same time, because a code that arrives after it expires is delivered but useless. See /answers/what-is-message-status.
How does BroadNet report OTP delivery rate?
Every message sent through BroadNet returns a message ID and a delivery receipt: by webhook on the REST API, or as deliver_sm on an SMPP bind. That lets you compute the rate per country and operator from your own traffic. Each /coverage country page gives the typical operator-direct delivery rate for that market; for /coverage/uae it is 99.6%. These are per-market figures, not a global average; your own receipts give the rate for your traffic.
What lowers OTP delivery rate?
Invalid or ported numbers, unregistered sender IDs, grey routes that operator firewalls block, and message content that trips spam filters. HLR lookups before sending, registered sender IDs, direct operator routes and a fallback channel address the main causes. The OTP delivery optimization checklist covers each control: see /guides/otp-delivery-optimization-checklist.