URL shortener for newsletters — track what readers click

A URL shortener for newsletters earns its place the day you switch email platforms and realise that every click number you reported for the last three years lives inside the tool you're about to leave. Substack click data stays in Substack. Beehiiv click data stays in Beehiiv. Mailchimp's wrap dies the moment your billing lapses. The links themselves keep working — recipients clicked them last week and will click them again from the archive next month — but the analytics tied to those clicks evaporate. A branded shortener on a domain you own keeps that data on your side of the fence regardless of which email tool is shipping the campaign.

This post is about how to do newsletter link tracking on terms that survive a platform change, how to read the click-through-rate numbers your reports actually show you (and which ones are theatre), how to handle UTM tags so the data lands cleanly in your destination analytics, and the live trade-offs between leaning on Substack/Beehiiv/Mailchimp's built-in click tracking versus running your own shortener alongside it. Plus a CTR calculator you can paste your own numbers into to see where your newsletter sits against the industry baseline.

The headline: in newsletters, the click is the only honest engagement signal you have left. Owning how you count it is worth more than any single platform feature.

How newsletter platforms already track clicks (and what they hide)#

Every modern newsletter tool ships with click tracking baked in. The mechanic is the same across platforms with small variations: when you write https://yourbrand.com/spring in the email body, the platform rewrites it on send to something like email.substack.com/api/v1/free/x/abc123 (or link.mailchimp.com/click/..., or track.beehiiv.com/...) so the click lands on the platform's redirector first, gets logged, then forwards the reader to your real URL.

The data this captures: which recipient clicked which link, when, how many times, and on what device class. Most platforms expose a per-link click count and a per-recipient click history in the dashboard. Some let you export. Some don't.

What the platform's built-in tracking hides — or at least understates — is that the click number you're staring at is not portable. When Substack writers move to Ghost or Beehiiv, the click history doesn't follow. When a Mailchimp account goes inactive, the wraps eventually 404 and the analytics view is gone. The 2024 episode of a major shortener pivoting away from its free tier broke links in the wild within two weeks of notice; the numbers attached to those links vanished even faster. The platform tracks clicks because it's useful to them and to you, but you don't own the dataset.

Run a shortener on your own domain in parallel — and the click data lives where you can take it with you.

Where Substack and Beehiiv wrap your links by default#

Substack rewrites every URL in the email body through email.substack.com/api/v1/free/x/... (or the paid equivalent) before sending. The reader sees the original URL when they hover in some clients, the wrap in others. The hop is invisible to most readers — they click, they land, the analytics tab in your Substack dashboard increments — but the wrap is mandatory. There's no public toggle to disable it.

Beehiiv does the same thing through track.beehiiv.com (or your custom subdomain when you're on the higher tiers). Beehiiv at least lets you bring a custom tracking domain so the wrap looks like links.yourbrand.com rather than the platform's host. That helps with deliverability and trust, but the data still lives in Beehiiv's database.

Mailchimp wraps via *.list-manage.com and a per-account redirector. Their dashboard distinguishes "total clicks" from "unique clicks" but rolls everything up by campaign — exporting per-recipient detail requires the higher tiers or an API integration.

ConvertKit (now Kit) uses tracking.convertkit.com and offers an off-switch in account settings — you can disable click tracking entirely if you want clean URLs in the email at the cost of losing the per-link numbers.

Ghost takes the most hands-off approach: clicks are tracked on a per-subscriber basis through mail.ghost.org redirects only if you enable it; the default for self-hosted Ghost is off.

A branded short link inside any of these emails gets wrapped twice on send — once by you (go.yourbrand.com/spring), once by the platform (substack.com/.../go.yourbrand.com/spring). The reader's tap travels through both, both log the hit, and your destination receives the visit with UTM parameters intact if you set them. Two redirects feel slow on paper; in practice the perceived delay is under 200 milliseconds and most readers never notice the extra hop. This is the same double-wrap pattern we covered in tracking links in email — what you can know vs what you should, where the privacy line gets drawn around what the wraps capture.

What "good" looks like — the newsletter CTR baseline#

The single most-asked question I see in newsletter circles: "is my click-through rate any good?" Mailchimp's annual benchmark report and Campaign Monitor's 2024 industry numbers both publish averages — the consolidated picture, with the caveats up front:

• All-industry average newsletter CTR sits between 2.0% and 3.0% of delivered emails for broad consumer audiences.
• Niche B2B and creator newsletters with engaged lists frequently run 4–8%, sometimes higher when the audience self-selected hard (a paid newsletter audience, a developer mailing list, a tight founder community).
• Click-to-open rate (CTOR) — clicks divided by opens — runs 10-15% on average, with strong newsletters in the 20-30% range. CTOR is the more honest number now that Apple Mail Privacy Protection has destroyed open-rate reliability.

The trap most operators fall into: comparing their CTR to a "good" number from a blog post written by a vendor who serves enterprise marketers. Their list is 50,000 cold consumers; yours is 800 hand-built subscribers who paid attention to your last six emails. The 2.62% benchmark is calibrated against the first audience. A subscriber-self-selected audience running 5%+ is normal and a 2% number on the same list would be a red flag.

The harder question — and the one a shortener answers cleanly — is "which links do they actually click?" CTR is the headline; per-link click distribution is where the editorial signal lives.

Per-link tracking — why it changes how you write#

Open the dashboard for any week-old newsletter that contains six links. The CTR number gives you one data point: did this email earn attention. The per-link breakdown gives you six. One link took 70% of all clicks. One took 25%. The remaining four split a single-digit percentage between them.

That distribution tells you something the CTR alone doesn't:

• The top link wasn't your headline link. It was the throwaway "I'm experimenting with this tool" mention three-quarters of the way down. Your readers don't read in the order you wrote — they skim, and the line they paused on isn't the one you led with.
• A "lead story" with zero clicks isn't a lead story. It's a headline that landed and prose that didn't.
• The footer link to your About page got 18% of the clicks because new subscribers are using your newsletter as a re-introduction to who you are. That's a content-strategy signal worth more than another A/B test on subject lines.

Substack's per-link view rounds to whole percentages and doesn't expose recipient-level detail without an API call. Beehiiv exposes per-link click counts cleanly. Mailchimp surfaces it on the higher tiers. A branded shortener exposes it on every link, on every plan, with the data joined to your UTM tags so you can roll up across campaigns. The reason this matters: editorial decisions get better when the feedback loop is fast and granular. A list that's been getting weak CTRs for a quarter probably has one or two specific link types that nobody clicks — kill those, and the headline number climbs without any subject-line tweaking.

UTM hygiene for newsletters#

Most newsletter platforms append no UTM parameters by default. Your link goes out as written. If you want destination-side attribution — the kind that shows up in Google Analytics or Plausible as "this visit came from your newsletter" — you have to add the UTMs yourself.

The minimum useful tag set for a newsletter link:

• utm_source=newsletter (or the specific newsletter name if you run more than one — utm_source=monday-edition).
• utm_medium=email.
• utm_campaign=2026-05-27 (the send date, or a campaign slug — pick one convention and never break it).

Optional but useful for editorial analysis:

• utm_content=lead-story or utm_content=footer-cta — distinguishes which placement inside the same email earned the click.

The mistake most writers make: applying UTMs by hand to each link inside the email composer. By month three you've written utm_source=email, utm_source=newsletter, utm_source=Newsletter, and utm_source=email-newsletter — your analytics now treats all four as different sources. The fix is to set the UTM template at the shortener level — every link generated under a campaign gets the same tag set automatically, no manual entry, no typos. For the in-between case — tagging a single send by hand because you haven't templated the campaign yet — the UTM link builder lowercases and hyphenates the values as you type, which is most of where the inconsistency creeps in. The UTM parameters guide for short links walks through the naming conventions in detail; the newsletter-specific point is that utm_source and utm_campaign are the two fields that earn their keep — the others are optional.

A subtle gotcha: when the platform wraps your already-UTM-tagged URL, some platforms preserve the query string through the redirect (Substack, Beehiiv, ConvertKit, Ghost), and a few drop or mangle it (older Mailchimp templates, some legacy ESPs). Test by sending yourself a copy of the campaign, clicking the link, and inspecting the URL bar after the destination loads. If your UTMs survived the round trip, you're fine. If they got stripped, the diagnostic and the eight ways clicks can vanish are covered in the short link not tracking clicks debug guide.

Outlook, Defender for Office, and the phantom click#

Corporate Outlook recipients are the noisy half of every newsletter list. Microsoft Defender for Office 365 — the security layer most enterprise email runs through — does two things to your links that show up as data corruption:

Safe Links URL rewriting. Every URL in inbound mail gets wrapped through safelinks.protection.outlook.com so the destination can be scanned at click-time. The wrap is transparent to the reader; the destination receives the visit normally. It does nothing to your numbers per se — except when combined with the second behaviour.

Link pre-scanning. Defender pre-fetches a percentage of URLs to check for malware. These pre-fetches arrive at your redirect within seconds of the email landing in the inbox, from Microsoft IP ranges, before any human has opened the message. Every short-link platform has to filter these out; most do it reasonably well by recognising the user agents and IP blocks Microsoft uses. But the filtering is imperfect. Expect a baseline of inflation on lists with a heavy enterprise component — sometimes 5%, sometimes 25% — that has nothing to do with your content.

The practical move: read your dashboard's per-link click count alongside the timing distribution. Real human clicks on a 9am-Tuesday newsletter arrive as a long tail over hours and days — early spikes within the first three minutes are mostly Apple Mail prefetch and corporate scanners. If your platform offers a "first-5-seconds" filter or a "datacentre IP exclude," turn it on. If it doesn't, mentally subtract 10-15% from your headline CTR on lists with enterprise Outlook recipients before drawing editorial conclusions.

Live CTR calculator#

The defaults are calibrated to a small but engaged list — 1,200 delivered, 480 tracked opens, 36 unique clicks (3% CTR, 7.5% CTOR). Plug in your actual numbers from your last send. CTR under 1% is a list-quality problem more often than a content problem; CTR over 8% on a tiny send is usually a sample-size mirage. CTOR is the most diagnostic single number you have, but only if you trust your open count — and post-2021 Apple Mail Privacy Protection, open counts on iCloud-routed lists are mostly noise.

The honest trade-off — built-in tracking vs your own shortener#

This is the call most newsletter operators put off because both options look adequate at first glance. They're not equivalent, but the differences are specific.

Stick with the platform's built-in tracking when: your newsletter is a side project on a free tier, your audience is under 500 subscribers, you don't plan to migrate platforms in the next two years, and you don't need cross-channel campaign attribution (you only send via newsletter, no social/SMS overlap). The built-in tools work, the data is enough, and adding a shortener is friction that doesn't pay back at this scale.

Run your own shortener in parallel when: your newsletter is a real channel for the business, you're paying for the platform anyway, you've moved tools before or expect to, you need to join newsletter clicks to social/SMS/print campaign data in one analytics view, or you've ever wished you could pull a six-month per-link history without a platform-specific export. The branded shortener on a domain you own is the only piece of the stack that survives every platform switch.

A pattern that works for most growing newsletters: use the platform's built-in click tracking for the audience-segmentation features (Substack's notifications, Beehiiv's automations, Mailchimp's behaviour-triggered sends) and run your shortener as the source-of-truth layer for analytics that have to survive a migration. The data overlap is fine — a click that fires both counters is still one click. The only number you should treat as canonical is the one on your own domain.

What a newsletter-grade shortener actually needs#

The feature checklist is shorter than vendors make it look:

• Custom domain support with auto-TLS — the link reads links.yourbrand.com/spring, not a generic shortener path. The CTR lift from a recognisable domain is documented in branded short links — why your domain beats bit.ly, and the full setup walkthrough is in setting up a custom short-link domain.
• UTM templates at the link level — set once, applied automatically to every link in a campaign. No hand-typing.
• Per-link analytics on every plan — don't pay extra to see which link earned the click. The basic analytics tab should expose timestamp, country, device class, and referrer without any upsell prompt.
• Bot and pre-fetch filtering, auditable — Microsoft Defender and Apple Mail prefetch hits should be filtered, but the filter rules should be visible to you and the raw event log should be one click away when something looks off.
• Bulk import and export as CSV — the migration optionality you bought the domain for is only real if you can move 800 slugs at once.
• A redirect that runs in under 50ms — newsletter readers tap from mobile on cell data; a slow shortener feels broken even if it works.
• A pricing model that doesn't punish your engagement — per-click pricing scales adversely; flat or per-link models scale neutrally. The pricing page lays out the lifetime-tier math.

Vanity slugs are a quiet upgrade most operators skip. links.yourbrand.com/spring-issue-12 reads as part of the newsletter; links.yourbrand.com/aB7xK2 reads as marketing. The recall multiplier on memorable slugs is covered in the vanity short URL naming guide — for newsletters specifically, the slug is rarely seen by the reader unless they hover, but it shows up in the platform's analytics dashboard and in any cross-channel report. A readable slug makes those reports legible six months later.

A note on RSS-to-email and digest newsletters#

If your newsletter is auto-generated from RSS — every Substack publication that bundles posts into a weekly digest, every podcast that emails new episodes — your URLs get wrapped twice by default: once when your CMS publishes the link, once when the newsletter platform wraps it. The shortener doesn't change this; it just adds a third wrap.

Two practical adjustments for digest formats:

• Set UTMs at the CMS level so the URL has campaign tags before the newsletter platform sees it. Don't try to add UTMs inside the newsletter template — most RSS-to-email pipelines strip template variables anyway.
• Use one shortener slug per post rather than the raw CMS URL, so per-link analytics aggregate across every channel the post got shared on. The newsletter click, the social share, and the podcast show notes all hit the same slug — you read the rollup, not five disjoint partial views. The same rollup is what makes cross-promoting your newsletter onto a live Twitch overlay worth the design effort — the QR scans, the email click, and the social share all converge on one number you can actually read across channels.

This is the same pattern the conversion tracking with QR codes and short links post argues for on the offline side: one slug, many channels, one rollup view of where the audience actually came from.

Compliance and the unsubscribe footer#

Two regulatory rules that touch newsletter links specifically:

CAN-SPAM (US federal) and CASL (Canada) both require a working unsubscribe mechanism in every commercial email. Most platforms include this in the footer automatically. If you're shortening every link in the body, do not shorten the unsubscribe link — the unsubscribe URL must be honoured for at least 30 days after the recipient receives the email under CAN-SPAM, and a shortened link sitting on your domain creates an unnecessary dependency on your platform staying up. Use the platform's native unsubscribe handler.

GDPR and ePrivacy (EU/UK) treat the click record as personal data when it can be tied to an identifiable subscriber. Per-recipient unique slugs cross this line; aggregate counters generally don't. The full privacy framing is in tracking links in email — what you can know vs what you should, but the practical newsletter takeaway is: aggregate click data by campaign and link, do not generate per-recipient unique slugs unless you have explicit consent and a documented purpose.

What we built#

Linked.Codes lets you bring your own domain (or a subdomain on one you already own) for newsletter links, with UTM templates per campaign, auto-TLS, per-link analytics on the same plan as everything else, and CSV export the day you want to leave. The redirect is tuned for the burst-traffic pattern newsletter sends produce — a Tuesday-9am send doesn't queue behind anyone else's. There is a free short-link generator you can use to tag a single link in under a minute, and the full domain walkthrough lives in the custom-domain docs when you're ready to set up the branded redirect.

The point of running your own shortener for newsletters isn't to compete with Substack or Beehiiv's tracking. It's to keep the data that matters on your side of every platform decision you'll make in the next decade.