Rule scope — which campaigns and ad sets it targets

Scope = ad_account_ids + entity_filter (name contains / status). Entity level controls granularity. Use naming conventions for reliable filtering.

Written By Salvatore Sinigaglia

Last updated About 4 hours ago

Scope = ad_account_ids + entity_filter (name contains / status). Entity level controls granularity. Use naming conventions for reliable filtering.

Rule scope — which campaigns and ad sets it targets

Two layers control which entities a rule evaluates: 1) ad_account_ids[] — which accounts the rule scans, and 2) entity_filter — narrow further by name pattern + status. The entity level (campaign / adset / ad) determines granularity of both evaluation and action.

Who is this for

Anyone building a rule that should target a specific slice of accounts (one client, one product line, one geo) instead of everything.

Why scope matters

A rule with no scope = global scope = every entity in every connected ad account. That's almost never what you want. Bad scope causes:

  • Rules acting on the wrong client's campaigns (esp. agency setups)
  • Test campaigns being killed by production-grade rules
  • Rules conflicting (e.g. two rules adjusting budget on same entity)

Tight scope avoids these.

Layer 1: ad accounts

Multi-select picker in the builder. Pick one or more ad accounts.

Use cases:

  • Single account — most common. One rule per client / per product / per geo.
  • Multi-account, same client — same client with separate accounts per platform or per geo
  • All accounts — risky; only for global guard rails (e.g. notify_only on > 90% daily budget)

Cross-platform rules (behind ENABLE_CROSS_PLATFORM_RULES flag) add platforms[] — which platforms within the chosen accounts to evaluate (default [meta]).

Layer 2: entity_filter

Narrow within the chosen accounts. Three sub-filters:

name_contains

Only evaluate entities whose name contains the substring.

Example: name_contains: "Prospecting" → only prospecting campaigns (assuming naming convention used).

name_not_contains

Exclude entities whose name contains the substring.

Example: name_not_contains: "TEST" → skip test campaigns.

status_in

Only evaluate entities in the listed statuses. Options: active, paused, archived. No default: if status_in is empty, the rule evaluates entities in all statuses. Set it explicitly (e.g. [active]) to narrow.

Use case: set status_in: [active] (most common) so paused / archived entities aren't evaluated.

Layer 3: entity level

Pick one:

  • campaign — evaluate campaign-level metrics, act on campaigns
  • adset — adset-level (more granular, most common for performance rules)
  • ad — per-ad (most granular, useful for creative rotation)

Granularity matters: campaign-level CPA averages out wins and losses inside; adset-level catches the losing audience inside a winning campaign.

How they combine

Final scope = entities matching (ad_account IN ad_account_ids) AND (entity_filter applies) AND (entity_level matches).

Example:

ad_account_ids: [act_123]entity_filter:  name_contains: "Prospecting"  status_in: [active]entity_level: adset

Result: every active ad set inside account act_123 whose name contains "Prospecting".

Naming conventions are critical

Without naming conventions, name_contains is useless. With them, scope becomes precise.

Recommended pattern: [Client]_[Campaign-Type]_[Audience]_[Geo]_[YYYYMM]_[Version]. E.g.

ClientA_SalesProspecting_LookalikePurchasers_IT_202611_v2

Rule scope variations:

  • name_contains: "ClientA" — only ClientA
  • name_contains: "SalesProspecting" — only prospecting type
  • name_contains: "_IT_" — only Italian geo
  • Multiple rules with different name_contains to handle different segments

See am-108 naming conventions.

Multi-account rules

For agency setups managing many clients on one Wevion workspace: pick all ad accounts in scope + use name_contains per-client convention (if your naming includes client prefix).

Alternative: one rule per client (duplicate + change scope). Simpler to audit + change per-client.

Cross-platform scope

If ENABLE_CROSS_PLATFORM_RULES is on: add platforms[] to limit which platforms in the chosen accounts are evaluated. Default [meta].

Useful when one ad account holds multiple platform integrations — restrict the rule to Meta only or Google only.

What you'll see in preview

POST /api/v1/rules/preview returns all entities evaluated (scope working) + per-entity match result. If scope is wrong:

  • No entities at all: scope too narrow (filter excludes everything) — check name_contains typos
  • Way too many entities: scope too broad (no filter at all) — add name_contains to narrow
  • Wrong entities: check the entity_level + status_in are what you intended

Common mistakes

  • No name_contains: rule scans every campaign — slower + risky
  • Naming convention not enforced: name_contains misses entities because copy used "PROSP" instead of "Prospecting"
  • status_in set to [active] when you need paused entities: an "activate at 9am" rule needs paused entities in scope — include paused in status_in (remember status_in has no default; leaving it empty evaluates all statuses)
  • Multiple rules same scope + same action: conflicts. Use disjoint scopes or merge into one rule.

FAQ

What controls a rule's scope in Wevion?

Wevion rule scope has two main layers: ad_account_ids[] (which accounts the rule scans) and entity_filter (narrowing by name pattern and status). A third setting, the entity level — campaign, adset, or ad — sets the granularity of both evaluation and action. Combined, they define exactly which entities the rule evaluates.

Why does name_contains fail to match my campaigns?

In Wevion, name_contains relies on consistent naming conventions. Without them the filter is useless — it misses entities when copy uses "PROSP" instead of "Prospecting". Enforce a pattern like [Client]_[Campaign-Type]_[Audience]_[Geo]_[YYYYMM]_[Version] so name_contains and name_not_contains filter reliably.

How do I scope a Wevion rule for a single client in an agency setup?

Pick that client's ad accounts in the multi-select picker, then add a name_contains filter using your client-prefix convention. Alternatively, create one rule per client by duplicating and changing the scope — simpler to audit and adjust per-client. Multi-account rules need a naming convention that includes the client prefix.

What does preview show if my scope is wrong?

Wevion's rule preview (POST /api/v1/rules/preview) returns every entity evaluated plus per-entity match results. No entities means scope is too narrow — check name_contains typos. Too many means it's too broad — add name_contains. Wrong entities means you should verify entity_level and status_in.

Which entity level should I use for performance rules?

Adset level is most common for performance rules in Wevion because it catches a losing audience inside a winning campaign, while campaign-level CPA averages wins and losses together. Use campaign level to act on whole campaigns, or ad level for the most granular control, useful for creative rotation.

FAQ

What controls a rule's scope in Wevion?

Wevion rule scope has two main layers: adaccountids[] (which accounts the rule scans) and entity_filter (narrowing by name pattern and status). A third setting, the entity level — campaign, adset, or ad — sets the granularity of both evaluation and action. Combined, they define exactly which entities the rule evaluates.

Why does name_contains fail to match my campaigns?

In Wevion, namecontains relies on consistent naming conventions. Without them the filter is useless — it misses entities when copy uses "PROSP" instead of "Prospecting". Enforce a pattern like [Client][Campaign-Type][Audience][Geo][YYYYMM][Version] so namecontains and namenot_contains filter reliably.

How do I scope a Wevion rule for a single client in an agency setup?

Pick that client's ad accounts in the multi-select picker, then add a name_contains filter using your client-prefix convention. Alternatively, create one rule per client by duplicating and changing the scope — simpler to audit and adjust per-client. Multi-account rules need a naming convention that includes the client prefix.

What does preview show if my scope is wrong?

Wevion's rule preview (POST /api/v1/rules/preview) returns every entity evaluated plus per-entity match results. No entities means scope is too narrow — check namecontains typos. Too many means it's too broad — add namecontains. Wrong entities means you should verify entitylevel and statusin.

Which entity level should I use for performance rules?

Adset level is most common for performance rules in Wevion because it catches a losing audience inside a winning campaign, while campaign-level CPA averages wins and losses together. Use campaign level to act on whole campaigns, or ad level for the most granular control, useful for creative rotation.

Last updated: 2026-05-17