Conditional redirect rules engine

Quickleap’s rules engine enables intelligent, conditional redirects based on visitor attributes. Route traffic dynamically based on location, device, browser, time of day, and more.

Overview

Rules allow you to override the default redirect destination based on conditions you define. When a visitor matches a rule’s conditions, they are redirected to the rule’s destination instead of the default.

Rules are evaluated in priority order. The first matching rule is applied, so rule ordering matters.

Rule types

Quickleap supports three types of redirect rules:

Force redirect

When conditions match, always redirect to the specified destination URL.

Percentage redirect

When conditions match, redirect a percentage of matching traffic to the specified destination.

A/B experiment

When conditions match, split traffic between multiple variants with specified percentages.

Force redirect

The most common rule type - when conditions are met, visitors are redirected to a specific destination. Example use case: Redirect mobile visitors to a mobile-optimized site

{
  "type": "force",
  "action": {
    "type": "redirect",
    "url": "https://mobile.example.com"
  }
}

Percentage redirect

Redirect a percentage of matching traffic to an alternative destination, while the rest goes to the default. Example use case: Send 20% of US traffic to a beta version

{
  "type": "percentage",
  "action": {
    "type": "percentage_redirect",
    "url": "https://beta.example.com",
    "percentage": 20
  }
}

The remaining percentage (80% in this example) continues to the default redirect destination.

A/B experiment

Split traffic between multiple variants for testing and optimization. Example use case: Test three different landing pages equally

{
  "type": "ab_experiment",
  "action": {
    "type": "ab_test",
    "variants": [
      {
        "name": "Control",
        "percentage": 33,
        "url": "https://example.com/control"
      },
      {
        "name": "Variant A",
        "percentage": 33,
        "url": "https://example.com/variant-a"
      },
      {
        "name": "Variant B",
        "percentage": 34,
        "url": "https://example.com/variant-b"
      }
    ]
  }
}

For A/B experiments, variant percentages must sum to 100.

Conditions and attributes

Rules are triggered when visitor attributes match your defined conditions. Quickleap provides extensive attributes across multiple categories.

Geographic attributes

Country

Type: String
Operators: equals, not_equals, in, not_inMatch visitors from specific countries using ISO country codes.Example: Route UK visitors to a UK-specific site

{
  "attribute": "country",
  "operator": "equals",
  "value": "GB"
}

Region

Type: String
Operators: equals, not_equals, contains, in, not_inMatch visitors from specific states, provinces, or regions.Example: Target California visitors

{
  "attribute": "region",
  "operator": "equals",
  "value": "California"
}

City

Type: String
Operators: equals, not_equals, contains, in, not_inMatch visitors from specific cities for hyper-local targeting.

Device attributes

Device type

Type: String
Operators: equals, not_equals, in, not_inMatch based on device category (desktop, mobile, tablet).Example: Redirect mobile users to a mobile app

{
  "attribute": "device_type",
  "operator": "equals",
  "value": "mobile"
}

Device brand

Type: String
Operators: equals, not_equals, in, not_inMatch specific device manufacturers (Apple, Samsung, Google, etc.).

Device model

Type: String
Operators: equals, not_equals, contains, in, not_inMatch specific device models for precise targeting.

Browser attributes

Browser name

Type: String
Operators: equals, not_equals, in, not_inMatch visitors using specific browsers (Chrome, Firefox, Safari, Edge).Example: Send Safari users to a Safari-optimized page

{
  "attribute": "browser_name",
  "operator": "equals",
  "value": "Safari"
}

Browser version

Type: String
Operators: equals, not_equals, greater_than, less_than, containsMatch specific browser versions for compatibility handling.

Operating system attributes

OS name

Type: String
Operators: equals, not_equals, in, not_inMatch visitors by operating system (Windows, macOS, iOS, Android, Linux).

OS version

Type: String
Operators: equals, not_equals, greater_than, less_than, containsMatch specific OS versions for version-specific routing.

Traffic source attributes

Referrer

Type: String
Operators: equals, not_equals, contains, not_contains, starts_with, ends_withMatch based on the full referring URL.Example: Route traffic from a specific campaign

{
  "attribute": "referrer",
  "operator": "contains",
  "value": "facebook.com"
}

Referrer domain

Type: String
Operators: equals, not_equals, in, not_inMatch based on just the referring domain for simpler rules.

Time-based attributes

Hour of day

Type: Number (0-23)
Operators: equals, not_equals, greater_than, less_than, betweenMatch based on the hour of day (in UTC or visitor’s timezone).Example: Route differently during business hours

{
  "attribute": "hour_of_day",
  "operator": "between",
  "value": [9, 17]
}

Day of week

Type: Number (0-6, where 0 is Sunday)
Operators: equals, not_equals, in, not_inMatch based on the day of the week.Example: Weekend-specific routing

{
  "attribute": "day_of_week",
  "operator": "in",
  "value": [0, 6]
}

URL attributes

URL path

Type: String
Operators: equals, not_equals, contains, starts_with, ends_with, regexMatch based on the URL path being visited.

Query parameter

Type: String
Operators: equals, not_equals, contains, exists, not_existsMatch based on specific query parameter values.Note: Requires param field to specify which parameter to check.Example: Route based on UTM source

{
  "attribute": "query_param",
  "operator": "equals",
  "param": "utm_source",
  "value": "email"
}

Technical attributes

Language

Type: String
Operators: equals, not_equals, contains, in, not_inMatch based on browser language preferences.

User agent

Type: String
Operators: contains, not_contains, regexMatch based on the raw user agent string for advanced detection.

IP address

Type: String
Operators: equals, not_equals, ip_rangeMatch based on visitor IP address or IP ranges.

Operators

Operators define how to compare attribute values:

Comparison operators

equals: Exact match
not_equals: Does not match
greater_than: Numeric greater than
less_than: Numeric less than
greater_equal: Numeric greater than or equal
less_equal: Numeric less than or equal
between: Numeric value within a range (requires two-value array)

String operators

contains: String contains the value
not_contains: String does not contain the value
starts_with: String begins with the value
ends_with: String ends with the value
regex: Matches a regular expression pattern

Array operators

in: Value is in the provided array
not_in: Value is not in the provided array

Existence operators

exists: Attribute is present
not_exists: Attribute is not present

Special operators

ip_range: IP address is within a CIDR range

Combining conditions

Rules can have multiple conditions combined with logical operators.

Condition logic

AND logic
OR logic

All conditions must match for the rule to trigger.Example: Mobile users from the US

{
  "conditionLogic": "AND",
  "conditions": [
    {
      "attribute": "device_type",
      "operator": "equals",
      "value": "mobile"
    },
    {
      "attribute": "country",
      "operator": "equals",
      "value": "US"
    }
  ]
}

Any condition can match for the rule to trigger.Example: Traffic from US or Canada

{
  "conditionLogic": "OR",
  "conditions": [
    {
      "attribute": "country",
      "operator": "equals",
      "value": "US"
    },
    {
      "attribute": "country",
      "operator": "equals",
      "value": "CA"
    }
  ]
}

For more complex logic combining AND and OR, use the in operator with an array of values.

Rule priority and ordering

Rules are evaluated in priority order, and the first matching rule is applied.

Rules are ordered by priority number (lower numbers = higher priority)
The redirect engine evaluates rules from highest to lowest priority
When a rule’s conditions match, its action is applied immediately
No further rules are evaluated after a match
If no rules match, the default redirect destination is used

Carefully order your rules. A broad rule with high priority will prevent more specific rules from ever triggering.

Reordering rules

You can change rule priority at any time:

Navigate to your redirect’s rules
Drag and drop rules to reorder them
Changes are saved automatically
New priority order takes effect immediately

Rule status

Each rule can be in one of three states:

Active

Rule is evaluated and applied to matching traffic.

Inactive

Rule is skipped during evaluation. Use for temporary disable.

Draft

Rule is being configured and not yet evaluated. Safe for testing.

Time-based rules

Rules can be scheduled with start and end dates:

Start date: Rule becomes active at this date/time
End date: Rule becomes inactive at this date/time
Both dates are optional
Useful for time-limited campaigns or seasonal routing

Example: Holiday campaign redirect

{
  "name": "Holiday Campaign 2026",
  "startDate": "2026-11-25T00:00:00Z",
  "endDate": "2026-12-26T23:59:59Z",
  "conditions": [...],
  "action": {
    "type": "redirect",
    "url": "https://example.com/holiday-sale"
  }
}

Testing rules

Quickleap provides a rule testing tool to verify rule logic before activating:

Navigate to your redirect’s rules
Click Test Rules
Enter user attributes to simulate (country, device, browser, etc.)
See which rule would match and where traffic would be redirected
Adjust conditions or priority as needed

Test your rules thoroughly before activating them to ensure they behave as expected.

Rule analytics

Track rule performance with dedicated analytics:

Hit count: Total hits for each rule
Match percentage: What percentage of traffic matches each rule
Total rules: Number of active, inactive, and draft rules
Rule comparison: Compare performance across rules

Rule analytics help you optimize your routing strategy and identify underperforming or overlapping rules.

Common use cases

Mobile-optimized routing

Scenario: Send mobile users to a mobile-specific site

Type: Force redirect
Condition: device_type equals “mobile”
Action: Redirect to mobile.example.com
Logic: AND

This ensures mobile users get an optimized experience.

Geographic localization

Scenario: Route users to country-specific sitesCreate multiple rules with different priorities:

UK visitors → uk.example.com
DE visitors → de.example.com
FR visitors → fr.example.com
Everyone else → default destination

Each rule uses country equals condition.

A/B testing landing pages

Scenario: Test three landing page variants equally

Type: A/B experiment
Conditions: None (test all traffic)
Variants:
- Control: 33% → example.com/control
- Variant A: 33% → example.com/variant-a
- Variant B: 34% → example.com/variant-b

Gradual rollout

Scenario: Roll out new site to 10% of traffic, gradually increasing

Type: Percentage redirect
Conditions: None (applies to all)
Percentage: Start at 10%, increase weekly
Action: Redirect to new-site.example.com

Update percentage as confidence grows.

Business hours routing

Scenario: Route to live chat during business hours, contact form otherwise

Type: Force redirect
Conditions:
- hour_of_day between 9 and 17 AND
- day_of_week not in [0, 6] (not weekend)
Action: Redirect to example.com/chat
Logic: AND

Traffic outside these conditions goes to default contact form.

Campaign-specific landing pages

Scenario: Route traffic from email campaigns to dedicated landing page

Type: Force redirect
Condition: query_param utm_source equals “email”
Action: Redirect to example.com/email-landing

Requires query forwarding enabled to preserve UTM parameters.

Best practices

Start simple

Begin with simple single-condition rules. Add complexity only when needed.

Use descriptive names

Name rules clearly to understand their purpose at a glance: “Mobile users to app” instead of “Rule 1”.

Test before activating

Always use the rule tester to verify logic before setting rules to active status.

Monitor analytics

Track rule hit counts to ensure rules are matching traffic as expected.

Order carefully

Place specific rules before broad rules to prevent unintended matches.

Use draft status

Set rules to draft while configuring to avoid accidental activation.

Document complex rules

Use the description field to explain the purpose of complex rule configurations.

Review regularly

Periodically review rules to remove outdated or low-hit rules.

Get Started

Core Features

Guides

Documentation Index

​Overview

​Rule types

Force redirect

Percentage redirect

A/B experiment

​Force redirect

​Percentage redirect

​A/B experiment

​Conditions and attributes

​Geographic attributes

​Device attributes

​Browser attributes

​Operating system attributes

​Traffic source attributes

​Time-based attributes

​URL attributes

​Technical attributes

​Operators

​Comparison operators

​String operators

​Array operators

​Existence operators

​Special operators

​Combining conditions

​Condition logic

​Rule priority and ordering

​Reordering rules

​Rule status

Active

Inactive

Draft

​Time-based rules

​Testing rules

​Rule analytics

​Common use cases

​Best practices

Start simple

Use descriptive names

Test before activating

Monitor analytics

Order carefully

Use draft status

Document complex rules

Review regularly

Build docs developers (and LLMs) love

Overview

Rule types

Force redirect

Percentage redirect

A/B experiment

Conditions and attributes

Geographic attributes

Device attributes

Browser attributes

Operating system attributes

Traffic source attributes

Time-based attributes

URL attributes

Technical attributes

Operators

Comparison operators

String operators

Array operators

Existence operators

Special operators

Combining conditions

Condition logic

Rule priority and ordering

Reordering rules

Rule status

Time-based rules

Testing rules

Rule analytics

Common use cases

Best practices