Read receipts are one of the clearest practical differences between RCS and SMS. Plain SMS gives you, at best, a carrier delivery report saying the message reached a device. It cannot tell you whether anyone looked at it. RCS separates the two states, so you can see that a message was delivered at 9:02 and read at 9:14, and treat those as the different facts they are.
Delivered and read are two separate events
On RCS you normally receive both, in order. DELIVERED fires when the message reaches the recipient's device. READ fires when they open the conversation containing it. The gap between the two is genuinely useful: a large delivered-to-read gap on a time-sensitive alert usually means the send time is wrong rather than the copy.
There is a third signal in the same family, IS_TYPING, which fires while the recipient is composing a reply to your agent. Together these are what make an RCS thread feel like a conversation rather than a broadcast, and they are covered alongside the rest of the webhook payloads in RCS event types.
What a business actually sees
A read receipt is a status update on a message you sent, not a window into the person. You learn that the message you sent to a given number was opened, and when. You do not learn what else is in their inbox, who else messages them, or anything about them beyond the number you already had permission to message.
That distinction matters when you are writing your privacy notice. The receipt is generated by the recipient's messaging app about your message, in much the way an email open reports on your email. It is engagement data about a message, and it should be described that way.
When a read receipt never arrives
Several ordinary situations produce no READ event at all, and none of them mean the message failed:
- The recipient has read receipts switched off. Both Google Messages and the iPhone Messages app let people disable them, and a good number of people do.
- The message fell back to SMS or MMS because the recipient could not receive RCS. SMS has no read receipt to send. See how RCS falls back to SMS.
- The message was delivered but the thread was never opened, which is a real result and worth measuring.
- The recipient read the message from the notification shade without opening the thread, which on some devices does not trigger the receipt.
The operational rule that follows: treat read rate as a directional engagement metric, never as a delivery guarantee or a compliance record. If you need to show that a notice was received, delivery status plus your own audit log is the defensible artefact, not a read receipt.
How read data should change what you send
Because read receipts are per recipient and timestamped, they make a handful of decisions measurable that on SMS were guesswork. Send-time testing becomes real: you can compare median time-to-read across two send windows rather than inferring it from click lag. Sequence design becomes real too, because you can hold a follow-up until the first message has been read, or send a different follow-up when it has not.
They also make it obvious when a programme is over-sending. A read rate that falls steadily across a campaign while delivery stays flat is the clearest early warning of message fatigue you will get, and it tends to show up well before the opt-outs do.
- RCS distinguishes DELIVERED, meaning the message reached the device, from READ, meaning the thread was opened. SMS reports only the former.
- Read receipts arrive asynchronously on your webhook, not in the API response to the send.
- Recipients can disable read receipts, so a missing READ event is not a failure and read rate is always an undercount.
- Messages that fall back to SMS or MMS produce no read receipt, because the older channels have no such signal.
- SimplyRCS reports delivered, read, and suggestion-tap events for every send, through the app and the API alike.