Conditions = {metric, operator, value, time_range}. 8 operators + 2 extension trend operators. 6 time ranges. AND / OR logic.

Conditions, operators, time ranges

Conditions are the IF part of an if-then rule. Each condition is a tuple {metric, operator, value, time_range}. Combine multiple conditions with AND (all must match) or OR (any matches). 8 standard operators + 2 trend operators (extensions). 6 time ranges.

Who is this for

Anyone designing a rule beyond a single condition. Reference for the builder's condition row UI.

The condition tuple

A condition has 4 fields:

{metric: "roas", operator: "lt", value: 1.5, time_range: "last_7d"}

In English: "ROAS less than 1.5 over the last 7 days."

Operators (8 standard)

between and not_between take an array of two numbers (inclusive bounds).

Trend operators (extensions, 2)

Behind the Rules Engine extensions feature set. Compare current time_range vs the immediately preceding equal-length period.

Use case: catch performance drift (sudden CPA increase, ROAS collapse) early instead of waiting for absolute thresholds to break.

Time ranges (6)

The window over which the metric is computed. Day-boundary windows follow the rule's own timezone (default Europe/Rome).

Shorter windows = faster reaction, noisier signal. Longer windows = slower reaction, more stable. For postback-fed metrics (purchases / ROAS / CPA): use last_7d minimum to avoid acting on incomplete data (see rul-103).

Combining conditions: AND vs OR

Per rule, choose condition_logic:

• AND — all conditions must match for the entity to qualify
• OR — any one condition matches

AND example (kill losers)

condition_logic: ANDconditions:  - roas lt 1.5 / last_7d  - spend gt 50 / last_7dactions: pause

Pauses only entities with both bad ROAS AND meaningful spend (avoids killing low-traffic tests that haven't proved anything).

OR example (frequency alarm)

condition_logic: ORconditions:  - frequency gt 5 / last_7d  - cpa increased_pct 50 / last_3dactions: notify_only

Alerts on either creative fatigue OR sudden cost spike.

Per-condition entity matching

Each condition is evaluated per entity (campaign / adset / ad depending on level). The rule decides per-entity whether to act. Two different ad sets in the same scope may match differently — that's expected.

Examples

Pause adsets with bad ROAS

metric: roas, operator: lt, value: 1.5, time_range: last_7d

Single condition. Targets adsets where 7-day ROAS dropped below 1.5.

Scale winners with traffic

condition_logic: AND- metric: roas, operator: gt, value: 3, time_range: last_3d- metric: spend, operator: gt, value: 100, time_range: last_3d

Both must match. Excludes hot-but-tiny adsets where ROAS is unreliable due to low volume.

Protect daily spend

metric: budget_spent_pct, operator: gt, value: 80, time_range: today

Fires when more than 80% of today's daily budget is already spent.

Detect performance drift

condition_logic: OR- metric: cpa, operator: increased_pct, value: 30, time_range: last_3d- metric: roas, operator: decreased_pct, value: 20, time_range: last_3d

Trend operators. Alerts on either CPA spike OR ROAS drop vs prior 3-day period.

What you'll see in preview

POST /api/v1/rules/preview returns each evaluated entity with:

• The metric values that the rule computed
• Whether each condition matched (true / false)
• Final match result based on AND / OR logic
• Skip reason if applicable (cooldown active, daily cap, pending action)

Useful for debugging: if a known-bad adset is not matching, preview shows which condition failed and why.

Common mistakes

• AND when you meant OR: condition too strict → no matches. Re-read the logic carefully.
• OR when you meant AND: condition too loose → too many matches. Consider AND or add a spend gt N guard.
• Short time_range on slow metrics: postback metrics need last_7d+. Otherwise rule fires on partial data.
• No spend guard on ROAS / CPA conditions: low-volume entities have wild metrics. Always pair with a spend gt minimum.
• between / not_between with bad array order: must be [min, max]. [30, 10] evaluates wrong.

FAQ

What makes up a rule condition in Wevion?

A condition is a four-field tuple: {metric, operator, value, time_range}. For example {metric: "roas", operator: "lt", value: 1.5, time_range: "last_7d"} reads as "ROAS less than 1.5 over the last 7 days." Each condition is the IF part of an if-then rule, evaluated per entity in scope.

Which operators can I use in rule conditions?

Wevion offers 8 standard operators: gt, lt, gte, lte, eq, neq, between, and not_between. The between and not_between operators take a two-number array [min, max] with inclusive bounds. Two additional trend operators — increased_pct and decreased_pct (extensions) — compare the current time_range against the immediately preceding equal-length period.

What's the difference between AND and OR condition logic?

Per rule you set condition_logic: with AND, all conditions must match for an entity to qualify; with OR, any single condition matching is enough. Use AND to require, for example, both bad ROAS and meaningful spend before pausing. Use OR to alert on either creative fatigue or a sudden cost spike.

Which time ranges can a condition use?

Wevion supports 6 time ranges, with day boundaries following the rule's own timezone (default Europe/Rome): today, yesterday, last_3d, last_7d, last_14d, and last_30d. Shorter windows react faster but are noisier; longer windows are more stable but slower. For postback-fed metrics like purchases, ROAS, and CPA, use last_7d minimum to avoid acting on incomplete data.

Why should I add a spend guard to ROAS or CPA conditions?

Because low-volume entities produce wild metrics. A brand-new ad set with tiny spend can show extreme ROAS or CPA that isn't meaningful. In Wevion, pair any ROAS or CPA condition with a spend gt minimum using AND logic, so the rule only acts on entities that have proven something.

Related articles

• Available metrics for rule conditions
• Actions — what your rules can do
• Preview (dry-run) — test before activating