​

Rules, Conditions, and Operators Reference

Rules are evaluated by priority and condition match. They route traffic before fallback behavior.

​

Rule evaluation model

1. Rules are checked in priority order.
2. First matching rule applies.
3. If no rule matches, fallback destination logic applies.

This means priority design is as important as condition design.

​

Rule types

Linquid supports rule types for:

• geography
• device/platform
• time schedule
• referrer/source
• UTM values
• IP and network attributes
• language
• fraud/traffic quality
• ASN/ISP
• headers/cookies
• rate limits/caps
• weighted distribution / percentage tests
• query/path/method/hostname
• visitor state
• nested logic

​

Condition input design principles

• keep condition sets explicit and minimal.
• avoid overlapping broad include and exclude patterns.
• prefer deterministic values over regex when possible.
• document assumptions for high-volume routing rules.

​

Operator behavior

Rules support two operator layers:

• logical operators for nested composition (AND, OR, NOT)
• comparison operators for value matching (equals, contains, membership checks, and related comparisons)

​

Common operator pitfalls

​

Major condition dimensions

​

Geo

• countries, regions, cities, continents
• include and exclude patterns

​

Device and client

• device class (mobile/tablet/desktop)
• OS and browser family
• language and locale signals

​

Traffic source

• referrer source rules
• UTM source/medium/campaign/term/content
• query parameter and path/hostname matching

​

Security and quality

• fraud score thresholds
• VPN/proxy/datacenter/Tor/bot/crawler controls
• visitor caps and cooldown behavior

​

Visitor state

• new vs returning visitor routing
• visit-count thresholds
• first-seen windows

​

Priority and conflict strategy

Recommended ordering:

1. Fraud/security exclusion rules.
2. High-specificity targeting rules.
3. Channel/experiment split rules.
4. Broad fallback-like rules.

When adding a new rule:

1. Identify which existing rule it could overlap.
2. Simulate expected match path.
3. Place at explicit priority.
4. Retest common traffic scenarios.

​

Nested logic patterns

Use nested logic when one flat rule is not enough. Recommended patterns:

1. Gate by geography first.
2. Branch by device/platform second.
3. Apply fraud quality controls before destination.
4. Keep one explicit fallback branch.

​

Rule priority strategy

• low number = evaluated earlier
• specific rules should be above broad rules
• update priorities when adding new broad conditions

​

Safety constraints worth knowing

• regex-based conditions use guarded validation for stability
• reserved internal cookie names are blocked
• condition arrays/fields are size-limited for reliability

​

Operator examples (user perspective)

• Target mobile visitors in one country: device + country condition group.
• Exclude suspicious traffic: fraud thresholds + VPN/proxy/Tor checks.
• Run A/B traffic split: weighted/percentage rule set.
• Return visitors to retention offer: visitor-state rule path.

​

Rule QA matrix

​

Troubleshooting guide

If a rule does not fire as expected:

1. Confirm priority order.
2. Confirm condition field formats.
3. Confirm include/exclude logic does not conflict.
4. Confirm fallback is not catching traffic first.
5. Validate date/time and timezone boundaries.

​

Change management best practices

1. Version high-impact rule sets with change notes.
2. Test in low-risk traffic segment before broad rollout.
3. Monitor top links and conversion trends after deployment.
4. Roll back quickly if anomaly thresholds are crossed.

Related:

• /user-guides/manual/growth/campaigns-links-rules
• /user-guides/manual/data/analytics-and-reporting