Geolocation-based dynamic redirection

[tostt]

Summary

Since Shlink provides device-specific redirects, I am wondering if geo-specific redirects would also be within the scope of the application.

Say, for a product page you want customers to be redirected to the website that serves the country (or area) they live in.
For example, Amazon offers the "OneLink" geo-redirection service, but conditions apply.

[acelaya]

There was a similar request recently, that I closed as "not planned". You can see the details #1735

I know you are not requesting exactly the same. Your reasoning makes a bit more sense, but I'm still hesitant due to the complexity to implement something like this.

• During short URL creation/edition you would need to provide the target urls per location. But what is a location. A city? A country? A geofence? A timezone? It's so open that it would require very careful checks and would be very hard to validate.
• What if this is combined with other rules, like device redirections. Which one applies? Or perhaps it should be combined?
• It would require extra conditional checks. What if the GeoLite key was not provided? Should creation/edition fail and force you to provide only a long URL? Should it let it through but redirect to default long URL? What if it is removed after the URL is created?
• What if geolocation is disabled but there are URLs that require it?
• What if geolocation fails or cannot produce an accurate-enough result?
• What if the GeoLite DB has not been downloaded yet? This is usually done in background, but if the redirect depends on it, the end user needs to wait until download finishes.

I'll leave this open, but due to the complexity, I'm going to tag it as a gold feature

[tostt]

Thank you for your answer and comments. Indeed, this can be a complex subject.
The way you describe all possible issues is definitely valid.

Another way to see things could be the following: if anything goes wrong, log the problem as a configuration warning and redirect to a default ("catch-all") URL. That's already the behaviour for device-specific redirects and, as a worst-case scenario, I think it's great. I believe that the most relevant way to geo-redirect is by country, but that's debatable.

I don't feel the app needs to cater for each and every thing which can go wrong. But of course, it's your project and your decisions. I hope you don't feel I'm making this a big deal. I am extremely satisfied the way the app is.

[acelaya]

Thanks for the feedback.

I believe that the most relevant way to geo-redirect is by country, but that's debatable.

Yeah, my main concern is that any feature makes people ask for the next thing.

I could just decide it's going to be countries, but people will ask for cities, geofences, etc., etc.

Much like adding device-specific redirects is making people ask for geolocation redirects :P

[martyp187]

I got here by searching for this feature and found this.

This feature was something I was hoping for to make the use case for a sovereign self-hosted/owned solution vs the paid options.

I agree with Tostt. This feature, much like the 'devices' would be a 'best effort' improvement.

A user will end up at the 'normal url' unless a match to the country location is found / possible.

[acelaya]

I'm thinking on removing the gold label from this issue, as this is now a bit easier to implement after the new dynamic rule-based redirects introduced in Shlink 4.0.0

Some of the points I mentioned in #1774 (comment) are still valid though, so I'm going to elaborate on them here.

• During short URL creation/edition you would need to provide the target urls per location. But what is a location. A city? A country? A geofence? A timezone? It's so open that it would require very careful checks and would be very hard to validate.

Redirect rules and conditions should allow to cover this nicely. It would even be possible to add all of the above as different types of conditions.

The tricky part is validating the values though. If the condition is "City", what should be the value? It sadly requires to know the naming convention used by GeoLite2, and could potentially break if they change it, or if GeoLite2 is eventually replaced with something else.

• What if this is combined with other rules, like device redirections. Which one applies? Or perhaps it should be combined?

This is covered by the dynamic rule-based redirects system, is it allows you to define priorities and combine conditions as desired. Scratching out.

• It would require extra conditional checks. What if the GeoLite key was not provided? Should creation/edition fail and force you to provide only a long URL? Should it let it through but redirect to default long URL? What if it is removed after the URL is created?

Dynamic rule-based redirects define a general behavior here. During short URL creation/edition, Shlink would not check if the GeoLite2 key/database file is present, and just let the config go through.

During a visit, if the visitor could not be geolocated for whatever reason (missing key, missing GeoLite2 db, missing IP address, geolocation disabled, geolocation not precise enough, etc.), the rule would be considered not matched and that's it.

This is a bit controversial though, as it can be a slightly unintuitive behavior, making people report issues, and having to drive them over some kind of debugging process to verify if any of the situations mentioned above has happened.

• What if geolocation is disabled but there are URLs that require it?
• What if geolocation fails or cannot produce an accurate-enough result?
• What if the GeoLite DB has not been downloaded yet? This is usually done in background, but if the redirect depends on it, the end user needs to wait until download finishes.

These three points are covered by the comment above.

[acelaya]

For those interested in this, please vote/comment here #2101