[FEAT] Support the ability to provide an expired link value
Closed this issue · 8 comments
I am looking for a new feature to be created which would allow a user to define an expired link value at a project level and at a link level in Dub.
Problem
The problem that this addresses is that the current behavior of an expired link is not customizable, and it yields an unsettling user experience for users passing through an expired link.
Example: https://trynw.co/QXHOZzg, which will send you to here:
This destination has nothing to do with the intended site and is completely outside of the users control.
Proposed Solution
Allow a user to define an expired link default at the project level. For me, this would be https://www.trynow.com/shopper most likely. This puts a user into a familiar destination and allows us to offer links to helpful content that may assist the user and keeps us in control of the destination. This acts as a generic fallback.
Further, allow a user to define an expired link at the link level that overrides the project level default. This can then be used to provide an extremely precise fallback destination when a link expires. I do not think there is a need to provide an example of how this is helpful (let your imagination run wild), but to do so, consider something like a magic authentication link that signs someone into an app. The normal destination before expiring would be the app itself. The expired destination may be a parameterized URL containing things like the username, link expiration time, etc and send the user to a fallback page that says something like:
Sorry, [username]. This link expired at [expiration time]. To try again, click here [restart href].
I am not intending to use this for auth purposes, but you get the idea. You can stuff as much data into that link as you want to customize the display in your fallback destination.
@steven-tey is it okay with you if I implement this?
@versecafe would love to hear what you have in mind for the implementation! 👀
@steven-tey When making a link and setting an expiration have an optional field for fallback URL after expiration.
For where to set the general fallback there is no great option, if done at an org level under [org]/settings general it works but it's a little out of place and would it be one general or per domain, and on the other hand putting it with the domains section, how would fallbacks for the dub domains including spt, amzn, etc then have default fallbacks set for them. Not sure what the best way to go about that would be.
Only adding opinion because I asked for the feature, but feel free to ignore: the setup that makes sense to me is to have a nullable fallback option at the domain level just like the fallback option on links themselves should be nullable. I don't think you can sanely have an org level default fallback because you may be managing a plethora of domains that have nothing to do with each other, but maybe I am not thinking about this from an enterprise perspective. Regardless, the domain-level fallback seems like an immediately tenable use case.
By allowing them to be nullable regardless of the level, you don't have to set defaults for anyone. They can use it if they would like to do so, or just leave it be and hit the default Dub fallback page. Granted, I have no knowledge of the example domains given and how Dub supports them, but optional new stuff is almost always met with happier users than mandatory new stuff or best effort guesses that then affects traffic 🙂
You have a point domain level fallback default makes a lot more sense then org level, since many companies would have multiple domains under their account, and optional nullable works, less setup for users, but there if they want it.
Yeah makes sense, was debating between workspace-level vs domain-level, but agree that domain-level seems more intuitive! Will account for that in the PR.
Publishing the changelog tomorrow, but in the meantime, this is shipped!
Feel free to refer to this help article to learn more: https://dub.co/help/article/link-expiration#setting-a-custom-expiration-url