Feature
Meta Ads rule automation, condition by condition
An AdOps rule pairs conditions on live Meta Ads metrics with an action the engine executes on your campaigns. Each rule targets campaigns or ad sets, combines its conditions with a single AND or OR across six operators, and writes an evidence row for every campaign it evaluated, changed or not.
Conditions on live Meta metrics paired with actions the engine executes on your campaigns, with an execution log behind every run.
In numbers
The figures behind this feature
- Dispatch interval
- Every 10 seconds Cron sweep with overlap prevention, so one tick never re-enters a sweep already running
- Comparison operators
- 6 greater than, less than, greater than or equal, less than or equal, equal, not equal
- Targeting levels
- 2 Campaigns and ad sets
- Pre-filter fields
- 3 campaign.id, campaign.name, campaign.effective_status
- Queue fan-out
- 1 job per ad account Enqueued onto a Redis-backed BullMQ queue named facebook_queue
- Entity fetch retries
- 3 total attempts Waits 1 second, then 2 seconds, before skipping that ad account
Sample data AdOps automates Meta Ads through rules you write yourself. A rule pairs conditions on live campaign metrics with an action AdOps executes against Meta’s Graph API. Each rule targets campaigns or ad sets, combines its conditions with AND or OR, and writes an evidence row for every campaign it evaluated, whether or not anything changed.
What is an AdOps rule made of?
A rule carries a name, the ad accounts it covers, a level, a set of pre-filters, a schedule, and a list of tasks. The rule builder hints that you select up to 5 ad accounts per rule.
A task is the working unit. Each one holds a single action, its own condition set, and an optional cooldown. Because tasks live in an array, one rule can encode a whole playbook instead of forcing you to create three rules that fight each other. A rule sits in DRAFT until you set it live, and only ACTIVE rules are ever picked up by the dispatcher.
How do conditions combine?
Every condition is four things: a metric, a reporting period, an operator, and a value. AdOps ships 45 Meta Ads metrics and 11 reporting periods, so Purchase ROAS over Last 7 days is one condition and Spend over Today is another.
Six operators are available on each condition.
| 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 |
The conditions inside one task are combined by a single group operator, AND or OR, which you toggle by clicking it. A condition’s right-hand side is normally a number, but switching its compare mode to metric lets you test one metric against another, each with its own reporting period.
Which campaigns does a rule touch?
Two things decide that. First the level, which is either campaign or adset. Second the pre-filters, which run before any metric is read.
| Pre-filter field | Operators | Values |
|---|---|---|
campaign.id | equal, not equal | a campaign ID |
campaign.name | contains, does not contain | free text |
campaign.effective_status | is, is not | ACTIVE, PAUSED |
As you change the level or the filters, the builder calls the estimate endpoint after a 500 ms debounce and shows an Estimated match: N Campaigns readout, with a per-account breakdown on hover. You see the blast radius before the rule is live.
What happens between the tick and the action?
The engine is split into a producer and a worker so that the part deciding what to run is not the part allowed to change anything.
- A cron sweep fires every 10 seconds and selects every
ACTIVErule whose next execution time has passed and whose date window is open. The cron is configured with overlap prevention, so a slow sweep is never re-entered by the following tick. - The producer pulls matching entities from the Meta Graph API, 1000 per page, following Meta’s own paging cursors. An ad account whose fetch fails is retried up to 3 total attempts, waiting 1 second and then 2 seconds, then skipped rather than blocking the rest.
- One job per ad account is enqueued onto a Redis-backed BullMQ queue named
facebook_queue. - The worker groups the rule’s conditions by reporting period, unions the Meta Insights fields those periods need, and issues them as a single Graph batch request. Every Insights call is sent with
use_unified_attribution_setting=true, so the numbers the rule judges are the numbers your ad set’s attribution window reports. - Conditions are evaluated, actions are executed, and results are persisted as one
rule_resultper campaign per task plus arule_benchmarkroll-up for the batch.
Batch progress is reported back to the queue as a whole percentage after each campaign finishes, so a run in flight shows a real figure rather than a spinner.
What are the honest limits?
The 10-second tick is how often AdOps looks for due work, not a promise about end-to-end latency. A sweep processes due rules one after another, and a large account with many pages of campaigns takes as long as Meta takes to answer. Treat the check interval as the floor on how often a rule can be considered, not as a service level.
The dispatcher’s blast radius is worth stating plainly, because it is verifiable rather than aspirational. That process only issues GET requests to Meta and writes two scheduling timestamps to its own database. It never calls a Meta write endpoint, so a bad deploy of the dispatcher cannot alter a campaign.
Where do you start if you do not want a blank rule?
AdOps ships 10 rule templates across 4 categories, tagged budget, status, naming or monitoring. Opening the Templates modal shows each template’s task count and a preview of every action, frequency, value and condition it contains before you import it. Importing drops those tasks into the rule you are editing, where they behave like tasks you wrote by hand.
Capabilities
What this feature does, item by item.
Each line is a behaviour you can reproduce in the product today.
- Conditions in plain arithmetic
- Each condition is a metric, a reporting period, one of 6 operators, and a number. A task combines its conditions with a single AND or OR. Nothing about the logic is hidden from you.
- Two targeting levels
- A rule runs at campaign level or ad set level. The level is stored on every result row, and the engine issues its Meta Insights reads at that level.
- Pre-filters before evaluation
- Scope a rule by campaign ID, campaign name or campaign status before any metric is read, so a rule only ever sees the campaigns you meant it to see.
- Many tasks in one rule
- A rule holds an array of tasks. Each task carries its own action, its own conditions and its own cooldown, so one rule can scale winners, pause losers and tag both.
- A dispatcher that cannot change your ads
- The producer that decides which rules are due only issues GET requests to the Meta Graph API. Every write happens in the separate worker process.
Questions
Asked about this feature.
Direct answers, with the numbers attached.
How often does an AdOps rule actually run?
The AdOps dispatcher checks for due work every 10 seconds and picks up any active rule whose next execution time has passed. How often a given rule becomes due is set by you, either as a check interval between 15 minutes and 72 hours or as a weekly timetable of days and hours.
Can one AdOps rule do more than one thing?
Yes. An AdOps rule holds a list of tasks, and each task carries its own action, its own conditions and its own cooldown. A single rule can raise the budget on campaigns above a ROAS threshold and pause the campaigns below it in the same run.
How does AdOps decide which campaigns a rule applies to?
AdOps applies three pre-filters before any metric is read. A rule can be scoped by campaign ID with equal or not equal, by campaign name with contains or does not contain, and by campaign status with is or is not against ACTIVE and PAUSED.
Does AdOps read every Meta metric on every run?
No. AdOps derives the field list from the conditions themselves, de-duplicates it, groups the conditions by reporting period, and sends one Meta Graph batch request covering every period the rule needs. Metrics resolved elsewhere, such as time of day or a custom metric, are excluded from that request.
Can the scheduler change a campaign by accident?
The AdOps component that decides which rules are due only issues GET requests to the Meta Graph API and writes two scheduling timestamps back to its own database. Every budget change, pause and rename runs in a separate worker process that consumes the queue.
Nearby
Features that work with this one
Write this rule against your own account.
Every feature on this page is available on every plan. Connect one ad account, copy a template, and read the log after the first run.
