Back to help
09

Smart routing and targeting

Dynamic rules let one short link lead to different destinations depending on visitor context. A link can route by country or region, browser language, iOS, Android or desktop device, browser family, date, time of day, random A/B distribution, or fallback availability when the main page is unhealthy. Rules can be created, edited, disabled, reordered by priority, and deleted from the link settings area.

Routing rules and A/B testing

Open the link card → «Settings» → «Dynamic redirect rules». The rule selects the target URL based on request characteristics, time and weight. It does not permit access contrary to password, time limit, or other link restrictions.

Create a rule

Fill in the name, full target address and priority, then the required conditions. Enable the rule and save. Through the line menu you can edit, temporarily disable or delete a rule. Maximum - 100 rules per link; name - up to 128 characters.

Field — Condition and example Priority — The smaller number is checked first. Acceptable is 0–1,000,000. Countries — Codes separated by commas, for example DE,AT. Regions — Region codes transmitted by the service infrastructure, for example BE. Browser languages — For example ru,en,de-DE. The language of the site and the language of the visitor’s browser are different settings. Devices — ios,android,desktop,mobile,tablet,bot,unknown. Use technical meanings without translation. Browsers — For example Chrome,Safari; case is not important. Date from/to UTC — Period of validity of the rule. The end point is not included. Time from/to UTC — Daily interval. Please fill out both fields. The interval may cross midnight, for example 22:00–06:00. Traffic weight — Integer 1–10,000 to distribute among eligible options of the same priority; an empty field means no weight. Fallback — Use the rule as a fallback if there is a known problem with the main target URL.

An empty condition does not restrict visitors on this basis. Values ​​within one list are combined using “OR”, different filled fields are combined using “AND”. For example, DE,AT and de and desktop indicate a German-language desktop browser from Germany or Austria.

Selection order

• The service considers the included rules that match the dates, times and characteristics of the request.

• If a freshly saved health check reports a supported problem for the target URL, an appropriate fallback rule can be selected.

• Among the normal rules, the first matching priority is used.

• If this group has rules with weights, the choice is made between them in proportion to the weight. Suitable rules without weight are not included in this group.

• If the rule is not selected, the main target URL of the link is used.

For a 50/50 test, create two matching rules with the same priority and weights 1 and 1. For 80/20 - 4 and 1. Equal priority without weights does not by itself create an A/B test.

Weighted selection is stable for a combination of short code, IP address and User-Agent. Refreshing the page repeatedly as the same visitor does not have to show different variants. Small samples need not match the configured proportions exactly. Switching networks or browsers can change the variant, as can changing the rules or their weights.

Country and region come from headers supplied by the service infrastructure; the service does not promise to determine location from every IP address. Missing country data uses ZZ, missing language uses und, and a missing region is left empty. Device and browser detection uses User-Agent and can be inaccurate or spoofed. Test requests with unknown attributes as well, and keep the primary destination available.

Before starting, use routing simulator: it will show the result of the selection without test clicks and spending the limit.

Complete user guide ยท Practical course

How to apply this section

Each topic explains a feature, the user decision behind it, and how to use it without making the link harder to manage. Read the checklist before changing a link that is already shared.

Before you publish or update

  • Start from the visitor experience: who opens the link, from where, on which device, and what should happen next.
  • Check that the destination is correct, opens quickly, and shows the expected page for the intended audience.
  • Choose only the controls that match the goal, such as expiration, password, referrer, QR design, UTM, routing, or analytics sharing.
  • Save a short note for important changes so future review, rollback, or teamwork stays clear.
  • Open the short link in a private browser session and, when relevant, test mobile, desktop, QR scan, and protected access paths.
  • Review analytics after sharing to confirm real visitors, source quality, device mix, and campaign performance.

Practical example

Example: create a test link for an internal page, add a clear slug, set a short expiration, enable preview if the destination is sensitive, scan the QR code from a phone, then check whether the visit appears in the link statistics.

Next step

After this topic is clear, combine it with one adjacent feature. For example, pair UTM with campaigns, QR with print layouts, targeting with fallback, or webhooks with conversion tracking.