How to Build an SMS Analytics Dashboard: Metrics, DLR Codes & Benchmarks

Why "Messages Sent" Is a Useless Number

Most SMS panels proudly show how many messages you submitted. That number tells you almost nothing. In India, a submitted message can be scrubbed by the DLT platform, blocked by DND preferences, expire in an operator queue, or land on a switched-off handset. The gap between submitted and delivered is where your money disappears, and an analytics dashboard exists to make that gap visible, explainable and fixable.

This guide covers the metrics worth tracking, the delivery report (DLR) codes behind them, a practical data pipeline, and the India-specific failure patterns you should build reports around.

The Metrics That Actually Matter

Note that SMS has no native "open rate" — anyone showing you one is estimating. Clicks on tracked links and OTP verifications are your real engagement signals.

Understand DLR Status Codes First

Every metric above is derived from delivery reports. The standard SMPP-style statuses you will aggregate:

• DELIVRD: handset confirmed receipt — the only status that counts as success
• UNDELIV: operator could not deliver (invalid number, ported number issues, handset errors)
• EXPIRED: message sat in the operator retry queue (typically up to 24–48 hours) and timed out — common for switched-off phones and weak coverage areas
• REJECTD: refused before delivery — in India this is very often DLT scrubbing: template mismatch, unregistered header, or content variables exceeding the approved format
• DND-blocked: promotional message to a number on the Do Not Disturb registry

A dashboard that only shows delivered vs failed hides the difference between "bad phone number" (a data quality problem) and "template mismatch" (a compliance problem you can fix today).

Slice Everything by Operator

India's subscriber base is split across four networks — roughly 46–47 crore on Jio, 38–39 crore on Airtel, about 21 crore on Vi and under 10 crore on BSNL as of 2025. Each operator has its own DLT platform, retry behaviour and congestion patterns. An operator-wise delivery report catches problems a blended average hides: if overall delivery drops from 96% to 91%, the operator split will usually show one network at 78% while the others are fine, which tells you exactly where to escalate. Track delivery rate, average latency and failure reasons per operator, per day.

Building the Pipeline

Step 1: Capture DLR Webhooks

Configure your gateway to push delivery callbacks to your server the moment status changes. A typical callback carries the message ID, destination number, status, error code, operator/circle and timestamps. Our developer API delivers these as HTTP callbacks you can point at any endpoint.

Step 2: Store Raw Events

Keep one row per message with columns like: message_id, campaign_id, msisdn (masked), template_id, operator, circle, submitted_at, delivered_at, status, error_code, cost. MySQL handles tens of millions of rows fine with indexes on campaign_id and submitted_at; beyond that, ClickHouse or a partitioned table keeps queries fast.

Step 3: Aggregate Hourly

Pre-compute an hourly summary table (per campaign, per operator, per template) so the dashboard never scans raw events. Delivery rate, latency percentiles (p50 and p95, not just averages), and failure counts by error code are all cheap to roll up.

Step 4: Visualise

You do not need to build charts from scratch. Grafana or Metabase pointed at your summary tables gives you time-series and breakdown charts in an afternoon; Chart.js works well if you want the dashboard embedded in your own admin panel. Whatever tool you use, the front page should answer three questions at a glance: is delivery healthy right now, is latency normal, and did anything fail in bulk in the last hour.

Step 5: Alert on Deviations

• Delivery rate drops more than 5 percentage points below the 7-day average
• OTP p95 latency crosses 30 seconds
• Any single error code exceeds 2% of traffic in an hour (catches DLT template breakage immediately)
• Spend per hour exceeds a campaign budget cap

India-Specific Reports Worth Adding

• DLT rejection report: failures grouped by template ID. One wrongly edited variable can silently kill an entire template's traffic.
• Promotional window compliance: TRAI expects promotional SMS between roughly 10:00 and 21:00; a chart of send times catches scheduler bugs before they become complaints.
• DND hit rate: a rising DND-block percentage means your promotional list needs scrubbing against consent records.
• Circle-wise latency: delivery in metro circles is usually fast; recurring delays in specific circles (common during festival-season congestion around Diwali and New Year) justify route changes.

Frequently Asked Questions

What is a good SMS delivery rate in India?

For transactional and OTP traffic on a clean route, 95–98% delivered is normal; the remainder is mostly switched-off handsets and invalid numbers. Promotional campaigns run lower, typically 88–93%, because of DND blocks and older list data. Anything under 85% points to a routing, DLT or data-quality problem.

Why does a message show DELIVRD but the customer says they never got it?

DELIVRD means the handset acknowledged receipt to the network. The usual culprits after that are the phone's spam filter (common on devices with aggressive inbox categorisation), dual-SIM phones receiving on the other number, or the user checking the wrong messaging app. Checking the exact destination number in your raw event log resolves most of these disputes.

How do I track clicks and conversions from SMS?

Use a unique short link per campaign (or per recipient for precise attribution) that redirects through your own domain, logging the click before forwarding. Pair click data with UTM parameters so sales and sign-ups show up in your web analytics attributed to the SMS campaign, then feed conversion counts back into the dashboard next to cost per delivered message.