--- title: "Delivery rate is not a result" summary: "It is the metric most often reported and the least often useful. What delivery actually means, what to measure instead, and how a simple holdout group tells you whether messages changed anything." canonical: https://cpaas.co/en/learn/delivery-rate-is-not-a-result kind: explainer depth: foundation origin: original published: 2026-09-18T16:26:18.899Z updated: 2026-10-14T16:26:19.442Z topics: ["Analytics", "Messaging", "Fundamentals"] language: en --- # Delivery rate is not a result Messaging dashboards lead with **delivery rate**, and it is almost always above 95%. That is not because the programmes are working. It is because delivery rate measures the network, and networks are good. > **Interactive figure — delivery-funnel.** Set delivery at 97% and read the last bar. The two numbers are describing the same campaign. > Available at https://cpaas.co/en/learn/delivery-rate-is-not-a-result ## What "delivered" actually means "Delivered" usually means a **delivery receipt** came back: an operator or messaging app confirmed the message reached the device. It does not mean the person saw it, read it, or did anything. Between delivery and outcome sit at least three drops: the message is not seen; it is seen and ignored; it is read but not acted on. Each stage loses most of what the previous one had. ```diagram:stats # One illustrative send, four numbers 97% | Delivered | An operator or app confirmed it reached the device 62% | Seen | Of those delivered, the share that reached someone's attention 4% | Acted on | Of those seen, the share that did something 2.4% | Outcome per hundred sent | The only figure the business recognises > Illustrative figures, but the shape is typical: every stage loses most of the one before. Report the last number against sent, not against delivered. ``` That is arithmetic, not pessimism — and it is why a 97% delivery rate and a 2% outcome rate routinely describe the same campaign. ## What to measure instead | Metric | What it tells you | Why it matters | |---|---|---| | Outcome per thousand sent | Appointments confirmed, payments made, replies received — per 1,000 sent | The number the business recognises | | Reply rate | Share of recipients who replied (where replies are possible) | Whether it felt like a message rather than a broadcast | | Opt-out rate per send, over time | Share who unsubscribed after each send | Early warning of over-sending; moves before revenue does | | Complaint and block rate | Spam reports and blocks | Low numbers with a rising trend come before a channel is taken away | **Use sent, not delivered, as the denominator.** Dividing by delivered quietly hides your worst failures: the messages that never arrived are exactly the ones that could not succeed. ## Look at the statuses, not the average Delivery rate is an average over statuses, and the average hides the diagnosis. - **Rejected at submission** — your problem: a malformed number, a missing registration, an unapproved template. Easiest to fix, because it fails immediately and loudly. - **Accepted, then failed downstream** — an unreachable or barred number, or an operator that accepted and dropped it. The **cause code** is the whole value here; a provider that returns "failed" without one is hard to debug against. - **Accepted, never resolved** — the message left and nothing came back. Every large programme has some. Track them explicitly rather than letting them round into "delivered". ```diagram:path # Where each status comes from Your system | Submits the message | Rejected at submission: a malformed number, a missing registration, an unapproved template Provider | Accepts it and passes it on | Failed downstream: unreachable, barred, or dropped — the cause code says which Operator or app | Carries it to the device | Never resolved: it left, and nothing came back Device | A delivery receipt returns, and only then is it "delivered" ``` ## The one thing delivery rate is good for Detecting a break. A delivery rate that drops from 97% to 71% overnight is a real signal: a registration lapsed, a template was rejected, a route changed. **Alert on sudden changes, not on the level.** ## SMS segments: why the bill surprises you SMS is billed per **segment**. A single segment holds 160 characters in the basic GSM alphabet, but only 70 when the message contains anything outside it — Arabic, Hindi, Chinese, Cyrillic, Greek, or a single emoji. Longer messages are split into segments of 153 or 67 characters. So the same notice can cost two or three times as much in one language as in another, and one stray character (a curly quote pasted from a word processor, say) can double a message's cost. A variable in a template — a name, an address — means you often do not know the length until sending. Measure cost per *outcome*, not per message, and the problem shrinks to its proper size. ```diagram:compare | Basic GSM alphabet | Anything outside it One message, one segment | Up to 160 characters | Up to 70 characters Each segment of a longer message | 153 characters | 67 characters What tips a message over | Length | Arabic, Hindi, Chinese, Cyrillic, Greek — or a single emoji or curly quote ``` ## Attribution: did the message cause it? The hardest part is not measurement but **attribution**. A customer who received a payment reminder and then paid may have paid anyway. The honest answer is a **holdout group**: a randomly chosen set of people who receive nothing, measured on the same outcome. If 61% of reminded customers pay on time and 55% of the holdout do, the reminder is worth about six points — not 61. ```diagram:bars # What the reminder is actually worth Reminded customers who paid on time | 61% | Received the reminder Holdout who paid on time | 55% | Randomly chosen, received nothing > The difference — about six points — is the reminder's effect. Not 61. ``` To build one that survives scrutiny: - **Randomise per person, and keep them there.** Re-drawing the group for every campaign means everyone eventually receives something, and the control stops being a control. - **Exclude nobody for convenience.** Pulling high-value customers out of the holdout removes exactly the people you most need to measure. - **Keep it small and permanent.** A few per cent is often enough at volume. A holdout that runs only during a test tells you about the test. - **Report the uncertainty.** A 3% lift measured on two hundred people is noise. Saying so is what makes the next report believable. ## What a good report looks like One page: outcome per thousand sent, with the holdout beside it; the funnel underneath; opt-out and complaint rates as a trend; one sentence on what the numbers cannot settle. If it takes more than a page, it is padded with things that move without meaning. ```diagram:checklist # The one-page report Outcome per thousand sent | With the holdout beside it The funnel | Underneath Opt-out and complaint rates | As a trend, not a single figure One sentence on what the numbers cannot settle | The line that makes the next report believable ``` ## What to ask a provider - Do you return a specific cause code for every failure, and can I get statuses by webhook? - How do you report messages that were accepted but never resolved? - Can I see segment counts and cost per message before and after sending? ## Where to go next - [Measuring a conversational programme](/en/learn/measuring-a-conversational-programme) — the deeper level. - [Channels are not interchangeable](/en/learn/channels-are-not-interchangeable) — what silence means on each channel. - [What CPaaS actually is](/en/learn/what-cpaas-actually-is) — accepted, delivered and acted on. --- Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.