Conditions and operators

A condition in AdOps is four choices: a metric, the reporting period to read it over, a comparison operator, and a value. Every condition in a task is joined by that task’s single AND or OR pill, and the task’s action runs only when the joined result is true.

What does one condition look like?#

{
  "metric_key": "purchase_roas.omni_purchase",
  "period": "last_7d",
  "operator": "LESS_THAN",
  "value": "1.2",
  "compare": "value"
}

Read aloud: when Purchase ROAS over the last 7 days is below 1.2, this condition passes.

Which operators are available?#

Operator	Symbol	Menu label
GREATER_THAN	>	greater than
LESS_THAN	<	less than
GREATER_THAN_EQUAL	≥	greater than equal
LESS_THAN_EQUAL	≤	less than equal
EQUAL	=	equal
NOT_EQUAL	≠	not equal

Forty-three of the 45 metrics expose all six. The two time-of-day metrics are the exception: Time greater than offers only GREATER_THAN, and Time less than only LESS_THAN.

Which reporting periods can I choose?#

Value	Label
today	Today
yesterday	Yesterday
custom_last_3_days	Last 3 days (incl. today)
last_3d	Last 3 days
custom_last_7_days	Last 7 days (incl. today)
last_7d	Last 7 days
last_14d	Last 14 days
last_30d	Last 30 days
this_month	This month
last_month	Last month
maximum	Lifetime

The plain presets are passed straight to Meta as a date_preset. The two custom_ forms are rewritten locally into an explicit time_range whose window ends today, which is why they are labelled “incl. today”.

Six of the 45 metrics have no period at all — Daily Budget, Lifetime budget, Remaining budget, Hours since creation, Time greater than and Time less than are point-in-time readings.

Comparing a metric against another metric#

Every condition row carries a Compare With cog. Switching it from Value to Metric replaces the number on the right-hand side with a second metric that has its own metric key and its own reporting period. The engine resolves that second metric and multiplies your entered value by it, writing the resulting threshold back onto the condition record as custom_value.

That turns fixed thresholds into relative ones: “spend more than 2× last-7-day revenue” instead of a currency amount that goes stale.

Note the cost. The compared metric is fetched with its own separate Graph call, so each metric-to-metric condition adds one API round trip per campaign.

Time and age conditions#

Time greater than and Time less than compare the current hour against a value chosen from a 24-hour list running 12:00 AM to 11:00 PM. The comparison is inclusive at the boundary, so the named hour itself always passes. Each of these conditions also accepts a day-of-week multi-select, listed Sunday first; when today is not in that list the condition fails.

Hours since creation converts a campaign’s creation timestamp into whole elapsed hours, rounded up. Pair it with any action to keep automation off campaigns that are still too young to judge.

How conditions shape the API call#

Before evaluating a campaign, AdOps groups every condition by its period, takes the part of each metric key before the first dot as the Insights field, de-duplicates that list, and issues one batched Graph request covering every period the rule needs. Metrics that are not Insights fields — the time metrics, custom metrics, Daily Budget, Hours since creation and the two custom budget metrics — are excluded from that fetch and resolved separately.

A rule comparing today against the last 7 days and the last 30 days therefore costs one request, not three. Adding conditions is cheap; adding metric-to-metric comparisons is not.

Practical limits#

Keep the condition set small enough to read in one breath. Every condition is stored with the actual value the engine saw and a Pass or Fail badge in the execution log, so a five-condition task is five lines to check when something surprises you.