---
title: "Matching rules and network defaults"
description: "Author the category/label rules that pair demand with inventory, make them apply automatically, and set the sixteen network-wide defaults that decide how new sites, advertisers, banners and placements are born."
type: "howto"
audience: [admin]
keywords: [rules, matching rules, campaign rule, inventory rule, apply automatically to, default for, inventory and campaigns settings, rules panel default status, rules management, network defaults, piggybacks default status, daisy chaining depth, macros accessibility, VAST events, default VAST tracking]
ui_path: "Admin → Ad serving → Rules"
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# Matching rules and network defaults

Two admin screens decide how demand and inventory find each other, and what every new
object on the network looks like the moment it is created:

- **Admin → Ad serving → Rules** — reusable *matching rules*. A rule is a named set of
  category and label conditions. Network managers attach rules to entities on the account
  side; the ad server then pairs banners with placements that satisfy them.
- **Admin → Ad serving → Inventory & campaigns settings** — sixteen independently saved
  cards holding network-wide defaults, from a new site's approval status to which macros
  are allowed to leak entity names.

They are on one page because they are wired together: the *Apply automatically to* boxes on
a rule only ever fire because of a setting on the other screen.

## Who this is for

Network administrators. **Rules** and **Inventory & Campaigns Settings** are two separate admin
permissions on the role, so an administrator may hold one without the other. Both pages live
under **Ad serving** in the admin nav.

Network users never see either screen. Where the rules you write here are actually put to
work is the **Matching rules** card on the account side — on a network manager's sites,
placements, advertisers and campaigns — documented in
[Attach matching rules to an entity](https://epom.com/ad-server/docs/guides/targeting/entity-matching-rules.md). Publishers and
advertisers do not get that card at all, so a rule reaches their inventory or demand without
them ever seeing it.

## Prerequisites

- The categories a rule matches on must already exist. A **Campaign rule** picks from
  *advertising categories*, an **Inventory rule** from *inventory categories* — both are
  maintained in [Manage category taxonomies](https://epom.com/ad-server/docs/guides/admin/taxonomies.md). The rule form only selects
  from existing entries; it cannot create one.
- Labels, if you want to match on them, must exist under **Admin → Categories & labels →
  Labels**. With no labels on the network the Label picker in the rule form is simply empty.

## Steps

### Create a matching rule

1. Go to **Admin → Ad serving → Rules**. The grid lists every rule with **ID**, **Name**,
   **Type**, **Details** (the condition count, e.g. *1 match(es)*), **Status** (*Active* or
   *not active*) and **Default for** (badges for the levels the rule auto-applies to).
   There is no search box; the toolbar is **Add**, **Edit**, **Delete**, then **Activate**
   and **Deactivate**. **Edit** only lights up when exactly one row is ticked; the other
   three accept a multi-row selection. Double-clicking a row opens it too.
2. Click **Add**, then name the rule and pick its **Type**. The type names the side the
   rule *tests*, which is the opposite of the side you will attach it to:

   | Type | Tests | Attach it to | So it controls |
   |---|---|---|---|
   | **Campaign Rule** | advertising categories + labels (demand) | sites, zones, placements | which demand may serve on that inventory |
   | **Inventory Rule** | inventory categories + labels (supply) | advertisers, campaigns, banners | where that demand may serve |

   Each option describes itself in the open **Type** dropdown (there is no help paragraph
   under the closed picker), and switching type clears every category already chosen — the
   two vocabularies are not interchangeable.

   ![Rules edit form for a Campaign rule — Type, Active, the Apply automatically to checkboxes, and one condition matching two advertising categories](https://epom.com/docs-images/ad-server/rules-and-defaults/rule-edit.webp)

3. Tick **Active**. A new rule is created **inactive**, and an inactive rule is left out of
   the ad cache entirely — it is not enforced even where it is already attached.
4. Optionally tick the boxes under **Apply automatically to**. The three on offer follow the
   type: a Campaign rule gets *All sites / All zones / All placements*, an Inventory rule
   gets *All advertisers / All campaigns / All banners*. Read
   [what these actually do](#make-a-rule-apply-automatically) before relying on them — the
   label overstates the case.
5. Under **Conditions**, click **Add** for each condition. A condition has an
   **include/exclude** picker, an **Operator** (*AND* / *OR*), a **Category** multi-select
   and a **Label** multi-select. Conditions are separated by an **And** divider because they
   are ANDed: an entity must satisfy every condition in the rule.
6. Click **Save**. The form returns to the grid and a **Done** toast appears. To turn rules
   on or off later, tick them in the grid and use **Activate** / **Deactivate** — you do not
   have to open each one.

### Make a rule apply automatically

The **Apply automatically to** boxes do nothing on their own, and they are not retroactive.
They are consumed at exactly one moment: when an entity's **Matching rules** card is
switched **on**. At that moment every rule flagged for that entity's level is attached to it,
each as its own single-rule group.

There are two ways that moment arrives:

1. **At creation**, if **Admin → Ad serving → Inventory & campaigns settings → Rules panel
   default status** has that entity's card set to **On**. A new object of that kind is then
   born with its Matching rules card on and the default rules already attached.
2. **By hand**, when anyone switches the Matching rules card on for an existing entity.

So to make a rule genuinely automatic you must set **both**: the flag on the rule *and* the
matching card in **Rules panel default status**. With the setting left **Off** — which is the
shipped default for all six levels — flagging a rule *default for* achieves nothing until a
user turns a card on themselves.

### Change a network default

1. Go to **Admin → Ad serving → Inventory & campaigns settings**.
2. Find the card you need and change its controls. Almost every card is an independent form
   with its **own Save button** — there is no page-level save, and saving one card leaves the
   others untouched. The exceptions are **Site revenue share preferences** and **Site pricing
   preferences**: each has an on/off switch in its heading (turning it off asks for
   confirmation and deletes the bindings or per-country rates) and a table below it whose
   rows you **Add** and **Delete** one by one, with no card-level Save. **Default VAST
   tracking events** is two blocks, each with its own Save. The frame below is scrolled to
   the two cards that govern rules.

   ![Inventory and campaigns settings scrolled to the Rules panel default status and Rules management cards, with four cards visible and a separate Save button on each](https://epom.com/docs-images/ad-server/rules-and-defaults/inventory-defaults.webp)

3. Click that card's **Save**. A **Done** toast confirms it (the **Site default status** card
   says *Default site status changed.* instead). Check the table below before you
   assume the change reaches objects that already exist — most of these cards only shape
   *new* ones.

Any signed-in user can read the three defaults that shape their own creates over REST:
`GET /rest-api/network/settings.do` returns `newEntities.active` (*Advertiser default
status*), `newEntities.siteApprovalStatus` (*Site default status*, only for a user who may
create sites) and `newEntities.piggybackActive`.

## Options and fields

### The rule form

| Field | What it does |
|---|---|
| **Name** | Required, capped at 64 characters — both checked by the form. Shown in the grid and in every account user's rule picker, so name it for what it selects, not for the ticket that asked for it. |
| **Type** | *Campaign Rule* or *Inventory Rule* — see the table in step 2. Defaults to *Campaign Rule*. Changing it clears the chosen categories. |
| **Active** | Off for a new rule. Inactive rules stay in the grid and keep every attachment, but they are dropped from the ad cache and so stop being enforced. The account-side picker also hides them until the user ticks its *Show inactive* box. |
| **Apply automatically to** | Three checkboxes matching the type. See [Make a rule apply automatically](#make-a-rule-apply-automatically). |
| **Conditions** | Zero or more condition rows, ANDed together. Nothing requires you to add one — and a rule saved with **no** conditions matches *everything* on the other side, so attaching it widens rather than narrows. |

### A condition

| Control | What it does |
|---|---|
| **include / exclude** | *include* keeps the entities that satisfy the condition; *exclude* keeps the ones that fail it. It inverts this condition's test — it is not the same operation as the include/exclude on the account-side rule group. |
| **Operator** | *AND* requires **every** selected category **and** every selected label to be present. *OR* requires **any one** selection, across categories and labels together. |
| **Category** | Advertising categories for a Campaign rule, inventory categories for an Inventory rule. Type to filter; pick as many as you like. |
| **Label** | Labels, for either type. Empty on a network that has no labels defined. |

> **Note:** the categories and labels a rule reads are not necessarily the ones on the entity
> you attached it to. Inventory categories come from the **site**, labels from the
> **placement**; advertising categories come from the **advertiser**, labels from the
> **banner plus its campaign**. The full matrix is in
> [Attach matching rules to an entity](https://epom.com/ad-server/docs/guides/targeting/entity-matching-rules.md#what-a-rule-looks-at).

### Defaults that shape new objects only

Changing any of these leaves existing objects exactly as they are.

| Card | What it sets | Applied when |
|---|---|---|
| **Site default status** | The network **approval** status a new site is given — *Approved*, *Pending* or *Rejected*. Not an active/inactive switch. | A new site is created. Bypassed to *Approved* when the creator holds the sites-approval permission or is an admin switched into the account. |
| **Site revenue share preferences** | A template of advertiser/campaign → revenue-share-% bindings, copied onto each new site. Turning the card off deletes every binding. | A new site is created. Ad serving reads each site's own copy, never this template. See [Pricing](https://epom.com/ad-server/docs/guides/delivery/pricing.md). |
| **Site pricing preferences** | A template of the global rate plus per-country CPM/CPC rates, copied onto each new site. Turning the card off loses the per-country rates. | A new site is created. |
| **Advertiser default status** | Whether new advertisers, campaigns **and** banners are created active or inactive. | Each of those three is created. |
| **Piggybacks default status** | Whether a new piggyback row starts active (field label *Default Status of Piggyback for Inventory/Advertiser*). Governs the status of rows you add in the piggyback grids on sites, placements and campaigns — see [Piggybacks](https://epom.com/ad-server/docs/guides/conversions/piggybacks.md). | A new piggyback row is opened. |
| **Rules panel default status** | Six On/Off selects — *Site card*, *Zone card*, *Placement card*, *Advertiser card*, *Campaign card*, *Banner card*. Each decides whether a new object of that kind is created with its Matching rules card switched on **and** the *Apply automatically to* rules attached. | That kind of object is created. Ships **Off** for all six. |
| **Daisy chaining lookup depth** | The hop count copied into a placement's daisy-chaining config when that config has none yet. Ad serving reads the per-placement value, not this one. See [Daisy chaining and passback](https://epom.com/ad-server/docs/guides/delivery/daisy-chaining-passback.md). | A placement's daisy chaining is first configured. |
| **Default VPAID framework** | The framework pre-selected on the **create** form for a new video banner. It never rewrites an existing banner. See [Video banners](https://epom.com/ad-server/docs/guides/advertising/banner-video.md). | The banner create form is opened. |
| **Default VAST tracking events** | Which VAST playback events (quartiles, complete, mute, viewability…) are already switched on when a video placement or video banner is created — two independent sets, *New video placements* and *New video banners*, each with its own Save. | A video placement or video banner is created. |
| **Placement domain as default channel** | One Active/Inactive select, *Default value of domain as default channel for new placements*: whether a new placement is created with its domain used as the default channel. See [Create a placement](https://epom.com/ad-server/docs/guides/inventory/placements-create.md). | A placement is created. |

### Settings read live

These take effect for everything on the network, including objects created long ago.

| Card | What it sets | Read at |
|---|---|---|
| **Rules management** | Two selects — *Publishers tab* (*All campaigns rules* / *None of campaigns rules*) and *Advertisers tab* (*All inventory rules* / *None of inventory rules*). They decide what an entity with the Matching rules card **on and no rules attached** matches: *All…* means it pairs with everything on the other side, *None…* means it drops out of rule matching. The entity's card prints the answer in its own empty state. | Every ad-cache rebuild, and every entity edit page. |
| **Banner approval obligatory fields** | Which of *Advertiser category*, *Pricing*, *Targeting*, *Limits* must be filled before a banner can be submitted for approval. The *Pricing*, *Targeting* and *Limits* checks are additionally skipped for a user who lacks the matching permission (*Manage Pricing*, *Manage Demand Targeting*, *Manage Capping & Limitations*); the *Advertiser category* check applies to everyone. | Every submit-for-approval. Tightening it immediately blocks submissions for banners that already exist. |
| **Banner approval moderation fields** | Which field changes on an **edit** send a creative back to moderation — three checkboxes, *URL for local/external banner type*, *Banner Creative for Local/External File Banner Type* and *Code for HTML code banner type*. It does **not** decide whether new banners are moderated: a banner created by a user who holds *Banners Moderation With Deactivation* or *Soft Banners Moderation* (and not *Banners Approval*) starts pending whatever this card says, and the card is never consulted for a brand-new banner. See [Moderate banners, sites and traffic quality](https://epom.com/ad-server/docs/guides/admin/moderation-and-quality.md). | Every banner save. |
| **Accounting period management** | Three sets of share types (*Is Owner*, *Can Edit*, *Can View*), labelled *Sharing type requirement for preliminary confirming / confirming / finalizing*. The report page enables the matching accounting-period buttons only when the user's share on every selected row is in the set; an empty set means any share qualifies. See [Finances, fees and referral billing](https://epom.com/ad-server/docs/guides/admin/finances-and-billing.md). | Every analytics page load. |
| **Macros accessibility** | Two Active/Inactive selects — publisher-side entity names (`$$PLACEMENT_NAME$$`, `$$ZONE_NAME$$`, `$$PUBLISHER_NAME$$` and their `_ESC` variants) and advertiser-side ones (`$$ADVERTISER_NAME$$`, `$$CAMPAIGN_NAME$$`, `$$BANNER_NAME$$`). Switching a side off **strips** those macros from the served markup rather than leaving them unresolved, and removes them from the macro reference lists in the UI. See [Macros reference](https://epom.com/ad-server/docs/reference/macros.md). | Every macro substitution, i.e. every ad served. |

> **Warning:** the sixteenth card, **VPAID to MRAID bridge template**, is inert. The chosen
> template is stored but nothing uses it; setting it changes no behaviour.

## Where the vocabularies live

The values a rule picks from are maintained on other admin screens:

| Screen | Where it is documented |
|---|---|
| **Categories & labels → Advertising categories / Inventory categories** | [Manage category taxonomies](https://epom.com/ad-server/docs/guides/admin/taxonomies.md) — the two vocabularies a rule's **Category** field draws on. |
| **Creatives & tags → Custom ad units & sizes** | [Other admin tools](https://epom.com/ad-server/docs/guides/admin/admin-tools.md) — the size catalogue every placement and creative picks from. |
| **Categories & labels → Labels** | [Manage categories and labels](https://epom.com/ad-server/docs/guides/admin/taxonomies.md) — free-form values attachable to banners, campaigns and placements, and matchable by a rule's **Label** field. |
| **Categories & labels → Custom country groups** | Not yet documented. Named country sets reusable in geo targeting — edit the group once and every targeting rule using it follows. |
| **Categories & labels → Domain categories** | Retired from the new UI's sidebar. A deprecated list of named ad-serving and invocation-code domain pairs, superseded by the ad-serving domains Epom support manages for your network. |

## Corner cases and gotchas

> **Corner case:** a rule that is attached to any entity **cannot be deleted**. The delete
> confirmation warns you ("*Rules in use will not be removed*"), and the request then returns
> a **Rules in use** dialog listing each blocked rule and the entities holding it. Those
> entities have to detach the rule first. Deleting a multi-row selection deletes the free
> rules and reports the rest — you get both a "*N record(s) deleted*" toast and the dialog.
> Deactivating has no such restriction and is the right move when you are diagnosing
> delivery, since it stops enforcement everywhere while keeping every attachment.

> **Corner case:** the usage dialog identifies entities by **type and numeric id** —
> "*Advertiser: 9*" — never by name. Look the ids up before going hunting.

> **Corner case:** a rule can only ever **widen** a placement's candidate pool. At serving
> time the banners a placement's rules select are *added to* the banners hard-linked to it,
> not filtered against them. A directly linked banner keeps serving no matter what any rule
> says, so an *exclude* rule is not a way to stop a linked creative — unlink it, or use
> [blocking](https://epom.com/ad-server/docs/guides/targeting/block-ad-categories-on-inventory.md).

> **Corner case:** rules are re-evaluated continuously, but **lazily**. When the ad cache
> reloads, every placement's rule result is marked stale and recomputed in the background;
> the first request to arrive meanwhile is answered from the previous result. Expect a short
> window after a rule change in which serving still reflects the old rule.

> **Corner case:** rules are not the same mechanism as **auto-linking**. Auto-linking runs
> once, when a placement or site is created or edited, and writes permanent banner ↔
> placement links from a banner's own *allow new placements auto-linking* settings. Rules
> write nothing and are recomputed forever. The two are configured in completely different
> places and one is not a substitute for the other — see
> [Hierarchy and linking](https://epom.com/ad-server/docs/concepts/hierarchy-and-linking.md).

> **Corner case:** default VAST tracking events are copied onto a video placement or banner
> once, when it is created. Changing the defaults never touches entities that already exist,
> and a copied placement or banner keeps its source's events rather than the defaults. OpenRTB
> banners are skipped, as they have no VAST tracking card. Auto-placements are not covered.

> **Corner case:** un-ticking **Apply automatically to** never detaches the rule from
> entities that already received it. The mechanism only ever adds. Nor does folding a default
> rule into a multi-rule group count as "already attached" — switch the entity's card off and
> on again and you get a second, single-rule copy of it.

> **Corner case:** re-saving a rule rebuilds all of its conditions from scratch. The stored
> condition rows are discarded and replaced with new ones, so anything keyed on a condition's
> identity — an audit trail, an external reference — will not survive an edit. The rule's own
> id is stable.

> **Corner case:** setting **Site default status** to *Pending* often looks like it did
> nothing, because a reviewer or administrator creating sites themselves is exempt: a user holding the
> sites-approval permission, or an admin switched into a publisher's account, always gets
> *Approved*. The setting only bites for publishers creating their own sites.

> **Corner case:** the **Default VPAID framework** and **VPAID to MRAID bridge template**
> pickers are populated by the VPAID-frameworks and templates admin endpoints, each guarded
> by its own permission. An administrator who holds *Inventory & campaigns settings* but not
> *VPAID framework management* or *Template management* sees an empty dropdown rather than an
> error.

> **Corner case:** **Daisy chaining lookup depth** is range-checked in the browser only
> (1–100). A value sent by other means is stored unvalidated.

## Per-role notes

- **Admin with *Rules* only** — can author rules but not set **Rules panel default status**,
  so *Apply automatically to* never reaches new entities until someone with *Inventory &
  Campaigns Settings* turns the card on. Grant the two together.
- **Admin with *Inventory & Campaigns Settings* only** — still sees and saves the two rules
  cards without the Rules screen.
- **Network manager** — never sees these screens; works with the **Matching rules** card
  (active rules of the opposite type only) and **Matched banners** / **Matched placements**.
- **Publisher, advertiser** — no Matching rules card; rules apply to them unseen.

## Related

- [Attach matching rules to an entity](https://epom.com/ad-server/docs/guides/targeting/entity-matching-rules.md) — the
  account-side card, the demand/supply flip, and how include/exclude and the group operator
  are evaluated
- [Manage category taxonomies](https://epom.com/ad-server/docs/guides/admin/taxonomies.md) — the two category vocabularies a rule
  matches on, their public/internal visibility, and what deleting one does to a rule
- [Keep unwanted ad categories off your inventory](https://epom.com/ad-server/docs/guides/targeting/block-ad-categories-on-inventory.md)
  — blocking, which *removes* candidates where a rule can only add them
- [Moderate banners, sites and traffic quality](https://epom.com/ad-server/docs/guides/admin/moderation-and-quality.md) — the workflow
  the two banner-approval cards feed
- [Piggybacks](https://epom.com/ad-server/docs/guides/conversions/piggybacks.md) · [Daisy chaining and passback](https://epom.com/ad-server/docs/guides/delivery/daisy-chaining-passback.md)
  · [Pricing](https://epom.com/ad-server/docs/guides/delivery/pricing.md) · [Macros reference](https://epom.com/ad-server/docs/reference/macros.md) ·
  [Finances, fees and referral billing](https://epom.com/ad-server/docs/guides/admin/finances-and-billing.md) — the features the live
  settings govern
- [Other admin tools](https://epom.com/ad-server/docs/guides/admin/admin-tools.md) — VPAID frameworks, auto placements, additional
  entity fields
- [Hierarchy and linking](https://epom.com/ad-server/docs/concepts/hierarchy-and-linking.md) — direct links and
  auto-linking, the other two ways a banner reaches a placement