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 would not 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]

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.

[voidspark99]

Browser

This is an excellent feature. I would also add user-agent based redirect.
Use case: we have a site that only works in Microsoft Edge on iOS. We have a redirect (via QR code), where the long URL start with microsoft-edge-https://, and this opens MS Edge if Safari or Firefox is the default browser.
However, MS Edge itself is so stupid that it would show a blank page. So, we'd use https as protocol if the agent is Edge.
I can also imagine other similar use cases.

[acelaya]

By re-reading this I think this could be made more concrete by saying you need to identify the device OS (which will be covered by #2101 (comment) but particularly for mobile devices is already supported) and the specific browser.

Since the only missing piece is the second, I'm going to rename this from "user agent", which is a bit too abstract, to "browser" (Edge, Firefox, Chrome, Safari, etc.)

Then you would be able to achieve what you describe here by creating a rule with two conditions, one for "device=ios" and one for "browser=edge".

[acelaya]

Operating system

This would be an extension of the existing device condition, but with new possible values:

• Windows
• Linux
• Mac
• ...

More context can be found in this issue.