The exchange, step by step
Somebody taps short.bi/spring. Their browser opens a connection and asks for that path.
- The server looks the path up and finds the record holding your destination.
- It records the click along with the country, device, browser and referring site.
- It applies any rules on the link, such as a password, an expiry date or a routing condition.
- It answers with a redirect status and the destination address.
- The browser follows it and loads the real page.
All of that happens in a few milliseconds. From the visitor's side there is one tap and one page.
301 and 302 are not the same promise
A 301 says the move is permanent. Browsers cache it, sometimes for a long time, and search engines pass ranking signals through to the destination.
A 302 says the move is temporary. The browser is told to come back to the short address next time rather than remembering the destination.
For an editable link, temporary is usually the right answer. If a browser has cached a permanent redirect and you then change the destination, that visitor keeps landing on the old page until the cache expires, and you have no way to clear it from their device.
The exception is a genuine permanent move, such as retiring an old address in favour of a new one. There, permanent is what you actually mean.
Why the destination can move
Because the link is a lookup rather than an encoding. The short address contains no information about where it goes. It is a key, and the value behind it is yours to edit.
This is what separates a dynamic short link from a static QR code, where the destination is baked into the pattern. It is also what makes a short link worth using on anything printed, archived or embedded somewhere you cannot go back and change.
The practical consequence: choose an ending that describes the intent rather than the current destination. short.bi/menu still means the menu when the menu moves to a new system.
What gets recorded on the way through
Because the request passes through your account, the click can be counted without anything being stored on the visitor's device.
- Time of the click and the link it belongs to.
- Approximate location, taken from the connection and not from anything left behind on the device.
- Device, browser and operating system.
- Referring site, when the browser sends one.
- Any UTM or query parameters attached to the link.
That is a smaller measurement than page analytics and it comes without a consent banner in front of your visitor, which is a trade most people are happy to make.
The obvious risk, stated plainly
A short link adds one hop between the person and the page. If the shortener disappears, the hop breaks and every link it ever issued stops working.
There is a well known example. The goo.gl service stopped issuing links in 2019 and stopped answering the old ones in 2025, and everything printed against those addresses went with it.
The mitigation is to care about who runs the domain, and to keep the ability to export your links. A shortener you can leave is a very different proposition from one you cannot.
What happens to parameters
Adding ?utm_source=newsletter to a short link is only useful if the parameter survives the redirect. On Digily Link it does, so your destination's analytics see the campaign exactly as it would if you had shared the long URL.
You can also store the parameters on the link itself rather than appending them each time, which means the person sharing it cannot accidentally strip them.
Either way, check once in your own analytics after the first campaign. Parameters going missing between the short link and the destination is the sort of thing that stays invisible for months if nobody looks.