Developers interact with links everywhere — projected from a conference stage, embedded in a README, buried in a curl | sh install script, pasted into a Hacker News comment. The difference between a dev-marketing team that understands its audience and one that doesn't is usually visible in the link layer: one uses raw GitHub URLs on slides that no one in row 30 can read; the other has a clean go.yourtool.dev/talk-gophercon that the audience is already clicking before the session ends.
This post is the link architecture for developers who create content and the teams who support them. It covers six use cases — conference talks, GitHub READMEs, blog attribution, install scripts, OSS sponsorship, and Discord — and the four anti-patterns that surface most often when the setup goes wrong.
For the UTM-fundamentals grounding, Track UTM campaigns end-to-end is the reference post. For context on what smart links can do beyond simple redirect, smart links explained is the better starting point.
Six use cases that matter for developers#
1. Conference talk short URLs#
A 45-minute talk typically asks the audience to visit three to six URLs: the slides, the repo, a live demo, a post-talk feedback poll, a Discord or Slack invite, maybe a blog post that goes deeper. On most slides, those are raw URLs — github.com/yourorg/yourproject, docs.yourproject.dev/getting-started, discord.gg/abc123xyz. From row 30, none of those are readable. From row 10, maybe two of them.
The cleaner pattern: one short URL per talk, projected in a large font at the bottom of every slide. Something like go.yourproject.dev/gophercon-2026. When clicked, it resolves to a landing page that links to everything — or, with device-aware routing, resolves differently for mobile (the Discord join link, since mobile users are most likely opening it on their phone mid-talk) versus desktop (the slides PDF, since desktop viewers are probably at home watching the recording).
What you learn: per-talk attribution. If you spoke at four conferences this year, the gophercon-2026 link and the kubecon-2026 link and the strangeloop-2026 link let you compare audience engagement across events. Which audience starred the repo? Which drove the most doc visits? Which conference sent zero traffic after the talk? That data shapes next year's conference budget.
What Elido's API lets you build: create a short link per talk via POST /v1/links, include a device_rules block to split mobile vs desktop, tag with utm_campaign=gophercon-2026&utm_medium=conference&utm_source=stage. The API + SDKs quickstart covers the call shape. If you want to automate this from a talk-submission form, the short links as Terraform post covers the declarative config approach.
2. GitHub README links#
A typical OSS project README has between 8 and 15 outbound links: docs, demo, Discord, OpenCollective, GitHub Sponsors, CI badge, npm/PyPI/crates.io, changelog, contributing guide, security policy. Every one of those links gets clicks. Almost none of them are tracked.
The question OSS maintainers rarely have an answer to: which link in your README actually drives Discord joins? Is it the "Join our community" line in the features section, or the badge at the top, or the contributing guide at the bottom? Most maintainers would guess the badge. The data often says the contributing guide.
Short links as README badges solve this: replace https://discord.gg/abc123xyz with https://go.yourproject.dev/readme-discord. Same destination, but now you know how many clicks came from the README vs from a blog post vs from a talk slide. The link renders identically in the Markdown — GitHub strips UTM parameters from raw URLs anyway, but a short link passes through as-is.
The badge pattern: for each outbound link category in the README, create a slug: readme-docs, readme-discord, readme-demo, readme-sponsor. Tag each with utm_source=github&utm_medium=readme&utm_content=<slug>. Now you have a per-link breakdown of README engagement. The "decorative link audit" — finding which README links get zero clicks after 90 days — is a useful quarterly cleanup task.
What you learn: GitHub's own traffic page shows referrers, but not which link within the README sent traffic. Short links close that gap. If readme-sponsor has 600 clicks in 30 days and your GitHub Sponsors count moved by four people, you know your README-to-sponsor conversion rate is under 1%. That's actionable.
3. Blog post and Hacker News attribution#
A developer blog post reaches audiences through very different channels: HN, Reddit, LinkedIn, Twitter/X, newsletters, other devs linking in their own posts. Each channel has different reader intent and different conversion to "starred the repo."
The naive approach: post the raw URL everywhere and look at aggregate Plausible or GA traffic. That tells you total visits, not which channel drove which action. The channel-aware approach: create one short link per distribution channel, each with a UTM source. When you drop the blog post into HN, you post go.yourproject.dev/post-hn-clickhouse-joins. On Reddit you post go.yourproject.dev/post-reddit-clickhouse-joins. LinkedIn gets its own. Your newsletter gets its own.
The HN front-page case: the biggest single-day traffic spike most dev blogs ever see comes from an HN front-page hit. Those hours are unusually valuable — the audience is senior, technical, and opinionated. If your short link fires a click event into your analytics pipeline and you forward goal completions (GitHub star clicks, doc-signup clicks) back into the attribution chain, you can answer "did HN traffic convert to repo stars, or just read and leave?" The HN reader is famous for reading and leaving; if the data confirms that, it informs how you write the HN summary comment, not just the blog post itself.
For the conversion forwarding mechanics, Track UTM campaigns end-to-end covers how to pass click-IDs from the short link into your analytics stack and join them to downstream goal events.
4. CLI-friendly short URLs#
When a developer runs an install script — curl go.yourproject.dev/install | sh — the short link in that script tells you something that your download counter does not: it tells you where the person who ran it heard about you in the first place.
If the install short link carries a utm_source from the talk that recommended it, or the README that linked to it, you get a chain: talk slide click → blog post click → install script execution. Most dev tools can't close that loop because they don't own the link between the distribution point and the install event.
Trust considerations: developers are increasingly cautious about curl | sh from non-first-party domains. This is a legitimate concern and it has a legitimate answer: your short domain (go.yourproject.dev) should CNAME to Elido, not redirect through bit.ly or any other third-party domain that the developer community has associated with spam or ad-tech. The domain the short link runs under is a trust signal. Bit.ly in an install script is a red flag to a security-aware developer. Your own project domain is not.
The EU-first angle matters here too: short link resolvers in the EU can commit to no third-party tracking pixels, no cookie injection, and GDPR-covered click data — relevant if your OSS project serves European enterprise adopters who ask about data handling in the evaluation phase.
5. Sponsorship attribution for OSS#
GitHub Sponsors, OpenCollective, and similar platforms give sponsors a reason to fund your project. They don't give sponsors a way to measure which of their funded repos actually drives product awareness or trial signups.
A sponsor funding 12 OSS repos wants to know which three are worth doubling down on. Without per-repo attribution data, the sponsor is guessing based on star counts — a lagging, gameable metric that doesn't correlate tightly with the awareness-to-conversion funnel the sponsor actually cares about.
The attribution approach: for each sponsor relationship, issue a dedicated short link for the placement that the sponsor gets in return for funding (README badge, footer line, release note mention). go.yourproject.dev/sponsor-acme-corp routes to the sponsor's landing page and records how many clicks that placement generates per month. The sponsor gets a monthly attribution snapshot. You get a retention argument for renewal: "your placement in our README drove 340 clicks to your product this month."
This is a sharper pitch than "we have 8,000 stars." Stars are public and every other sponsor knows the same number. Click attribution from your specific README is proprietary to the relationship.
6. Discord invite tracking#
Discord invite analytics answer one question: how many people joined through this invite link. They do not answer: where did those people come from before they clicked the invite?
Discord's native analytics have no referrer. You know that 40 people joined today. You don't know that 35 of them came from the HN thread and 5 came from the conference talk you gave last week. The short-link wrapper closes that gap.
Replace every Discord invite URL you share with a short link that 302s to the Discord URL. Each distribution point gets its own short link slug: discord-hn, discord-gophercon, discord-readme-top, discord-readme-contributing. When someone clicks go.yourproject.dev/discord-gophercon, Elido records the click, captures the referrer header, fires any webhook you've configured (say, a Slack ping to your #community channel), and then redirects to Discord. Discord records a join. You now have two events you can join: the click event with referrer, and the Discord join event by timestamp.
What you learn: which distribution channel actually builds your community, vs which channel drives traffic that bounces. If discord-hn sends 200 people and 170 join (85% follow-through), and discord-talk-slides sends 40 people and 38 join (95% follow-through), the conference audience is your highest-intent community channel — even though HN sent five times the volume.
The four anti-patterns#
1. Raw GitHub URLs on slides. The full GitHub URL for a repo is typically 35-60 characters, wraps across lines in landscape slide layout, and is unreadable from beyond row 6. Nobody in the back half of the room is typing that URL into their phone. A 4-8 character slug on a short domain is typeable from row 30 in the time it takes to pull out a phone. Project the short URL in a large, contrasting font in the lower-left or lower-right corner of every slide — not just the last one. Audience members stop paying attention to the slides URL by slide 10 if they had to wait.
2. Bit.ly in install scripts and CLI tools. The developer community's trust in bit.ly has eroded. When a security-aware engineer sees curl bit.ly/xyz | sh, they either refuse to run it, or they curl-inspect the chain first, which slows adoption. The distrust is not irrational — bit.ly has been used to redirect through ad networks that attempt cookie injection. Using your own project domain (go.yourproject.dev) on Elido's infrastructure gives you the link analytics you want without the trust cost. The domain you use for short links is a brand signal.
3. One generic Discord invite for all channels. A single discord.gg/yourserver shared everywhere looks efficient. It is analytically opaque. You have no idea whether your Discord growth is coming from your blog, your conference talks, word-of-mouth, or a random YouTube video someone made about your tool. Issue one short-link-wrapped Discord invite per significant distribution channel. Archive old ones when the channel is no longer active. The operational overhead is two minutes per channel; the analytical value compounds over time.
4. Treating the stargazers graph as your only attribution data point. Star counts are public, delayed, and influenced by factors you don't control (HN front page, ProductHunt launch, a high-profile tweet). Using stars as your primary attribution metric means you're measuring the output of your distribution, not the mechanism. Short-link attribution at each distribution touchpoint — talk, README, blog, newsletter — gives you the input data that explains why the stars graph moved when it did, and which inputs are reliable enough to repeat.
A reference architecture for an OSS project#
This is the link structure I recommend when a maintainer is starting from scratch or rationalising an existing mess.
One short domain for the project. go.yourproject.dev. CNAME to Elido's edge. Cert issued in under 30 seconds. Every link lives under this domain — talks, README, blog, Discord, install.
Slug namespaces by intent:
t/— talk links.t/gophercon-2026,t/kubecon-na-2026. One per conference appearance. Device-aware rule: mobile → Discord join, desktop → slides PDF.r/— README links.r/docs,r/discord,r/demo,r/sponsor. Stable slugs that don't change between major versions — just update the destination URL when docs move.b/— blog distribution links.b/hn-clickhouse-joins,b/reddit-clickhouse-joins. Created per post-per-channel at publish time.install— the install script slug. One slug, one destination, UTM source passed in the destination URL so the install script knows it was reached via the short link.s/— sponsor links.s/acme,s/hashicorp. Per-sponsor-relationship, renewed each contract cycle.d/— Discord invites.d/talk-gophercon,d/readme-top,d/hn-post-jan-26.
Three analytics surfaces:
- Talk performance dashboard — scoped to the
t/prefix. Answers: which conference drove the most post-talk engagement? Which device split shows mobile-dominant audiences (talks where the speaker asks the audience to join Discord live)? - README engagement report — scoped to the
r/prefix. Monthly export. Answers: which README links are decorative (under 10 clicks/month) vs load-bearing? - Community source breakdown — scoped to the
d/prefix. Correlates with Discord member growth by cohort. Answers: where does our community actually come from?
Infrastructure notes for the security-conscious#
Developers read whitepapers. If you're using a link shortener for a security-sensitive audience — infrastructure tooling, developer security products, anything touching compliance — a few notes are worth making explicit to your audience:
EU data residency. Click events in Elido live in EU-region ClickHouse by default. No cross-Atlantic transfer of click data unless you explicitly configure it. Relevant for EU enterprise adopters running through InfoSec reviews.
No ad-tech tracking pixels. Elido does not inject third-party pixels, ad-exchange beacons, or cross-site tracking cookies on redirect. The redirect is a clean 302. The only analytics are first-party: your click data, your account.
HMAC-signed webhook payloads. If you configure webhooks from short link events (say, a webhook that fires when someone clicks your install link and you want to log it in your own data warehouse), Elido signs every payload with HMAC-SHA256. Your handler can verify origin without a shared bearer token.
Declarative link management. If your project uses infrastructure-as-code for everything, the short links as Terraform post covers the Elido Terraform provider and the MCP integration with Claude and Cursor covers the AI-assistant-driven workflow for teams that manage links through their AI coding environment.
Where Elido fits alongside your existing dev toolchain#
The API + SDKs quickstart has the five-minute version of link creation via the REST API and the TypeScript, Python, and Go SDKs. For most OSS maintainer workflows, the SDK is overkill — the Elido dashboard's bulk-create UI and the CLI are faster for ad-hoc talk links. The SDK becomes valuable when you want to auto-provision links from a GitHub Action (e.g., create a distribution short link whenever a new blog post is merged), or when you want to build the attribution reporting into your own internal dashboard.
For developer marketing teams managing multiple projects, the workspace and team features let you segment link namespaces by project, control who can create or archive links in each namespace, and export per-project attribution CSV for the quarterly sponsors report.
Related reads for teams combining URL shortener attribution with broader developer marketing:
- URL shorteners for SaaS: the full attribution stack — the sibling post for SaaS product teams with developer audiences
- URL shorteners for startups: lean attribution before you have a data team — relevant if you're an early-stage tool with one person running DevRel
- Track UTM campaigns end-to-end — the UTM fundamentals reference
- Smart links explained — device-aware routing, geo-routing, A/B testing at the link layer
- Short links as Terraform: declarative link management — IaC-style link management for infrastructure-minded teams
- Elido MCP: manage links from Claude and Cursor — AI-assistant-driven link workflows