| I think our company has a policy against using shortened URLs, namely because: - If the company goes out of business, then our documentation and business logs have a lot of dead, useless links that can't be fixed after the fact. If it's a business critical use case, then you just shot yourself in the foot. - Related to the above, it's not human-parseable. If you're on a mailing list and you send out a hyperlink, you don't immediately know if it's relevant to you and have to scan the rest of the text for context. - It's an unnecessary abstraction on top of perfectly good HTTP URIs, that couples an Internet-scale protocol to one particular company and its closed-source parsing logic. I also don't get how this is product is "sticky" / won't be cut at the first sign of a recession, how much overhead larger companies really have in maintaining such an internal tool (I would think you make something like bit.ly once and keep extending the suffix length by changing one number in a conf file), why smaller companies might need this (I think larger companies just track everything because human analytics at scale might have business value), and how it's different from other solutions on the market. |
The second, our links are actually more human-parsable. go/customer-feedback is much more readable than https://docs.google.com/d/document/ABCDE1234/. You actually wouldn't know if the google doc is relevant without opening it. This might be surprising, but many companies with a similar system actually don't maintain them very well. It works the first time when a tools team builds it, but when those engineers leave the company, new engineers will either try to revive the old system, or rewrite the entire system from scratch to maintain it. We continue to improve the product over time with customer feedback and can provide analytics for the most common links used in the company.
There currently isn't a solution specifically solving these issue on the market today.
Hope this helps!