RCS (Rich Communication Services) business messaging has moved from a carrier curiosity to a mainstream channel through 2026, now that both Android and iOS support it and most major carriers have finished their rollout. Compared to plain SMS, RCS gives a sender rich cards, carousels, suggested replies, typing indicators, and genuine read receipts — a level of interaction visibility SMS never had. For teams migrating a messaging programme across, that richness is also the trap: it’s easy to keep tracking exactly what was tracked on SMS — delivered, opened — and never wire up the layer of data that actually explains why a campaign worked, which is which specific card, button, or suggested reply someone tapped.
Without element-level interaction tracking, an RCS campaign’s headline numbers look impressive and say almost nothing useful. A “72% open rate” or a “10x engagement lift over SMS” figure is real, but it doesn’t tell a team whether the lift came from the hero image, the price shown on a carousel card, or a suggested reply that made responding effortless. Teams that only migrate their delivery/read tracking end up unable to answer the one question that actually matters for the next campaign: what part of the message drove the result, and what should get built into the next one.
Data Points to Track
- Per-element interaction events — which specific carousel card, button, or suggested reply was tapped — mapped to a unique ID assigned at message-build time, not just logged against the overall campaign
- Time-to-first-interaction after delivery, to separate messages that get acted on immediately from ones that sit read but ignored
- Read-receipt-to-click conversion rate, isolating how often a confirmed read actually turns into an interaction rather than assuming the two move together
- SMS fallback rate, tracked as its own event distinct from RCS delivery failure, since a device or carrier without RCS support is a different problem than a message that failed to send
- Suggested-reply usage versus manual free-text reply, to see whether structured response options are actually being used or just displayed
Setup Steps
- Confirm your RCS aggregator or platform sends per-element interaction webhooks, not just delivered/read status — most support it, but it’s frequently off by default and needs an explicit request to enable.
- Assign a unique trackable ID to every rich card element at message-build time — each button, carousel item, and suggested reply — rather than only tagging the message as a whole.
- Log SMS fallback events separately from outright RCS delivery failures, so a shrinking addressable RCS audience doesn’t get mistaken for a delivery-reliability problem.
- Route RCS interaction events into the same funnel and attribution pipeline used for other channels, so downstream conversions can be traced back to the specific element that drove them instead of sitting siloed in a messaging-platform dashboard.
- Run an early SMS-equivalent baseline campaign to confirm RCS’s richer format is genuinely lifting conversion for your audience, rather than assuming it from delivery and open metrics alone.
Actionable Insights
A high read-receipt rate paired with a low per-element click rate points to a creative problem — the message is landing but the content or call-to-action isn’t compelling enough to act on. A rising SMS fallback rate is a reach problem: your addressable RCS audience is smaller than assumed, and any budget planned around full RCS coverage needs revisiting. And if suggested-reply usage consistently outpaces manual free-text replies, that’s a clear signal to simplify future flows around structured, tappable responses rather than open-ended text.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert