​

SMS click-through

​

Where to reach it

• Insights → SMS click-throughs — the full panel: group-by control, window control, totals strip, and the bucket table described below.
• Messages → SMS messages — a compact summary embedded at the bottom of the SMS workspace. It shows the last 7 days as four figures — clicks, verified clicks, tracked links, and average clicks per link — with a day-by-day sparkline, plus a link through to Insights → Links for the per-link drill-down. The window is fixed at 7 days; use the Insights surface when you need a 24-hour or 30-day cut or per-bucket rows.

​

What the panel reads

• Sends — outbound SMS in the window, whether or not they carried a tracked link.
• Tracked — sends that carried at least one tracked short link.
• Clicked — sends whose tracked links recorded at least one click.
• Clicks — raw clicks across the bucket’s links, including bot and link-preview traffic.
• Verified — clicks that passed the bot/link-preview filter.
• CTR — clicked sends divided by tracked sends. A bucket with no tracked sends shows —, not a misleading zero.
• Verified CTR — verified clicks divided by tracked sends. Use this when comparing against email’s bot-filtered Clicked metric.

​

Two clicks, two rates — link-shortener vs short-link CTR

​

Denominator — engaged recipients, not delivered

• CTR — sends that recorded at least one click ÷ tracked sends. The raw rate; includes every click that landed, bot or human.
• Verified CTR — filtered (human-quality) clicks ÷ tracked sends. The cross-channel parity rate — the email Clicked metric is bot-filtered, so compare SMS against email on Verified CTR never on raw.
• Per-link open-event CTR — clicks per link ÷ tracked links on Insights → Links. This is a link-level rate, not the campaign click rate; the two surfaces are deliberately kept separate so campaign rollups and link drill-down agree bucket-for-bucket.

​

How the panel scopes

• Group by: Campaign / Queue — the segmentation axis. Campaign buckets on the campaign_id stamped at send time (per campaign); Queue buckets on the messaging-service id recorded at send time, falling back to the provider tag when no queue resolves (per audience lane) — the same precedence the API’s group parameter uses. Per-link segmentation lives on Insights → Links; this control defines what a “bucket” is for every row on the panel.
• Window: 24h / 7d / 30d — a trailing window, aligned to “now” at the render instant, for every number on the panel. Time windowing is not a rolling-n-calendar-days cut; 24h rolls back exactly 24 hours, 7d and 30d the same in days. The totals strip always covers every bucket in the window (not just the page you’re viewing), and a shorter window is not a sub-sample of a longer one — it is a fresh rollup over a narrower span.

​

Pagination, sort, and empty states

• Loading — skeleton placeholders for the totals cards and table rows.
• No traffic — a “No tracked click-throughs yet” empty state with a link through to the Link tracking page. It appears when the window contains no sends (or none rendered any rows) — a new sender’s normal starting point, not an error.
• Load failure — a retryable error lane (“Couldn’t load the SMS click-through report”) with a retry button.

​

Reading the unattributed bucket

1. metadata.shorten_urls on the send payload — explicit per-send opt-in; rewrites every http(s):// URL in the body into a tracked link and stamps your campaign_id onto it.
2. SMS auto-shorten (tenant channel setting, default ON) — rewrites URLs longer than 30 characters, but only when the minted short URL is strictly shorter than the original.
3. WhatsApp auto-track (tenant channel setting, default ON) — the WhatsApp counterpart, which also mints for scheme-less www. spans.

​

Verified clicks and bot filtering

​

Why a spike can be scanner traffic

• Send fewer un-minted URLs — plain-text SMS sends where a raw http(s):// URL never got minted to a short link contribute to Sends but nothing downstream, so scanner traffic only scales when you shorten more of what you send (auto-shorten and per-send metadata.shorten_urls are the two opt-in routes).
• Front the link with a recipient-only tap — the verified predicate drops clicks with no user-agent; a scanner that doesn’t present a UA re-scores as verified as soon as a real tap arrives. The dashboard page’s Verified column is the mitigation read-out — rely on Verified CTR wherever you compare against the email channel.
• Quarantine raw spikes — when raw and verified diverge per bucket, quarantine the spike onto the unattributed bucket first; a compounding-verified-only spike signals scanner follow-through, not audience engagement. For the scoring rules themselves (what counts as a known bot, the 0.5 threshold), see short links and click tracking.

​

Troubleshooting

​

Defensive misreads

• Email parity — read Verified CTR, not CTR. The email channel’s Clicked metric is bot-filtered. Lining it up against raw CTR mixes a filtered number with an unfiltered one and always flatters email. For cross-channel comparison use Verified CTR, which applies the same quality bar: a click crosses the verified line only when its quality score reaches the 0.5 threshold — a user-agent is present and the click does not match a known bot or preview-fetch signature.
• — is informative, not missing data. A bucket with no tracked sends renders — for both CTR columns, and the API returns null for the rate fields. A fabricated zero would tell you the campaign performed badly when in fact it was never measurable — the dash is the honest value.
• Totals cover the whole window, not the visible page. The totals strip aggregates every bucket in the selected window even when the table paginates, so the totals won’t match a manual sum of the 25 rows on screen.
• The totals won’t foot to the per-link drill-down when untracked volume is large. Raw and verified counts only cover sends that carried tracked links. Sends whose URL never minted into a short link (30-character threshold, or a mint failure that shipped the original URL) contribute to Sends but nothing downstream — close the untracked share before reconciling against per-link analytics.
• Verified counts can rise without new clicks. The bot filter lives at the read layer, so when the known-bot catalogue expands, previously raw clicks re-score as verified on already-collected data. A week-over-week rise in Verified that raw doesn’t confirm is usually a filter update, not a traffic change.

​

API parity — how to read the metric

curl "https://api.orbit.devotel.io/api/v1/analytics/sms-click-through?group=campaign&window=24h" \
  -H "X-API-Key: dv_test_sk_YOUR_KEY"

curl "https://api.orbit.devotel.io/api/v1/analytics/sms-click-through?group=queue&window=7d&page=2" \
  -H "X-API-Key: dv_test_sk_YOUR_KEY"

{
  "data": {
    "channel": "sms",
    "group": "campaign",
    "window": "24h",
    "rows": [
      {
        "bucketKey": "cmp_summer26",
        "bucketLabel": "Summer 26 launch",
        "sends": 1204,
        "tracked_sends": 980,
        "sends_with_clicks": 211,
        "total_clicks": 237,
        "unique_clickers": 189,
        "verified_clicks": 196,
        "click_rate": 0.215,
        "verified_click_rate": 0.2
      }
    ],
    "pagination": { "page": 1, "pageSize": 25, "total": 41, "totalPages": 2 },
    "totals": {
      "buckets": 41,
      "sends": 9402,
      "tracked_sends": 8101,
      "sends_with_clicks": 1633,
      "total_clicks": 1804,
      "unique_clickers": 1511,
      "verified_clicks": 1542,
      "click_rate": 0.201,
      "verified_click_rate": 0.19
    }
  },
  "meta": { "request_id": "req_01J4Z…", "timestamp": "2026-09-29T12:00:00Z" }
}

​

See also

• SMS click-through rollup walkthrough — the operator guide for this page’s tiles, controls, and misreads
• SMS click-through parity guide — reconciliation math, untracked volume, and email-parity reading
• Short links and click tracking — how links get minted, scored, and attributed
• SMS click-through API reference — the endpoint behind the panel