New conditions for dynamic rule-based redirects

[acelaya]

Now that Dynamic rule-based redirects are implemented with support for language, query-param and device-type conditions, I'm looking for new condition types that would be useful for this system.

I thought about a few, but I want to hear ideas as well, so feel free to just vote here or post comments.

TL;DR

I was going to create a poll, but it's a bit limiting because:

• People won't be able to vote for more than one option.
• Some of them require clarifications, but poll options are one-liners.
• I want people to be able to add more options that can be voted.

Because of that, I'm going to add every option as a comment here, and expect people to react with 👍🏼 to those that seem useful.

If you want to comment on any of those, add a reply to that comment as a thread. If you want to suggest new options, add a new top-level comment.

[acelaya]

City/country (geolocation-based)

Geolocation conditions seem like an obvious useful addition. I didn't add it to the initial implementation because it has a lot of considerations, and I wanted to avoid confusions and people reporting issues which are actually implicit limitations.

You can see those considerations in this comment.

[acelaya]

Date (before, before or at, after, after or at)

These should be easy to implement. They would be 4 different conditions and users would just need to set the date representing the limit.

[acelaya]

A/B testing

It feels like the dynamic rules-based redirection system should be a good foundation to support A/B testing in Shlink.

However, rules are currently evaluated in order of priority, while in A/B testing, rules have a porcentual probability to match, so the system implementation would need some adjustments.

Also, in A/B testing, once a "user" has matched a specific path, they should consistently continue matching it, which would require some way to identify returning visitors (cookies or something like that).

More context can be found in this issue.

[acelaya]

Originally posted by @Moongazer

---

@acelaya First of all, thank you so much for your great software and especially being open for useful improvements and features - we highly appreciate that, because that's not always the case in other projects which reached a "kind of final state"! 🙏🏼

Also, in A/B testing, once a "user" has matched a specific path, they should consistently continue matching it, which would require some way to identify returning visitors (cookies or something like that).

That's true, good point! I'd say that with a cookie it shouldn't be that difficult to implement, if the cookie's value contains all information which Shlink needs to perform the same redirect again (so no session management is needed on server side).

First consideration: depending on the overall "dynamic rules-based redirection" implementation, there might be some rule-cases in the future (beside AB-testing), where also prior redirect information are needed to perform the same decision again.
If that might be the case, I'd create the cookie value/payload in a generic way. Means, that such a cookie is able to store a certain payload for a certain rule (so that cookie can be re-used for multiple rules if needed). Usually I use a serialized JSON string (sometimes BASE64 encoded or even encrypted to hide the payload information), adding a HMAC to protect against payload manipulation. But that's extra sugar.

Possible Shlink settings for such a cookie:

• Enable dynamic-rule cookie: yes/no, because one might decide to not set a cookie because of GDPR regulations or complaint rules. For sure, in case of "not enabled" a little warning has to be displayed, or example that remembering prior decisions of AB-rules will not work
• Cookie lifetime: e.g. default set to 30 days, but possible to overwrite (0 = session cookie)

Second consideration:
Lets say we have a "remember prior redirect decisions" implementation, e.g. similar like the proposal above. For the AB-test rule, probably we'd need only the following information as payload:

• Short-URL record ID (or the short-code itself, but the ID is probably more reliable since the code might be edited after cookies are set on clients)
• AB-Test target-URL ID

If these both information are available and valid on a request with cookie set, the redirect can be executed immediately. A PSR-15 middleware could be responsible for that (not sure how Shlink works internally tho). If there is a chain of more rules, probably it shouldn't be by-passed. Here the whole concept needs to be more defined.

[acelaya]

IP address

Redirect to different places based on the visitor's IP address, with support for IP ranges, subnets, wildcards, etc.

Originally requested in #2120
Rough implementation: #2121

[nwalke]

Would also ask that this take X-Forwarded-For into consideration, looks like the "rough implementation" did this already. Just wanted to call it out!

[acelaya]

Yes, definitely. The mechanisms to determine the visitor's IP have been there since forever, to be used in the context of geolocation.

This rule would use the same IP address resolved for that purpose, which already takes into consideration several common headers where the IP address can be present.

See https://github.com/shlinkio/shlink/blob/6836840746669deeb2c3135c60b76195969ecb51/config/autoload/client-detection.global.php