This article walks through the model we recommend for combining UTM tagging with a short-link service, with the specific failure modes we see in support tickets and how to design around them.

What each tool actually does

A short link is a redirect. A user clicks thin.ly/launch-q3, the server looks up launch-q3 in a database, finds the destination, and issues an HTTP 302 to that URL. The destination URL can contain anything — including UTM parameters.

UTM parameters are query-string key/value pairs (utm_source, utm_medium, utm_campaign, utm_content, utm_term) that Google Analytics and most other analytics tools recognize as campaign metadata. They’re read at the destination, on the landing page itself, after the redirect has already happened.

This means UTM parameters live on the destination URL, not on the short link. The short link is the wrapper; the UTMs ride inside it.

The basic pattern

If your campaign destination is:

https://acme.com/pricing

and you want it tagged for a paid social campaign, the destination URL you shorten is:

https://acme.com/pricing?utm_source=linkedin&utm_medium=cpc&utm_campaign=q3-launch&utm_content=carousel-a

Then you shorten that — full string with UTMs — into something like thin.ly/q3-launch-li. The user clicks the short link, the server redirects to the long URL with UTMs intact, the destination page records the visit under the correct campaign in your analytics.

The mistake we see most often is shortening the bare URL and then trying to “add UTMs in the short link” by appending them after the slug, like thin.ly/q3-launch?utm_source=linkedin. Most shorteners (including thin.ly) strip those because they’re meaningless to the lookup engine — the slug is q3-launch, the query string is noise. The redirect goes to the bare destination and your analytics records “direct traffic.”

Picking values that aggregate cleanly

Google Analytics doesn’t normalize UTM values. Linkedin, linkedin, LinkedIn, and LINKEDIN are four different sources in your reports. Adopt a small convention and write it down:

• utm_source — always lowercase, no spaces (linkedin, newsletter, partner-acme).
• utm_medium — pick from a short, fixed vocabulary: cpc, email, social, affiliate, referral, print. If a new value feels needed, add it to the vocabulary first; don’t invent it in a campaign.
• utm_campaign — date or version prefix is your friend (2026-q3-launch, winter-promo-v2). It groups campaign reports chronologically and survives reuse later.
• utm_content — variant identifier (headline-a, carousel-bg-purple). This is where A/B variants live.
• utm_term — paid-search keyword. Leave it empty for non-search traffic.

If you’re using thin.ly, the link’s title field is a good place to write the human-readable name of the campaign while the destination URL holds the machine-readable UTM string.

Where short links genuinely help

The reason to shorten a UTM-tagged URL at all comes down to four things:

1. Length. A fully tagged destination URL is often 200+ characters. It won’t fit on a printed flyer, in an SMS, or comfortably in a tweet.
2. Stability. If a campaign destination needs to change — pricing page gets a new path, the landing page moves — you can swap the short link’s destination without re-printing materials or asking partners to update their copy.
3. Click analytics independent of the destination. UTMs only fire if the user reaches the landing page and the analytics script loads. The short link records the click the moment the redirect happens, before any page-load or ad-blocker can interfere.
4. Per-link governance. A short link lets you pause a campaign by pointing the link at a “campaign ended” page, or expire it on a schedule, without touching the underlying site.

Failure modes to design around

A few problems we see repeatedly:

Email clients stripping query strings. Some corporate mail security products rewrite URLs in inbound mail, and a few of them strip query parameters they don’t recognize. UTMs vanish. The fix is to put the UTMs inside the short link’s destination so the user clicks thin.ly/launch-q3 and the redirect — fired from your server, not the mail rewriter — carries the UTMs through. Add an HTTP-level test by sending one mail and clicking through to confirm.

Social platforms appending their own parameters. LinkedIn and Facebook sometimes append a ?trk=… or fbclid=… to outbound links. Most analytics tools handle these without issue, but if you build a report by URL the appended noise will split your rows. Either filter fbclid/gclid/trk in your analytics view, or strip them in your destination router.

The “two-shortener” problem. Marketing shortens a tagged URL, then a partner re-shortens that with a different service for their newsletter. You now have two redirects in series, and the analytics on the first hop record one click while the second hop’s analytics record a different one. Pick a single source of truth before launching a campaign, and tell partners to use that link as-is.

Reusing campaign values. Every report becomes harder to interpret when utm_campaign=launch appears in three different quarters. Treat the campaign string as a version number. Future-you will thank you when year-over-year comparisons stop requiring a SQL pivot.

A practical workflow

1. Decide on a campaign name and write it in your link-management tool’s title field.
2. Build the destination URL with full UTM parameters using your vocabulary.
3. Shorten the full URL (with UTMs). Give the short link a memorable slug.
4. Test the click path: short link → expected destination, UTMs intact, the visit appears in your analytics under the right campaign.
5. Distribute the short link, not the long one. Never distribute both — if anyone has the long URL, half your clicks will arrive untagged.

Done well, the combination gives you a clean campaign roll-up, a stable short link you can swap if anything changes, and click counts that don’t depend on the destination’s analytics being healthy. That last property is what makes the pairing worth the setup time.

This is a guide to making QR codes that actually work in printed materials: what dynamic QR codes are, why static QR codes will hurt you, the size and contrast rules, and the small craft details that decide whether anybody scans them.

Static QR codes vs dynamic QR codes

A QR code is just a 2D barcode encoding a string of text. If that string is a URL, the user’s camera offers to open it. Everything else — branding, analytics, the ability to change the destination later — depends on what’s in that string.

A static QR code encodes the destination URL directly. Scanning the code takes you straight to https://acme.com/menu/spring-2026. The QR pattern is determined by the URL: longer URLs need denser patterns. If you ever want to change the destination, you cannot — the pattern is already printed. The destination URL must outlive the campaign.

A dynamic QR code encodes a short URL: https://thin.ly/spring-menu. The user’s camera opens that short URL, the server redirects to the real destination. The destination can be swapped at any time without reprinting anything. The QR pattern is also simpler because the encoded string is short, which means the printed code can be smaller while remaining scannable.

For anything that goes to print, use a dynamic QR code unless you are absolutely certain the destination will never change. The cost of being wrong is reprinting. The cost of being right early is nothing.

Sizing

The two failure modes for printed QR codes are “too small to scan” and “large enough but printed too close to other dark elements.” Both have specific thresholds.

The minimum scannable size depends on the distance between the camera and the code. As a rule of thumb, the code’s side length should be 1/10th of the expected scan distance:

These are minimums. Add 20% for outdoor billboards and anything that might be photographed at an angle. The most common mistake is reusing a small brochure-sized QR code on a poster that lives across a hotel lobby.

Contrast and quiet zone

QR readers need high contrast and a clear border. Two rules:

1. Dark code on a light background. Inverted QR codes (light on dark) work in software but fail in many phone-camera apps because the camera’s auto-exposure assumes dark-on-light. If your brand demands light-on-dark, test on three different phones before printing.
2. Quiet zone of at least 4 modules. A “module” is one of the small squares that make up the pattern. The quiet zone is the empty margin around the code. Without it, surrounding dark elements (a black border, a photo, a column of text) merge with the code’s edge and the reader gives up. Four modules is the spec’s minimum; six modules is safer.

If you must put the code over a photo, use a solid white box behind it with the quiet zone inside the box. The marketing-design impulse to “integrate” the code with surrounding imagery is the single biggest source of failed prints.

What surrounds the code matters as much as the code

A QR code with no accompanying text gets ignored. Users need to know why they would scan it. A few rules that come from watching scan rates against otherwise-identical layouts:

• Tell people what they get. “Scan to see the menu” beats “Scan here.” Even a vague benefit beats no benefit.
• Mention the platform. “Scan with your phone camera” is unnecessary in 2026 — every smartphone reads QR codes natively. But “Watch the video” or “Read the recipe” tells the user what they’re committing to.
• Put it near the call to action it supports. A QR code in the corner of a poster, separated from the product photo, gets a tenth of the scans of one placed next to the headline.
• Include a short URL as fallback. Print the short URL — thin.ly/spring-menu — under the code in small type. Users on older devices, in poor light, or with smudged camera lenses will type it in. Roughly 5-10% of attempted scans fail; the short URL recovers those.

Tracking print-only campaigns

The point of a dynamic short link behind a QR code is that you get click analytics on a campaign that otherwise has no telemetry at all. A printed poster doesn’t fire a Google Analytics event when someone walks past it, but the moment they scan the code, your link service records the click with timestamp, country, device, and referrer. Over a campaign you can see:

• Total scans and unique scanners (most short-link services dedupe by IP).
• Geographic distribution, useful for figuring out which locations got the best foot traffic.
• Time-of-day patterns, which often reveal when the poster is actually being noticed.
• Device split, which sometimes shows surprising things — print campaigns aimed at older demographics often get more iPad scans than expected.

UTM parameters on the destination give you the same data inside your web analytics, with the bonus that you can see what users did after they landed.

The reusability dividend

The strongest argument for dynamic QR codes is the long tail. A static code on a 2024 menu is dead the moment the menu changes. A dynamic code on the same menu can be repurposed in 2025 by changing the destination — the print artifact keeps working. Restaurants we’ve talked to who switched to dynamic codes ended up using the same printed laminated menus through three menu cycles, swapping the URL twice. Same physical cost, three times the lifespan.

The same pattern works for product packaging, conference badges, vehicle livery, real estate signs — anywhere reprinting is expensive and the destination might shift. Dynamic codes are the cheaper option once you factor in the second print run you would otherwise have done.

A pre-flight checklist

Before sending a layout to print:

1. The QR code is dynamic (encodes a short URL, not the destination).
2. The destination URL has UTM parameters set for this print campaign.
3. The code is sized for the actual viewing distance.
4. The quiet zone is at least four modules clear of surrounding artwork.
5. Contrast is dark on light, and tested on three phones in average lighting.
6. The short URL is printed under the code as a fallback.
7. The accompanying text tells the user what they get by scanning.
8. You’ve placed a single test scan from each phone OS before the press run.

The last item costs ten minutes and saves more reprints than any other pre-flight check on the list.

This article goes through the standard metrics, what they actually measure, and the questions they’re worth asking.

Clicks vs. unique clicks

Total clicks is the count of redirects served. Unique clicks dedupes by visitor, usually by IP address combined with a short time window.

The gap between the two tells you something the headline number doesn’t. A 50% unique rate (10 total clicks, 5 unique visitors) means heavy revisitation — your audience is bouncing back to the link multiple times, which is normal for documentation, reference pages, and resources people need repeatedly. A 95% unique rate (10 clicks, 9.5 unique) means each visitor came once and didn’t return — normal for promotional links and one-time content.

Neither pattern is “good” or “bad” on its own. They are a signal about the relationship between your content and your audience. A documentation link with a 95% unique rate suggests people aren’t returning to consult it, which means either the content was insufficient or one-and-done was the right outcome. A promotional link with a 50% unique rate is suspicious — you may be looking at click farms, ad-network bots, or your own QA team clicking repeatedly.

The most important caveat: IP-based deduplication is approximate. Two users on the same office NAT show up as one IP. One user on a mobile network that rotates IPs shows up as several. Trust the trends, not the absolute numbers.

Geographic distribution

Country-level data is reliable. City-level data is less reliable. Both come from a GeoIP database that maps IP addresses to locations, and the mapping has known limitations:

• VPNs and proxies are very common. A user connecting through a London VPN exit node shows up as a London click regardless of where they actually are.
• Mobile carriers sometimes route traffic through gateways in different regions than the user. A US user on T-Mobile occasionally shows up as Seattle even if they’re in Atlanta.
• Cellular IPs can be reassigned across cities in minutes.

The useful questions to ask:

• Is the geographic shape broadly what you expected? If you ran a campaign aimed at US small businesses and most of your clicks are in Vietnam, you’re probably looking at scraper or bot traffic.
• Is the distribution stable across days, or do you have one spike from a country you didn’t target? A single-day Brazil spike usually means you got mentioned somewhere — a blog post, a forum thread, a newsletter.
• Are there countries you targeted that show no clicks? That’s worth investigating before you blame the targeting; the GeoIP database may be mis-mapping them.

Referrers

The referrer is the URL of the page the user was on when they clicked. It’s usually the most actionable piece of data on the dashboard because it tells you which surfaces are actually sending traffic.

Limitations to know about:

• Direct traffic doesn’t mean someone typed your URL from memory. It means the browser sent no referrer header. The most common cause is a click from inside an app — Slack, Discord, WhatsApp, Twitter — where the platform doesn’t expose the originating URL. Mobile clicks are disproportionately “direct” for this reason.
• HTTPS-to-HTTP links strip the referrer for privacy. Increasingly rare now that almost everything is HTTPS.
• Referrer policies (Referrer-Policy: no-referrer) on the source site strip the value. Search engines and major social platforms apply policies that send only the origin, not the full URL — you’ll see google.com but not the specific search results page.

A high “direct” share isn’t a failure; it usually means messaging-app traffic is doing the work. If you’re running a campaign and direct clicks are 70% of the total, look for the conversation. There’s a Slack or WhatsApp or Discord thread out there driving the campaign that doesn’t appear in your referrer report.

Device split

The mobile/desktop/tablet split tells you what kind of moment the click represents. A short link distributed via email shows desktop dominance during work hours and a slow shift to mobile in the evening. A short link distributed on Instagram Stories is 95%+ mobile by definition.

Device data is reliable because it’s parsed from the user-agent header, which mobile devices and desktops set distinctively. It is not reliable for distinguishing tablets from large phones — iPads identify as tablets, but Android tablets often identify as desktops or phones depending on the browser, and most analytics tools count them inconsistently.

The interesting question is whether the device split matches the distribution channel. A campaign you ran on LinkedIn — a desktop-dominant platform — that turns out to be 80% mobile clicks suggests the link traveled. Someone shared it onward, probably via messaging. That’s a story worth investigating.

Click-through rate (CTR)

CTR is impressions divided by clicks. Link services typically don’t show CTR because they don’t see impressions — they only see the click side. If you have impressions data from another source (an ad platform, an email tool, a social analytics dashboard), you can compute CTR manually: clicks on the short link divided by impressions of the container.

Industry benchmarks for CTR are noisier than the published numbers suggest. A “1-3% CTR” for display ads is so context-dependent that the range is almost useless. Better practice: establish your own campaign-class baseline and compare against it. CTR on your prior newsletter campaigns, CTR on your prior LinkedIn posts, CTR on your prior conference-poster QR codes. Year-over-year comparison against yourself is more honest than industry benchmarks.

Time-of-day distribution

A 24-hour histogram of clicks is more revealing than it looks. Three patterns to watch for:

1. Working-hours skew. B2B audiences cluster between 9am and 6pm local time, with a lunchtime dip. If your dashboard shows a flat 24-hour distribution for a B2B campaign, you may be looking at bot or click-fraud traffic.
2. Late-night peaks. Consumer content and entertainment often peak between 9pm and midnight. If you’re targeting professionals and seeing this pattern, your audience definition is off.
3. Sudden spikes. A 30-minute spike at 4:17am, followed by silence, is almost always a script. Either a scraper, an uptime monitor that accidentally followed the link, or a CI system. The clicks are real but they’re not human and you should filter them out.

What none of these metrics tell you

A click is not a conversion. Link analytics measure interest in the offer, not engagement with the destination. You can have a beautiful 1,000-click report on a campaign that converted nobody, because the landing page was broken or the offer didn’t match the audience.

Pair click analytics with destination-side analytics — GA4, your CRM, your billing system — and look for the drop-offs. Most teams that “have analytics” are actually only reading the click report, and they miss the part of the story that happens after the redirect.

The question your link analytics can answer is “did the message land and where are the people coming from.” The question your destination analytics can answer is “did the message work.” Both halves matter. Neither replaces the other.

The history of URL shorteners is the history of failed trust. Cheap shorteners get used by spammers, phishers and malware distributors the moment they get enough traction. Eventually mail providers, browsers and ad networks start treating short-link domains as suspect. The shortener gets blocked at the network edge, legitimate users stop being able to deliver email through it, and the service dies.

This article goes through the threat model from a defender’s perspective: what an attacker tries to do with a URL shortener, what serious shorteners (including ours) do to stop them, and what users should look for when deciding whether to trust a short link.

The threat model

There are four broad categories of malicious use:

1. Malware delivery. The short link points at a drive-by download, an exploit page targeting an unpatched browser, or a software bundle that asks the user to install it.
2. Phishing. The short link points at a fake login page, typically mimicking a major service (Microsoft 365, Google, a bank, a crypto exchange) to harvest credentials.
3. Scam content. Fake giveaways, fraudulent investment schemes, pages that demand payment for things the user is not actually receiving.
4. Policy-violating content that is legal but prohibited by the shortener’s terms — typically adult content, gambling that violates local law, or content that mass-violates someone else’s intellectual property.

Each of these has a different defense profile.

Pre-creation scanning

The first defense is at the moment of link creation. When a user submits a destination URL, the shortener can check it against several sources before issuing a short link:

• Google Safe Browsing. Google publishes a list of URLs known to host malware or phishing content. The list is updated frequently and used by Chrome, Firefox and most browser-integrated protections. Querying it at link-creation time catches the largest, most-reported threats.
• Known-bad domain lists. Independent threat feeds maintain lists of domains used for spam, phishing kits, exploit kits, and command-and-control infrastructure. The list overlap with Safe Browsing is partial — each catches a different long tail.
• Heuristic checks. Newly-registered domains (under 30 days old), domains with characters chosen to mimic well-known brands (g00gle.com, microsft.com), URLs with hex-encoded parameters designed to evade pattern matching — these are flagged for review even when they’re not yet on any threat list.

Links that fail pre-creation scanning are either rejected outright or quarantined for human review. At thin.ly, links we can’t scan with high confidence in under a few seconds are issued but flagged for re-scan, and the destination is blocked behind a safety interstitial until the scan completes.

Post-creation rescanning

Pre-creation scanning catches the obvious cases. The more interesting problem is delayed weaponization: an attacker shortens a benign URL, waits a few weeks for the link to accumulate trust and distribution, and then quietly changes the destination’s content to something malicious. The short link is unchanged. The destination is not.

The defense is periodic rescanning. Every short link’s destination is re-checked on a schedule — more frequently for high-traffic links — and any destination that has flipped from benign to malicious triggers an automatic block. At that point, anyone clicking the short link sees a safety interstitial instead of the malicious page.

This is also why we recommend treating a short-link service as a trust boundary in your own infrastructure. If you embed user-supplied URLs in your product, route them through a shortener with rescanning. The benefit is that the shortener absorbs the cost of keeping up with new threat feeds and you get free rescanning as a side effect.

Sandboxed inspection

For destinations that aren’t yet on any threat list, dynamic analysis sometimes catches things static checks miss. A sandboxed browser fetches the destination, executes scripts, watches for redirects to known-bad domains, watches for credential-collection forms, fingerprints the page against known phishing-kit templates. Sandboxing is expensive — milliseconds become seconds — so most shorteners apply it selectively: flagged-on-creation links, high-risk categories, or as a background job after the link is issued.

The role of interstitials

When a destination has been blocked, what happens at click time?

Two options. The bad one: hard 404. The user gets no explanation, and they have no idea whether the link was broken, the destination was removed, or something dangerous was happening. Worse, the link is silently broken for the legitimate users who haven’t been compromised.

The good option: a safety interstitial. The user clicks the short link, the server detects that the destination is blocked, and instead of redirecting it renders a clear page explaining that the destination was flagged as unsafe and giving the user a way to report a false positive. The user understands what happened, the link creator gets a signal that something is wrong, and the malicious destination never loads in the user’s browser.

thin.ly uses interstitials for both flagged destinations and for paused/expired campaigns where there is no longer a valid destination. The interstitial does not load any third-party content.

What users can do

A few practical habits for evaluating short links you didn’t create yourself:

• Preview before clicking. Most shorteners offer a preview URL pattern. For thin.ly, https://thin.ly/preview/<slug> shows the destination without redirecting. Many browser extensions add this capability for all shorteners.
• Trust the wrapper, not the slug. A real thin.ly link will always be on thin.ly. A link that says thin1y.com or thinly.co is not us — homograph attacks rely on users pattern-matching on shape rather than reading the domain.
• Distrust short links from unknown senders. The same rule that applies to executables applies here: if you don’t know why this message arrived, don’t follow the link, no matter how short or branded it looks.

What link creators can do

If you operate a short-link campaign:

• Use HTTPS destinations. Mixed-content warnings will lose you trust even on legitimate campaigns.
• Use a short, memorable slug rather than the auto-generated one whenever you can. thin.ly/spring-menu reads as legitimate; thin.ly/aB3xY9q reads as suspicious to careful users.
• Use a branded domain if you can. A custom short domain (acme.link/spring) carries the brand into the link and prevents it from being mistaken for someone else’s service.
• Watch the click report. A campaign whose clicks are 90% from one country you didn’t target, or are arriving in suspiciously uniform bursts, may have been picked up by a scraper or injected into a botnet’s URL list. That’s a signal to rotate the short link.

The economics of staying clean

Defending a shortener against abuse is continuous work, not a one-time check. The asymmetry is brutal: an attacker has to find one gap, the defender has to close all of them. The reason cheap shorteners get blocked at network boundaries is that they don’t invest in this work, and the bad actors find them quickly.

If you’re picking a shortener for a campaign, ask the vendor what their post-creation rescanning policy is, what their abuse-reporting flow looks like, and how they handle false positives. The answers tell you whether they’re treating safety as a feature or as a cost center.

This article is a decision framework: when a branded short domain genuinely matters, when it’s overkill, and the in-between options worth considering.

What a branded short domain actually buys you

Four things, in roughly descending importance:

Trust at the click. Users are more likely to click a short link on a domain they recognize as belonging to the sender. A LinkedIn post from Acme that links to acme.link/2026-launch reads as internal Acme content. The same post linking to a generic shortener reads as “could be anyone.” For B2B audiences who have been trained by years of phishing emails to look at the domain before clicking, this matters more than the design.

Brand impressions on every share. Every Slack, email, retweet, and printed material that carries your short URL also carries your brand name. Generic shorteners give that real-estate to the shortener itself. If you’re running a 100,000-impression campaign, the branded domain is showing your name 100,000 times for free.

Survival of the shortener. When a generic shortener gets bought, sunsets, or stops paying for its infrastructure, every short link on its domain breaks. Bit.ly and TinyURL have been around long enough that this feels safe, but the graveyard of dead shorteners includes goo.gl (sunsetted by Google in 2024), j.mp, and a few dozen others that have been bought and quietly shut. A branded domain is yours; you control the DNS and the redirect logic regardless of who provides the underlying service.

Defensibility against copycats. A campaign run on a generic shortener is trivial to mimic — competitors can register similar slugs on the same domain, or on a sister generic shortener, and intercept search traffic. A branded short domain is in your control; nobody else can register slugs underneath it.

What it costs

The full cost is rarely the cost the vendor quotes:

• The custom domain itself. A short, memorable domain — three to five letters — in a popular TLD costs $30–$300 a year if available, and four to six figures if you have to buy it on the aftermarket. Newer TLDs (.link, .page, .app) tend to be cheaper but less recognizable.
• The plan tier. Most shorteners gate custom domains behind a paid plan. The price varies but is typically $20–$100 per month on top of the base subscription.
• DNS and SSL. Trivial in 2026 — Let’s Encrypt and most managed DNS providers handle this — but you need someone to do it once.
• Internal coordination. Engineering needs to set up the DNS, marketing needs to use it consistently, finance needs to remember to renew the domain. The cost of failure (an expired domain that breaks every active campaign link) is high.

When the branded option is worth it

A few clear cases where the math works out:

• You’re running campaigns at scale. A campaign that puts your short link in front of more than a few thousand people is generating brand value the branded domain can capture.
• You’re targeting a security-conscious audience. Enterprise buyers, finance teams, IT, healthcare, government — all of them have been trained to look at the domain before clicking. A branded link gets a meaningful CTR lift in these audiences.
• You’re embedding short links in print. A printed poster or product packaging will be in circulation for months or years. The branded domain locks in your brand recognition for the entire campaign lifecycle.
• You compete with copycats or impersonators. If your brand has been spoofed before, a branded short domain is a defensive moat. It is much harder to spoof acme.link/login than to spoof thin.ly/login-acme.

When the generic option is fine

• You’re a small team running occasional campaigns. The branded domain pays for itself at volume; below that, you’re paying for brand polish you don’t need yet.
• The campaign is short-lived and internal. A one-week internal comms campaign doesn’t need to be on a branded domain.
• The audience won’t read the URL. SMS, push notification, and app deep-link contexts hide the URL or show only the tap target. Branded domains add less value when the URL doesn’t visibly appear.

The in-between option

A useful middle path is shared branded subdomains. Instead of buying acme.link, you use acme.thin.ly (or whatever your shortener supports). It carries your brand at the cost of a DNS record, doesn’t require domain ownership, and survives the shortener service if the vendor offers domain portability.

The downside is that you’re still trusting the parent service: any trust issues on thin.ly propagate to acme.thin.ly. The upside is that this is usually included in mid-tier plans without an add-on cost, and it captures the majority of the trust-and-brand benefit at a fraction of the friction.

Two practical questions

If you’re trying to decide right now:

1. Pull up a recent campaign you ran with a generic shortener and imagine the click rate one or two points higher. What does that change in real numbers? If it’s hundreds of clicks across the year, the branded domain is hard to justify. If it’s tens of thousands, you should already be on one.

2. Look at the next twelve months of campaigns you have planned. How many of them put the short URL in front of an audience that actively reads URLs (B2B newsletters, white papers, conference posters)? That count is your real volume for branded value, not total clicks.

What to do this week if you don’t have a branded domain yet

Three steps that don’t require any commitment:

1. Register the domain. Even short three-letter .link or .page domains can usually be found for $20-$40 a year. Buying the domain doesn’t commit you to using it; it just removes the option from competitors.
2. Set the DNS to point at your current shortener. Most shorteners will let you verify the domain ownership immediately even if you don’t activate it until later.
3. Run one campaign through it. Compare CTR against an otherwise-identical campaign on the generic domain. The difference, if any, is your branded-domain dividend in numeric form.

The decision usually isn’t between generic and branded forever. It’s between starting now with the option locked down and starting later when you’ve already given up the brand surface area on a few hundred thousand impressions.

These are operational problems disguised as marketing problems. They all have the same shape: a short link has a longer life than the campaign it was created for, and nobody planned for that.

The model that solves them is small — four verbs that should be first-class operations on every link, not afterthoughts.

Pause

A paused link still exists, still resolves, but no longer redirects to its original destination. Visitors see a clear “campaign ended” or “currently unavailable” interstitial, optionally with a fallback destination (your home page, a related landing page, a “what happened” explainer).

Pausing is different from deleting in three important ways:

1. The slug is reserved. Nobody can register a new link with the same short code while the paused link still owns it. This matters when the link has been printed somewhere — you don’t want a future user to register the same slug and start serving content to your audience.
2. The click history is preserved. A paused link still records clicks, which lets you see when audience interest in a campaign actually dies versus when it dies on the dashboard.
3. The operation is reversible. An unpause restores the redirect. Useful for seasonal campaigns (“relaunch the spring menu link in April”), pricing freezes, regulatory pauses, or emergency rollback.

Pausing should be a one-click operation. Most teams don’t pause links because the tooling makes it too heavy — they either delete (which loses history and frees up the slug) or do nothing (which leaves dead links live).

Route

A routed link sends different visitors to different destinations based on conditions: geography, device, time of day, or weight (A/B split). Same short URL, different real destinations depending on who clicked.

The most common cases:

• Geo routing. A global campaign needs to send EU visitors to a GDPR-compliant landing page and US visitors to a different one. Without routing, you have to publish two different short links and hope marketers paste the right one. With routing, one short link does the dispatch.
• Device routing. A campaign needs to send mobile users to an app-store deep link and desktop users to a web landing page.
• Scheduled routing. A campaign launches at 9am Tuesday. Before 9am, the link points at a “coming soon” page; after 9am, the live destination.
• Weighted routing. An A/B test where 50% of clicks go to variant A and 50% to variant B, with conversion measured downstream.

Routing rules are governance because they let you change the behavior of a link without re-issuing it. The printed material stays the same; the redirect logic adapts. This is the foundation for keeping campaigns alive past their original window.

Expire

An expired link returns a clear “this link has expired” interstitial, permanently. The slug is retired and cannot be reissued; the historical data is preserved.

Expiry is for links that should not come back. Time-boxed campaigns, limited-time offers, regulatory-mandated takedowns, or links whose destinations have been retired for good. The difference from “pause” is finality: a paused link is a maybe, an expired link is a no.

A useful pattern is scheduled expiry: at link creation, set a date after which the link auto-expires. Then forgetting to clean up isn’t a problem — the campaign self-shuts. We see this used heavily for limited-time promotions, beta access links, conference materials, and anything that should die on a known date.

Audit

The audit log answers the question “what happened to this link, and when, and who did it.” Every state change — created, destination updated, paused, resumed, routing rule changed, expired — recorded with timestamp and actor.

The audit log is the quietly important governance feature. It lets you:

• Investigate “wait, who pointed this link at the wrong page?” without resorting to Slack archaeology.
• Comply with regulated workflows where every URL change must be attributable (financial services, healthcare, government).
• Reconstruct campaign timelines after the fact for marketing retrospectives.
• Defend against accusations that the team changed a link to a malicious destination — the log shows what happened and who did it.

The destination-history view — every URL the link has ever pointed to — is the most-used subset of the audit log. We see customers pull it up when they’re trying to figure out whether a partner’s complaint (“the link sent my users to the wrong page on April 12”) is true. Usually the truth is more interesting than either side remembered.

How to roll this out

Most teams have lived with the email-the-link-owner workflow for a while and don’t believe they need governance until they have a near- miss. The minimum useful setup, in roughly the order to add it:

1. Pause everything that’s done. Run a quarterly review: any campaign that’s been “over” for more than a quarter should be paused. This is the highest-value cleanup because the dead links are the ones most likely to cause embarrassment when discovered later.
2. Schedule expiry on new time-boxed campaigns. Going forward, any link tied to a date has an auto-expire set at creation.
3. Adopt routing for anything with multiple destinations. Stop publishing two links for “EU” and “US” versions of the same campaign. One link, one routing rule.
4. Make the audit log discoverable. Show the destination history on every link’s dashboard view. The cost is zero, the upside is that the team learns the feature exists before they need it.

The cultural part

Tooling is the easy part. The cultural change is teaching the team that links are durable infrastructure, not throwaway artifacts. A short URL that ends up on a printed banner has a five-year lifespan; a short URL in an email campaign has a six-month lifespan; even an “internal-only” short URL has the lifespan of every saved bookmark and every shared Slack message.

Treat short links like database rows that are visible to the public: created on purpose, updated through process, retired through process, audited continuously. The governance verbs above are the API; the culture is making sure they get used.

This is a practical walkthrough of the setup: what records to set, what to test, and the five mistakes we see most often in support.

Step 1: Pick the domain

A short domain is a marketing artifact more than a technical one. The traits that matter:

• Short. Three to five characters is ideal. The whole point is brevity; an eight-character domain doesn’t help versus thin.ly/abc1234.
• Memorable. It should be guessable, even by someone who didn’t receive the link.
• Defensible. If you can register the typo variants too (acne.link next to acme.link), do it. Domain squatters will register them for you otherwise.
• TLD recognition. .com, .co, .io and .link all read as legitimate. .click and .xyz carry baggage from spam history and may trigger mail filters and ad-network blocks.

If your primary domain is acme.com, the cleanest options are:

1. A separate apex domain. acme.link, acme.co, or acme-go.com. Clean, brand-aligned, and gives you a clean surface for short URLs that’s separate from your main site.
2. A subdomain of your primary. go.acme.com, s.acme.com, or link.acme.com. Cheaper (no new domain registration), instantly trusted because it’s already on a domain users know, but URLs are longer than a fresh apex.

For B2B audiences, the subdomain option is often preferable because it inherits the existing trust signal from acme.com. For consumer brands, a separate apex usually wins because the shorter total URL matters more.

Step 2: Set up DNS

Once you’ve picked the domain, point it at your shortener. The specific records depend on whether you’re using an apex domain or a subdomain.

Subdomain (go.acme.com)

A subdomain points with a single CNAME record:

go.acme.com.   CNAME   custom.thin.ly.

The CNAME tells DNS resolvers that whenever someone looks up go.acme.com, they should follow the alias to custom.thin.ly and ask for its IP. The shortener’s edge load balancer answers, sees the Host: go.acme.com header on the incoming request, and routes the redirect through your account.

This is the simplest case. The CNAME propagates within minutes for most modern DNS providers, and most shorteners can verify the domain ownership immediately.

Apex domain (acme.link)

Apex domains (the bare domain without a subdomain prefix) can’t be CNAMEs in the original DNS spec — only A records. Two ways around this:

1. A records pointing at the shortener’s IP addresses. The shortener publishes a stable set of IPs that you point your apex at. Simple, but if the shortener changes infrastructure you have to update your DNS.
2. ALIAS / ANAME records (provider-specific). Modern DNS providers — Cloudflare, Route 53, DNSimple, Cloudflare Registrar — support an “ALIAS” record type that acts like a CNAME at the apex. The provider does the lookup server-side and returns the resolved IPs to the client.

If your DNS provider supports ALIAS, use it. If not, use A records and accept that the IPs may change over time.

Typical A record setup:

acme.link.   A     203.0.113.10
acme.link.   A     203.0.113.11

Two records for redundancy.

Step 3: Verify and provision SSL

After DNS propagates, the shortener can verify ownership of the domain (usually by looking up a specific TXT record you publish, or by serving a verification file at a specific path) and provision an SSL certificate.

Almost every modern shortener uses Let’s Encrypt for free certificates, issued automatically once the domain points at their infrastructure. Provisioning takes anywhere from a few seconds to half an hour depending on the provider. You’ll know it’s working when https://acme.link/ loads with a green padlock and no certificate warning.

Common stalls at this step:

• CAA records blocking issuance. If you have a CAA record on your domain restricting which certificate authorities can issue for it, you may need to add an entry for letsencrypt.org.
• DNS not fully propagated. Let’s Encrypt validates the challenge response over public DNS. If your subdomain hasn’t propagated everywhere yet, the validation fails. Retry after fifteen minutes.
• Cloudflare proxy in “Full” mode without a certificate on the origin. If you’re proxying through Cloudflare and the shortener doesn’t have a valid origin certificate, you get a 526 error. Set Cloudflare to “Flexible” SSL, or have the shortener provide an origin certificate.

Step 4: Test the round trip

Once SSL is live, test the full path before you announce the domain. At minimum:

1. HTTPS resolves. Browse to https://acme.link/ and check that the certificate is valid.
2. HTTP redirects to HTTPS. Browse to http://acme.link/ and confirm an automatic upgrade to HTTPS.
3. A test short link redirects properly. Create acme.link/test-1, point it at a known destination, click it, confirm the redirect happens and the destination loads.
4. The root domain does something sensible. Either redirects to your main site, shows a branded landing page, or returns a readable 404. The default for some shorteners is to show the shortener’s brand on your root, which is bad — fix this before anyone notices.
5. WWW does something sensible. www.acme.link either redirects to acme.link or vice versa. Pick one and be consistent.

The five mistakes we see most often

1. Forgetting the apex. Team sets up go.acme.com but doesn’t set up acme.com to redirect to it. Anyone who shortens the domain in conversation (“yeah, go to acme.com slash test”) hits the main site, not the shortener.
2. Not removing the old shortener. Team migrates from a generic shortener to a branded one, but doesn’t update the old campaigns. For weeks, half the audience clicks the old shortened URLs and half clicks the new ones. Plan a transition window and migrate campaigns systematically.
3. Forgetting to renew the domain. A custom short domain that expires breaks every active campaign link instantly. Set up auto-renewal and an internal calendar reminder a month before expiry. Many of the worst short-link incidents we see are self-inflicted via expired domains.
4. Hosting on infrastructure they don’t control. Pointing the domain at a shortener whose plan they’re not paying for, or whose verification has lapsed. The domain works for a while, then stops, often without warning.
5. Not setting up redirects for the bare domain. Browsing to https://acme.link/ returns 404 or a generic shortener home page. This is the single most common visible mistake; it makes the branded domain look broken even though it’s working perfectly for actual links.

A migration checklist

If you’re moving from a generic shortener to a branded one:

• Domain registered with auto-renewal on.
• DNS records set (CNAME for subdomain, A or ALIAS for apex).
• SSL certificate provisioned and valid.
• Root domain redirects somewhere sensible.
• At least three live test links validated end-to-end.
• Existing campaigns inventoried so you know what to migrate.
• Transition window defined; both shorteners live for it.
• Internal calendar reminder set for domain renewal.

Done in that order, the whole setup takes thirty minutes to an hour. Done out of order, it takes a week of intermittent breakage. The checklist is the part to actually keep.

Both are wrappers around a destination URL. Both can be branded, tracked, and updated to point somewhere new without changing the artifact. The difference is the surface they live on.

The surface decides

The question to ask before picking is: how will the user encounter this URL?

The short version: if the user is reading, give them a short link. If they are at arm’s length or farther, give them a QR code with the short link printed underneath as fallback.

When to use both

The “QR code plus short link printed underneath” pattern works because they handle different failure modes:

• The QR code handles the case where the user is on their phone, the lighting is fine, and they want to scan.
• The short link handles the case where the camera fails to focus, the user is on a desktop, the user prefers to type, or accessibility needs make scanning hard.

The fallback short link captures roughly 5-10% of clicks that would otherwise be lost in print campaigns. The cost is one extra line of text underneath the QR code. Always include it.

When the choice changes the campaign

There are a few cases where the choice between QR code and short link genuinely changes campaign behavior:

Indoor versus outdoor. Outdoor QR codes have to deal with weather, glare, and distance. They need to be larger, higher contrast, and absolutely not relied upon as the only entry point. For an outdoor billboard, the short link is often the more important artifact — drivers can read and remember a short URL more easily than they can scan from a moving car.

Hands-free contexts. A podcast host saying “go to acme.link slash launch” requires a short, pronounceable, memorable slug. There is no QR code option in audio. This is the only case where the short link’s slug-readability really dominates the design.

Multi-step conversion flows. If the destination needs the user to fill out a long form, scanning a QR code on a poster is a worse experience than later typing the short URL on their laptop. Print the short URL prominently as a “type this later” option, with the QR code as the “tap now” shortcut.

Privacy-sensitive distribution. Scans don’t leave the device’s clipboard or browser history the way typed URLs do, but they do leave a network trace. For situations where the user is shoulder- surfed or in a monitored network, a typed short link is sometimes less visible than a scan that fires a camera.

What’s the same regardless

The wrappers differ but the operational concerns are the same. In both cases:

• The URL is dynamic — the destination can be changed without reprinting or reshooting the wrapper.
• The clicks are tracked with the same analytics — geography, device, time of day, referrer.
• The link can be paused, expired, or routed by rules.
• The destination can be replaced if it turns malicious or if the campaign migrates to a new landing page.

The wrapper choice is about user experience, not about the underlying machinery.

A simple decision rule

If the answer to “could the user type this URL in five seconds without making a mistake?” is yes, you can lead with the short link. If the answer is no, lead with a QR code and include the short link as fallback. If both are at arm’s length and could go either way, include both side by side. Almost no campaign should include a QR code alone with no readable URL — when the scan fails, the user has no recourse and the campaign goes silent.

The choice gets simpler the more concrete the surface is. Don’t try to pick one wrapper for “the whole campaign.” Pick the wrapper for each surface — poster, email, social, podcast — independently, and let the format decide.