Every link a publisher puts in front of a reader is a data point. The newsletter click that drove a paid subscription. The syndicated article that generated 40 000 readers from Apple News but zero conversions. The freelancer piece that ranked on HN front page but never made it into the next brief. None of that is visible unless the link layer is instrumented. This post is the link architecture that makes publisher analytics actually work.
This is a companion to URL shorteners for marketers, which covers the broad marketing use case. Publishers have four distinct needs that generic marketing guidance misses: newsletter attribution chains, syndication channel isolation, paywall conversion joins, and contributor-level ROI.
Why "click-through" is the wrong metric#
Email vendors report open rate and click-through rate. Both are noisy — open rate has been broken since Apple Mail Privacy Protection landed, and CTR varies by list size, topic, and send time in ways that make week-over-week comparison nearly meaningless.
The question worth answering is: which content drove the conversion that matters to your business model? For a Substack, that conversion is a paid subscription. For a trade publication, it is a demo request or a content upgrade download. For an ad-supported newsroom, it is a return visit within 7 days (the proxy for loyal-reader status that commands premium CPM).
Getting there requires a chain: short link → click_id → downstream event. Track UTM campaigns end-to-end covers the general mechanics of building that chain. For publishers, there are five specific contexts where the chain matters most.
1. Newsletter attribution beyond CTR#
A newsletter issue typically contains 8 to 20 links. If every one of them resolves to the article URL with no additional tracking, your ESP tells you 1400 people clicked "something" in issue #83. That is not useful.
The instrumented version: each link in each issue carries a utm_source=newsletter, utm_medium=email, utm_campaign=issue-83, and utm_content=link-position-3 (or a named slug for the article). The short link then resolves to the article with those UTMs appended. If you also pass a click_id — a random token that your ESP embeds per-subscriber and you carry into the destination URL's query string — you can join the click back to the subscriber record.
That join is what makes downstream attribution possible. When the subscriber upgrades to paid two days after clicking link-position-3 in issue-83, the conversion event carries the click_id. You look up the click_id in your link analytics, find it maps to a specific article in a specific issue, and the attribution chain is closed.
For the technical detail on passing that click through to a server-side conversion event, server-side conversion tracking is the long read.
Practical note: most ESPs have their own click-tracking domain — something like link.yourpublication.com. That domain is controlled by the ESP, not by you. If you switch ESPs, every old link in the archive resolves through the old vendor's domain or stops resolving entirely. Using your own URL shortener as a proxy layer — where the ESP tracks the click on link.yourpublication.com, which immediately redirects to go.yourpublication.com/issue-83-p3, which is your short link — keeps the meaningful analytics on infrastructure you own.
2. Syndication tracking by partner#
Syndication is a significant traffic source for many publishers. The Reuters Institute Digital News Report consistently shows that a meaningful fraction of article consumption happens outside the publisher's own domain — through Apple News, Flipboard, SmartNews, MSN, or direct RSS aggregators.
The problem: the canonical URL is the same for all syndication channels. When a reader clicks your article in Apple News, the URL the Apple News app opens is your canonical URL. Unless Apple News appended its own referrer parameter (and some do, inconsistently), the click looks like organic direct traffic in your analytics.
The instrumented version: give each syndication partner a distinct short link. go.yourpublication.com/apple-news/article-slug carries utm_source=apple-news&utm_medium=syndication. go.yourpublication.com/flipboard/article-slug carries utm_source=flipboard. Now you have a per-syndication traffic surface that does not rely on the partner's own dashboard.
This matters for contract renegotiation. Most syndication agreements include traffic guarantees. If your analytics show Apple News delivered 12 000 clicks last quarter and Apple News's own dashboard shows 15 000, the discrepancy is worth understanding before you renew at their proposed rate.
Creating per-partner short links for each article is the operational overhead. The payoff is that you can quantify which syndication partners actually convert vs. which ones generate bounce traffic. Short link analytics — what to measure covers the metrics that distinguish engaged traffic from bounce traffic.
3. Paywall conversion attribution#
The paywall conversion event needs to know which content piece drove the upgrade decision. Most paywall vendors (Piano, Zephr, Tinypass, Leaky Paywall) fire a conversion webhook when a subscription is created. That webhook typically carries the article URL the reader was on when they hit the wall.
What the webhook does not carry by default: which distribution channel brought the reader to that article. Was it the newsletter issue from two days ago? A Reddit self-post? Organic search? A syndication click from SmartNews?
The instrumented version: every short link in your distribution layer carries a UTM and a click_id. When the reader arrives at the article via the short link, the UTMs and click_id are stored client-side (first-party cookie or sessionStorage). When the paywall conversion fires, the conversion handler reads those stored values and includes them in the event. The paywall vendor's webhook receives a richer payload; your analytics warehouse joins the conversion to the originating distribution channel.
The mechanics are the same pattern described in forwarding conversions to Meta CAPI — the target endpoint differs (paywall webhook vs. CAPI) but the click_id passthrough is identical. You can also receive the link click as a webhook from your URL shortener and enrich the event stream before it reaches the paywall vendor; webhooks for link events covers that pattern in detail.
4. Contributor and freelancer attribution#
Many newsrooms are moving toward per-piece performance bonuses for freelancers. The calculus typically includes pageviews, time-on-site, and downstream conversions (subscription starts, newsletter sign-ups) within a 30-day window.
To make that calculation, you need per-contributor attribution. The clean way to do this: when a freelancer submits a piece, issue them a "contributor link" — a short link to their published article that carries utm_content=contributor-<slug>. When the contributor promotes the piece on their own social accounts, they use this link. Every click through that link is attributable to the contributor's own audience-building work.
This is separate from organic traffic the article generates on its own merits. The point is to capture the portion of the article's traffic that the contributor directly drove — which is the portion that should factor into a distribution-based bonus calculation.
The analytics surface is straightforward: filter clicks by utm_content prefix contributor-*, group by contributor slug, sum by article, join to the conversion data from step 3. A dashboard view scoped to utm_content=contributor-* gives the editorial team the per-contributor performance table without any custom SQL.
5. RSS and podcast cross-promo#
RSS subscribers are effectively invisible. Your ESP tells you nothing about them — they consume content in an RSS reader that does not report open rates, click rates, or identity. The only instrumentation available is the link.
If your RSS feed's <link> element points at the article's canonical URL with no tracking, you have no idea whether your RSS audience engages with your content at all, or whether they churn silently when you change publication cadence.
The instrumented version: wrap the article URL in a tracked short link before putting it in the RSS item. go.yourpublication.com/rss/article-slug?utm_source=rss&utm_medium=feed. RSS readers that render the article open the short link, which redirects to the canonical URL and records a click. You get a daily "RSS clicks" time series.
The same approach applies to podcast show notes. If you publish a podcast alongside a text publication, the show notes are your highest-intent audience touch — they listened to the full episode and then opened the show notes. A tracked short link for every URL in the show notes tells you which content the podcast audience actually clicks through on.
Important caveat: RSS aggregators often cache feed entries for hours. The click timestamp from your analytics will lag behind the actual publish time by the cache window. Factor that lag in when attributing traffic to publication timing.
6. Community and forum distribution#
Reddit and Hacker News remain significant traffic sources for tech-adjacent publications, B2B trade press, and niche-content sites. The press data on this is consistent: a single front-page HN story can generate more pageviews in 24 hours than a week of organic search.
The challenge: self-posts to Reddit and HN that link directly to your article URL give you no indication of where the traffic came from unless the referrer header survives (it does not always survive app browsers or privacy extensions). A short link solves this.
When you — or a contributor, or a community manager — shares a link to r/relevant-subreddit, use go.yourpublication.com/reddit/r-whatever/article-slug. The click is recorded. You know that 840 clicks came from that Reddit post. You can also compare: did the r/programming post convert subscribers at the same rate as the r/businessintelligence post? That comparison tells you which communities your publication actually serves.
This requires discipline in the distribution team: every external link share uses the short link, never the raw URL. The payoff is a community-attribution surface that most publications lack entirely.
The four anti-patterns that corrupt publisher link data#
1. Letting the ESP's click-tracking domain be the only link surface. Your ESP issues click-tracking links under a domain they control — link.yournewsletter.com or similar. They record the click, then redirect to your content. That is fine as a secondary record. The problem is when it is the only record. If you switch ESPs, every historical link in your archive resolves through your old vendor's domain. Some ESPs kill those redirects within 90 days of account close. You lose link history, break archive content, and hand your analytics continuity to a third party. Use your own URL shortener as the source of truth; the ESP's tracking is the secondary layer.
2. Using utm_source=newsletter as a single bucket. Tagging everything with utm_source=newsletter is marginally better than no tagging, but it answers none of the questions that matter. Issue #83 and issue #84 look identical. The top-of-newsletter placement and the footer link look identical. The paid-subscriber list and the free list look identical. Useful UTM hygiene for newsletters requires at minimum utm_campaign=issue-<n> and utm_content=<article-slug-or-position>. Track UTM campaigns end-to-end has the full taxonomy.
3. Not retiring short links after a campaign ends. A short link that was live for a two-week content campaign in Q1 2024 still resolves in Q3 2025 — and still shows up in your click analytics. Readers who saved the link, bookmarked the article, or embedded it in a third-party post keep sending clicks through it. Those clicks muddy your current campaign data and can mislead an automated anomaly alert into flagging normal old traffic as a new spike. Link-rotting prevention strategy covers the full lifecycle: when to archive, when to redirect to a successor URL, and when to let a link expire gracefully.
4. Treating click-through as the only outcome. The newsletter drove 1400 clicks. What did those clicks do? If the answer is "we don't know — we just look at CTR" then the entire data stack described above is moot. The paid conversion, the newsletter sign-up, the subscription start — those are the outcomes that matter to a publisher's business model. They need to join back to the link. Every item in this post is oriented toward making that join possible; click-through is just the first record in the chain, not the final answer.
A reference architecture for a mid-size digital publisher#
This is the link structure I recommend most often for a newsroom publishing 5–20 pieces per day with a newsletter in the 20 000–200 000 subscriber range.
One short domain per publication brand. go.yourpublication.com. Custom-domain short links, EU-resident click data, no third-party branding on the redirect path. If you run multiple publications under one parent company, each brand gets its own subdomain — cross-publication attribution still works via the shared analytics backend.
Four slug prefixes:
n/— newsletter links.go.yourpublication.com/n/83/article-slug. Issue number + article slug in the path. Per-issue, per-article attribution at a glance.s/— syndication links.go.yourpublication.com/s/apple-news/article-slug. Partner name in the path for easy filtering.c/— contributor links.go.yourpublication.com/c/contributor-slug/article-slug. Per-contributor, per-article.r/— RSS and feed links.go.yourpublication.com/r/article-slug. Disambiguates feed traffic from newsletter traffic in aggregate reports.
Three attribution surfaces:
- Newsletter click → subscriber conversion via
click_idpassthrough to the subscription platform. Answers "which issue / which article drove paid conversion?" - Syndication click → traffic quality via UTM grouping. Answers "which syndication partner sends engaged traffic vs. bounce traffic?"
- Contributor click → performance bonus via
utm_contentgrouping. Answers "how much of this article's conversions came from the contributor's own audience?"
This architecture requires no new infrastructure beyond your URL shortener. The short link records the click; the UTMs carry the context; the click_id closes the attribution chain on conversion. Total setup: 2–3 hours for the slug taxonomy, then 10–15 minutes per issue to generate the newsletter link set.
Where Elido fits#
Elido is not a newsroom CMS. The link layer described above is architecture-neutral — it works with any URL shortener that supports custom domains, UTM templating, and webhooks. What makes Elido the natural fit for EU-first publishers:
- EU data residency by default. Click events live in EU-region ClickHouse. GDPR coverage for reader click data requires no special configuration. Press publishers operating under GDPR (which is most of the European market) do not need to negotiate a data-processing addendum to cover click analytics.
- Webhook-on-click within 200ms. Every short-link click fires a signed webhook to your paywall or CRM. The
click_idpassthrough described in the paywall attribution section above requires this webhook to arrive before the reader finishes loading the article. 200ms is well within that window. - Link expiry and redirect rules. Set a link to expire after 30 days, redirect to a "this campaign has ended" URL, or forward to the article's canonical URL in the archive. The link-rot anti-pattern is solved at the platform level without manual link hygiene.
- Bulk newsletter link generation.
POST /v1/links/bulkwith a JSON array of{slug, destination, utm_*}entries generates an entire issue's link set in a single API call. Integrates with your editorial calendar tool via the webhooks for link events dispatch pattern.
For the full analytics-layer discussion that underpins publisher use cases, short link analytics — what to measure is the companion piece.
Related on the blog#
- Track UTM campaigns end-to-end — the cornerstone for attribution taxonomy
- Short link analytics — what to measure — the metrics layer beyond click count
- Server-side conversion tracking — closing the attribution chain at the conversion event
- Link-rotting prevention strategy — link lifecycle for archive-heavy publishers
- Forwarding conversions to Meta CAPI — click_id passthrough mechanics
- URL shorteners for marketers — the broader marketing context
- Webhooks for link events — real-time click dispatch into your stack