Reading the SMS click-through parity panel
The SMS click-throughs surface answers the channel-level question the per-link analytics can’t: “what is the click-through rate on this campaign (or queue)?” Per-link stats under Insights → Links tell you who clicked a given short URL; the parity panel rolls those rows up per campaign or messaging queue so SMS click-through can be compared side by side with the email channel’s Clicked metric. Everything the panel shows is a read-only rollup over the same shorten_urls pipeline that mints tracked short links on send (metadata.shorten_urls or the tenant SMS/WhatsApp auto-shorten settings) — so the panel can never disagree with the per-link drill-down. See the short links guide for how links get minted and tracked, and the SMS click-through API reference for the underlying endpoint.
1. What the panel reports
For each campaign or queue in the window, the panel reports:- Sends — outbound SMS rows 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 verified-click predicate (bot and link-preview scanners filtered out; see the short links guide for how filtering works).
- CTR — clicked sends divided by tracked sends, in the
[0, 1]range. If a bucket has no tracked sends, CTR shows as—rather than a misleading zero. - Verified CTR — verified clicks divided by tracked sends. Use this when comparing against email’s bot-filtered Clicked metric.
2. Where to find it
Open Insights → SMS click-throughs in the dashboard. If you work from the per-link drill-down at Insights → Links, the parity panel is the channel-level counterpart — per-link answers “who clicked this link,” the parity panel answers “how does this campaign compare to email.” In the email channel, the equivalent numbers already exist as the Clicked metric on campaign reports. This panel gives SMS the same granularity: per bucket, a bot-filtered click rate that reconciles across the whole window.3. Reading the panel
Two controls sit at the top of the panel:- Group by — switch between Campaign (bucket per campaign id) and Queue (bucket per messaging queue/provider). Campaign grouping is what you want when comparing a specific send; queue grouping is what you want when one route or sender pool is underperforming across campaigns.
- Time window — 24h, 7d, or 30d. Window and group changes reset pagination to page 1.
unattributed bucket. Sends with no resolvable campaign id (or queue, when grouped by queue) — one-off sends, compose dialog sends, older payloads — aggregate into a single bucket labeled unattributed, shown in place of a bucket name. It is not an error grouping; it is the catch-all for sends that were never stamped with a campaign. If your unattributed share of sends is large, the fix is upstream: stamp campaign_id (or a queue) on the send pipeline so attribution lands correctly.
Null CTR. When a bucket has zero tracked sends, both CTR columns render — (null), not 0.0%. Zero CTR and undefined CTR are different facts and the panel keeps them separate.
Worked example. Grouped by campaign over 7d, a row like this:
Read it as: of 12,400 sends, 12,317 actually carried a trackable short link (83 sends had no link, e.g. recipients that received non-URL bodies), 83 of those sends got clicked at least once, with 117 raw clicks after bots and preview scanners are filtered to 79 verified. CTR is 83 ÷ 12,317 ≈ 0.7%; verified CTR is 79 ÷ 12,317 ≈ 0.6%.
A large raw-to-verified gap (117 → 79 here) usually means aggressive link-preview scanners — common on corporate carriers and security gateways — inflating raw clicks. Trust the verified column when comparing to email’s Clicked metric, which is filtered the same way.
4. Why CTR parity matters
Email reports have had a channel-level Clicked metric for a long time; SMS operators were left to stitch per-link analytics together by hand to answer “how does this campaign click through.” Without a channel-level surface, SMS under-invests or over-invests with no feedback loop: you can’t A/B two templates against each other, you can’t prove a queue migration didn’t hurt engagement, and you can’t compare channels on a common bot-filtered denominator. With parity, the email-vs-SMS comparison becomes apples-to-apples, campaign A/B tests get a real click metric, and an engagement regression after a routing change shows up as a falling verified CTR in the 24h window rather than a week of anecdote.5. API path
The panel is a thin client overGET /api/v1/analytics/sms-click-through, mounted on the analytics router. Query params: group (campaign | queue), window (24h | 7d | 30d), page, pageSize (default 25). The response returns rows, totals, and pagination, keyed under the { data, meta } envelope; roles owner/admin/developer/viewer can all read it, and it’s cached for 60 seconds server-side.
For request and response schemas, see the SMS click-through API reference. For how links get minted and tracked in the first place, see the short links guide.