Traditional SMS reporting ends at the word delivered.
And yet, every team running business messaging is now asked what it returns. Nielsen found that 85% of marketers say they are confident in their ability to measure ROI, while only 32% actually measure it across their channels.
Messaging sits squarely inside that gap, carrying appointment reminders, fraud alerts, order updates, and payment links, and it reports back less than almost anything else in the stack.
The limit is structural. A carrier delivery receipt confirms that a message reached a handset. It says nothing about whether anyone opened it, what they did next, or which version of the message worked better than the one before it.
Measurement is also the part of the channel that gets the least attention up front. Planning usually stops at what RCS for business is and where it fits in a messaging strategy, and never reaches the question of what comes back.
This guide breaks down the metrics RCS delivers, which ones should shape your decisions, and how to run a controlled test that proves lift using your own traffic.
What your SMS reporting actually tells you
Every SMS platform reports delivery, and delivery is a real signal. A carrier confirms that the message reached the handset. What it cannot confirm is that a person looked at it.
Everything past that point has to be reconstructed. Click tracking requires wrapping every URL in a shortened link, which adds a redirect and gives carrier filters another reason to inspect the message. Even when the link survives, a click tells you someone reached a page. It does not tell you which line of the message moved them there.
Replies are the one rich signal SMS returns, and they arrive as free text. Someone has to read them, interpret intent, and decide what happens next. At volume that becomes a staffing question rather than business messaging analytics.
So a channel carrying appointment reminders, payment links, and fraud alerts reports back a single number with a wide margin of interpretation. Teams fill the space around it with survey data, loose correlation against sales, and judgment.
The metrics RCS reports back
RCS analytics arrive in two layers. The first is a set of counts available in the console every sender works from, where Google’s documentation describes three metrics for each agent: sent, delivered, and read, refreshed daily and grouped by the date the message went out. That third metric is the one SMS never had. RCS read receipts let a sender separate messages that arrived from messages that were opened.
The second layer is the event stream underneath the console, and it is where most of the useful detail lives. Every message carries an ID, and every event that follows attaches to it. That is what makes per-message analysis possible instead of per-campaign averages.
Six categories of data come back on a typical send:
- Delivery and read events: Each message reports when it reached the device and when the recipient opened it, both tied back to the original send.
- Time between read and reply: The gap between someone opening a message and answering it shows whether the request was clear enough to act on immediately.
- Button and suggested reply data: Every tappable element carries its own identifier, so a message with four buttons returns four separate counts instead of one aggregate click.
- Response format: The record shows whether someone answered with text, sent a file, or shared a location, which tells you how people prefer to respond.
- Unsubscribe reasons: People who opt out select a reason, and those reasons come back as a breakdown rather than a single opt-out count.
- Spam rate and sender reputation: Reported spam and its trend over recent weeks feed the traffic limits applied to a sender, so the number carries operational weight.
That data exists whether or not anyone uses it. Whether it reaches the people who need it depends on where the channel runs. A messaging layer that adds SMS, MMS, and RCS to the numbers your team already works from keeps the reporting in the same place as the conversations, so nobody exports a file to answer a question about last week’s send.
Which numbers are worth acting on
| Metric | What it tells you | What you change because of it |
|---|---|---|
| Read rate | Whether the message reached attention, separately from whether it reached the device | Send timing, sender name, and the opening line |
| Taps by button | Which specific action people chose when given several | Button labels, button order, and how many options to offer |
| Time from read to reply | Whether the request was clear enough to answer without rereading | Message length and how much context sits above the action |
| Reply volume and format | Whether people are answering the way the message was designed for | Whether the next version needs a button in place of an open question |
| Unsubscribe reasons | The specific complaint driving opt-outs, most often frequency or relevance | Send cadence and list segmentation |
| Spam rate and trend | How recipients are categorizing the sender over time | Content mix, consent capture, and volume pacing |
How to run a test that proves lift
Every metric above describes one program in isolation. Proving that RCS changed an outcome takes a comparison, and the cleanest comparison available is a controlled test against the version already running. Five steps make that test defensible.
Pick one recurring message
Choose something already going out on a schedule: an appointment reminder, a delivery notification, a payment due notice. Recurring traffic supplies volume without waiting for a campaign window, and the current version becomes the baseline.
Hold a control group on the existing version
Keep a portion of the audience on the current SMS message for the full length of the test. Without a holdout the comparison is this month against last month, and every other thing that changed in between gets counted as the result.
Change one variable
Send the RCS version with the same copy, the same timing, and the same audience criteria. If the new version also moves the send window or rewrites the offer, the test cannot say which change did the work.
Define the outcome before the first send
RCS engagement metrics are diagnostics. The result is the business outcome behind them: appointments kept, invoices paid, calls avoided, trucks rolled. Write down which number decides the test before anyone sees data, because the temptation to pick the flattering metric afterward is real.
Account for fallback before you split the audience
Recipients whose devices do not support RCS receive SMS automatically. That is correct behavior for the message and a complication for the test. Segment by device capability, or measure only the eligible cohort, so the RCS group is genuinely receiving RCS.
A test like this runs more cleanly when the campaign was built properly to begin with. The steps that take an RCS campaign from setup to launch cover consent, verification, and fallback design, each of which shapes what the resulting numbers mean. After two or three tests, most teams find the data has also answered a larger question about which messages belong on which channel.
Turning message data into automated action
Read counts and tap counts serve as records. The same events can serve as inputs.
Because a tapped button carries its own identifier, the response arrives as structured data instead of text someone has to interpret. That is what makes routing and automation practical on a messaging channel.
- Routing on response: A tap on reschedule can open a booking flow while a tap on confirm closes the task, with no agent reading either one.
- Triggered follow-up: A message read without a reply after a set interval can prompt a different second message than one that was never opened at all.
- Feeding the record: Engagement events sit alongside the message content, so the retention and archiving policy covering conversations covers the data about them too.
Structured taps let messaging automations that already lift engagement branch on what someone actually chose instead of guessing from keywords, and they give AI-assisted replies a specific input to work from. The same structure sits underneath how RCS and AI work together inside Microsoft Teams, where the button a customer taps becomes the routing decision.
Where the data lands matters as much as what it contains. Teams already sending RCS from the Microsoft Teams numbers their staff work from every day see engagement data in the same inbox as the conversation, which is usually the difference between data that exists and data anyone opens.
Prove what your messaging is worth on your own numbers
Every argument for RCS eventually meets a request for proof. This channel is unusual in that it supplies its own.
Read state, per-element taps, reply timing, and opt-out reasons come back on every send, and a controlled test against the current SMS program turns that data into a number that holds up in a budget conversation.
Momentum Messaging, powered by Clerk Chat, runs that channel as a managed messaging service inside Microsoft Teams, on the numbers your team already uses. Registration, brand verification, fallback design, and reporting sit with one provider, on one bill, with one support team. The reporting arrives where the conversations already are.
See what your messages actually do after they land. Try RCS on your own phone and watch the read and the tap come back.
FAQs
What can RCS analytics measure that SMS cannot?
RCS reports read state, so a sender can tell an opened message from a delivered one. It also reports taps on each individual button or card, the time between a read and a reply, whether the reply came as text or a file, and the specific reason someone unsubscribed. SMS reporting stops at the carrier delivery receipt.
Are RCS read receipts always accurate?
Treat read rate as directional. Recipients can turn read receipts off in their messaging app settings, and read events are only reported back within a limited window after the original send. A read that happens weeks later may never appear in the totals. The metric is useful for comparing versions of a message, less so as an absolute count.
How do I track which button a customer tapped?
Each suggested reply or action carries its own identifier that comes back when a recipient taps it. Tie that identifier to the original message ID and the record shows exactly which option was chosen. A message offering four choices returns four separate counts, which makes it possible to test button wording and ordering directly.
Does SMS fallback change what I can measure?
Yes. When a device cannot receive RCS, the message goes out as SMS and reports back like SMS, with delivery status only. Any comparison between the two channels needs to separate recipients by device capability first. Otherwise the RCS group contains SMS traffic and the results understate what the richer version actually did.
What should I measure first on a new RCS campaign?
Start with one business outcome tied to revenue or workload, such as appointments kept or calls avoided. Read rate and button taps come next as diagnostics that explain why the outcome moved. Measuring engagement first tends to produce reports that look encouraging without answering whether the program was worth running.
Does tracking RCS engagement create privacy or compliance concerns?
The same rules that govern business texting apply. Capture consent, honor opt-outs promptly, and retain engagement data under the policy covering the messages themselves. On security, business RCS trust rests on verified sender identity and carrier verification. The cross-platform end-to-end encryption now rolling out covers personal one-to-one chats, not brand-to-customer messaging.
