---
title: "Moderate banners, sites and traffic quality"
description: "Approve or reject pending banners and sites, read the traffic-quality scores, and tune the network-wide validation settings that decide which events count."
type: "howto"
audience: [admin]
keywords: [approval, moderation, pending banners, pending sites, traffic quality, validation settings, fraud, IP blacklist, user-agent blacklist, rejected conversions, PDF report]
ui_path: "Account → Pending banners"
---

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.

# Moderate banners, sites and traffic quality

Three independent surfaces keep a network clean, and they do **not** back each other up:
the **approval queues** hold new creatives and sites for human review, **Traffic Quality**
scores your supply for invalid traffic, and **Validation settings** decide which
impressions, clicks and conversions are counted as real. A creative can pass moderation and
still deliver nothing but bot traffic; a Fraudulent placement keeps serving until you stop
it yourself.

## Who this is for

Network administrators and network managers. Pending banners, Pending sites and Traffic Quality are
account tabs; Validation settings is an admin page. Which of
them you see depends on your role — see
[Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md).

The gate covers the queue **and every verdict in it**: approving or rejecting a banner needs
*Banners Approval*, and approving, rejecting or re-categorising a site needs *Sites Approval*
— even for someone who can edit that banner or site.

## Prerequisites

- **Banner moderation is switched on per role, not per network.** A user's saves are
  moderated only when their own ACL role carries **Soft Banners Moderation** or **Banners
  Moderation With Deactivation**. On a network where no role holds either, nothing ever
  enters the banner queue no matter what the admin settings say. A user who holds **Banners
  Approval** is never moderated at all — their own saves stay approved.
- **The two "Banner approval …" admin cards do not switch moderation on.** They only tune a
  flow a permission has already enabled — see *Options & fields* below for what each does.
- **What the switch does depends on which moderation grant the role carries.** With
  *banners moderation with deactivation*, a creative cannot be activated until it is
  approved, and editing a moderated field switches it off again — so review is what
  puts it on the air. With *soft banners moderation*, editing a moderated field only
  sends the creative back to the queue: **it keeps serving while it waits**. Soft
  moderation is a review workflow, not a hold.
- **Site moderation is a network preference.** Set **Admin → Ad serving → Inventory &
  campaigns settings → Site default status** to *Pending*; new publisher sites then queue for
  review. It ships as *Approved*, so by default nothing queues.
- **Traffic Quality has to be switched on for your network** — it is off by default and has
  no in-product switch; ask Epom support or your account manager — and your role needs both permissions above.
- Traffic Quality scores one day at a time, and only placements with enough traffic that day.
  A quiet placement is never scored and never appears.

## Steps

### Approve or reject a creative

1. Go to **Account → Pending banners**.

   ![Pending banners queue with Pending and Rejected creatives and per-row Approve and Reject buttons](https://epom.com/docs-images/ad-server/moderation-and-quality/pending-banners.webp)

2. Each row is one creative: **Name**, **Advertiser**, **Campaign**, **Placement type**,
   **Categories**, **Created**, **Users** (the accounts the advertiser is shared with) and a
   **Status** pill. Name, advertiser and campaign all link to their edit pages.
3. Narrow the queue with the two filters. **Status** defaults to *Pending + Rejected*;
   *Approved* and *New* can be added. The **Filter** box is labelled *by name…* but matches
   **either** a banner name **or** the username of a user the advertiser is shared with — see
   the corner case on its blind spot before you trust an empty result.
4. Click **Approve** on the row. It applies immediately and the row reloads. Approving also
   needs edit rights on the advertiser — a Can Edit or Is Owner share; on a Can View
   advertiser it is refused.
5. Click **Reject** on the row and confirm *"Are you sure you want to reject this item?"*.
   **This also switches the creative off**, so it stops serving immediately; it stays in the
   queue under the *Rejected* filter.
6. To remove creatives instead, tick their checkboxes and use **Delete** at the top right —
   this is the only action that works on a multi-row selection, and it confirms with
   *"The following items will be deleted along with everything in them. You can restore them
   within 90 days."* — see [Restore something you deleted](https://epom.com/ad-server/docs/troubleshooting/restore-deleted.md).

You can also moderate one creative from its own page: open it and use **Actions →
Approve** / **Reject**. Both entries disappear once the creative is approved, and *Reject*
greys out once it is already rejected. A user whose own role is moderated gets a different
third entry there instead — **Submit for approval** — which is how a creative that is New or
Rejected goes back into the queue.

> **Approval does not switch a creative back on.** Whether it was deactivated by a
> rejection or by moderation-with-deactivation, approving it only clears the verdict —
> whoever owns the campaign decides when it runs again. That keeps a reviewer working
> through the queue from putting creatives back on the air that were paused on purpose.

> **Approving gives the moderator no share.** Approving a banner or a site records the
> verdict and notifies the owners; it does not add the moderator as an owner of the
> advertiser or site. Grant a share separately if the moderator should manage it.

### Approve or reject a site

1. Go to **Account → Pending sites**. The columns are **Name**, **URL** (opens the live site
   in a new tab), **Categories**, **Created**, **Users** and **Status**. There is no *New*
   status for sites — only Pending, Rejected and Approved.
2. **Approve**, **Reject** or select rows and **Delete**, exactly as for creatives. Rejecting
   a site from this page sends no e-mail: the page posts no rejection reason, and the
   server mails the site's owners only when it is given one.

> **Note:** approving a site is also what generates its automatic placements. A site left
> pending may simply have no placements to serve.

### Read traffic-quality scores

1. Go to **Account → Traffic Quality**.

   ![Traffic Quality page: seven summary cards above a grid of scored placements](https://epom.com/docs-images/ad-server/moderation-and-quality/traffic-quality.webp)

2. The seven cards summarise the selected scan date: **Clean traffic**, **Suspicious**,
   **Fraudulent** and **Blocked** (these four are counts of *placements*, not impressions),
   then **Impressions analyzed**, **Est. fraud spend** and **Scan date**. They ignore the
   **Level** filter — they always count every placement you may see for that date. **Est.
   fraud spend** is an estimate: each placement's gross times the share of its impressions
   that carry invalid-traffic signals.
3. Filter by **Date** — it defaults to yesterday and will not accept a date after today —
   and by **Level**, a multi-select that defaults to *Fraudulent + Blocked* so the worst rows
   surface first.
4. Each row scores one placement: **Site**, **Zone**, **Placement** (all three link into the
   publisher tree), the numeric **Score**, the colour-coded **Level**, **Impressions** and
   **Gross**, then five percentages — **DC proxy**, **Susp. proxy**, **Emulator**,
   **Duplicate**, **Risk flagged** — and finally **Indicators**, the named detections that
   fired. On a window about 1,440 px wide the grid
   scrolls sideways inside its card: **Indicators** and the **Report** column (with
   **Generate report**) sit past the right edge until you scroll the grid.
5. For evidence, click **Generate report** on the row. The button becomes *Generating...*; the
   page polls every 30 seconds and, when the report is ready, asks *Report for placement N
   is ready. Download now?* and then shows **Download PDF** on the row. Rows already
   generating when you open the page keep polling.
6. To fill a gap, ask Epom support or your account manager to run a backfill. It scores only recent days that have
   no scores at all; it cannot rescan a date you choose.

### The Traffic Quality page shows only zeros or an empty grid

Scores are computed once a day, for **yesterday**, and later retries fill days that were
missed. The page only reads what that run saved, so zeros mean one of:

- **The feature is not switched on for your network.** Traffic Quality scoring is a
  server-side setting. Until it is on, no day has scores. Ask Epom support or your account manager.
- **The day is not scored yet.** Today has no scores by design, and yesterday's appear only after
  the nightly run has processed the day. Pick an earlier scan date.

- **The level filter hides them.** The summary cards count every level, the grid shows only the
  levels ticked in the filter — *Fraudulent + Blocked* by default. Cards with numbers above an
  empty grid mean the traffic was clean or merely suspicious: add *Clean* and *Suspicious* to the
  filter.
- **You cannot see those sites.** Rows of placements on sites your role has no view access to
  are left out of both the cards and the grid.

A **Risk-flagged** percentage of 0 on every row while other indicators are non-zero means the
external risk-scoring service is not enabled on the network — the other indicators are computed
without it.

### Tune the validation settings

1. Go to **Admin → Validation & anti-fraud → Validation settings**.

   ![Validation settings page with the ten validation checkboxes and the two blacklist tabs](https://epom.com/docs-images/ad-server/moderation-and-quality/validation-settings.webp)

2. Tick or untick the checks you want and click **Save**. A green **"Data saved."** toast
   confirms it.
3. Maintain the addresses on the **Ban & white-listed iPs** tab. Columns are **IP range**,
   **Count**, **Info** and **Status**; *Count* is how often the ad servers have matched that
   entry since they last restarted, and *Info* is the location the address resolves to — both
   read `0` and `—` on a network that has not matched anything yet. **Status** shows **BAN** or **WHITE-LIST**; whitelisted ranges are never
   banned by impression-fraud detection and never blocked by the IP blacklist check. The tab
   has a search box, an **Add** button, CSV import, a **Download CSV** button, and **Delete**
   for selected rows.
4. Maintain user agents on the **White-listed user agents** tab. Columns are **User agent**,
   **Wildcard** (✓ or —), **Event**, **Placement type** and **Status** — each entry applies
   to one event type and one placement type, so the same string may need several rows.
   This tab has **Add**, **Delete** and **Refresh** only: **no search box and no CSV**, so a
   long user-agent list has to be entered one row at a time.
5. Allow about a minute for a saved validation setting to reach the ad servers, and up to
   about ten minutes for a new IP-list entry: the ad servers reload that list every ten minutes.

### See which addresses got flagged

The ad servers keep their own lists of the IP addresses they flagged for click fraud and
invalid traffic. To see who was flagged, ask Epom support or your account manager.

## Options and fields

### Validation settings — checks that change what is counted

On screen the ten boxes sit in one list: Clicks validation, Do not record the same user
sequential conversions, Conversions validation, Conversion per IP time frame, Impressions
validation, Impression signature check, the three Match … with ad request boxes, then IP
blacklist check. The two tables below group them by what they do.

Every one of these is network-wide and applies from the moment you save; none of them
reprocesses past data.

| Checkbox | What it actually does | Default |
|---|---|---|
| **Clicks validation** | Master switch for the click checks, including the IP blocklist on clicks. A click it flags is kept **out** of the General report and counted as rejected in the Advanced reports. | On |
| **Do not record the same user sequential conversions** | Turns on the repeat-conversion counters per campaign + action + IP/user-agent and per user id. It also makes a conversion that was excluded by capping or a realtime limit count as fraud. | Off |
| **Conversions validation** | Rejects duplicate conversions — **server-to-server only**, and only for actions that also have their own *Reject duplicate conversions* switch on. The pixel path uses a separate server-side setting (ask Epom support or your account manager) and ignores this box. | Off |
| **Conversion per IP time frame** | Enables the two per-IP windows on a conversion action. | On |
| **Impressions validation** | Turns on automatic banning of addresses that show invalid impression patterns; banned addresses are later written into the IP blacklist. Needs *IP blacklist check* on as well. | On |
| **Impression signature check** | Verifies the signature on each impression beacon. Leave it on. | On |
| **IP blacklist check** | Turns on matching against the **Ban & white-listed iPs** tab. Turning it off stops the matching at once. | On |

### Validation settings — flags that only label the event

| Checkbox | What it actually does | Default |
|---|---|---|
| **Match impressions with ad request** | Stamps a validation marker on the raw impression record. | Off |
| **Match clicks with ad request** | Same, for clicks. | Off |
| **Match conversions with ad request** | Same, for conversions, using the per-action *Match conversions with request* setting. | Off |

> **Note:** these three **reject nothing**. They mark the raw log record; whether an event is
> then treated as invalid is decided later in analytics processing, not by the ad server.
> They will not change your General-report numbers.

### The two "Banner approval …" admin cards

Both live on **Admin → Ad serving → Inventory & campaigns settings**, and neither switches
moderation on.

| Card | What it controls |
|---|---|
| **Banner approval obligatory fields** | Which of *Advertiser category*, *Pricing*, *Targeting*, *Limits* an advertiser must fill in before **Submit for approval** is accepted. A missing one produces an error message instead of a queue entry. |
| **Banner approval moderation fields** | Which field changes send an already-approved creative **back** to Pending: *URL for local/external banner type*, *Banner Creative for Local/External File Banner Type*, *Code for HTML code banner type*. With all three off, editing an approved creative never re-queues it. |

### Approval statuses

| Status | Banner | Site | Badged on the entity page |
|---|---|---|---|
| New | Yes — a creative created by a moderated user | — | No |
| Pending | Yes | Yes | Yes |
| Approved | Yes | Yes | **No** |
| Rejected | Yes | Yes | Yes |

### Traffic-quality levels

| Level | Score | Meaning |
|---|---|---|
| Clean (green) | 0–2 | No significant indicators. |
| Suspicious (yellow) | 3–5 | Elevated indicators; watch the placement. |
| Fraudulent (red) | 6–9 | Strong signals. Only Fraudulent and Blocked rows get the detailed second-pass analysis behind the PDF. |
| Blocked (grey) | 10 and above | The worst band. It is a label, not an action. |

## Corner cases and gotchas

> **Corner case:** a Pending creative does **not** automatically stop serving.
> Ad serving has no approval filter at all — delivery is decided by the *Active* switch.
> Under **Banners Moderation With Deactivation** the product deactivates the creative for
> you and refuses to let it be re-activated until approved. Under **Soft Banners
> Moderation** it does not, so a soft-moderated creative keeps delivering while it waits.
> **Rejecting is different: it switches the creative off whichever grant applies** — an active
> creative you reject stops serving immediately, the same as a moderation-with-deactivation refusal.

> **Corner case:** a pending site's inventory serves normally too. Site approval is a
> workflow state; nothing in ad serving reads it.

> **Corner case:** rejecting a creative **always emails everyone the advertiser is shared
> with**, and the page gives you no way to choose a reason or suppress the mail. Rejecting a
> **site**, by contrast, sends no email at all from this page.

> **Corner case:** the obvious workflow — an advertiser uploads, the network reviews — is not
> reachable from the standard Roles screen. Moderation only applies to a user whose role
> carries *Soft Banners Moderation* or *Banners Moderation With Deactivation*, and those two
> are hidden from the account-role permission matrix, so an advertiser or publisher role
> cannot be given them there. As shipped, the queue is fed by administrative users editing
> creatives. Arranging genuine advertiser self-service moderation needs Epom support.

> **Corner case:** enabling moderation is forward-looking only. Existing creatives keep the
> status they have — normally Approved — and go on serving. One enters the queue only when
> someone next edits a field listed under *Banner approval moderation fields*. There is no
> "re-moderate everything" action; a bulk re-review has to be arranged with your
> administrator.

> **Corner case:** entity pages badge only **Pending** and **Rejected** approval
> states — an approved banner or site shows no approval badge at all. Absence of a
> badge means approved, not "unknown". The badge is also hidden entirely from users who hold
> none of the three moderation permissions.

> **Corner case:** the banner queue's **Filter** box only ever returns creatives whose
> advertiser is shared with at least one user — the search runs through the sharing table.
> A creative under an unshared advertiser is in the queue, and visible with the box empty,
> but searching for it by name finds nothing. An empty search result is not proof the
> creative is absent; clear the box and sort the **Name** column instead.

> **Corner case:** the approval queues load the whole result set and page it in the browser,
> so sorting and paging never re-query. On a large backlog the first load is the slow part.

> **Corner case:** a day that is scored again **refreshes its rows** — except rows that
> already have a PDF report, which keep the numbers the report was built from. A backfill only
> ever scores days with **no** scores at all, though, so in practice a day that already has
> scores is not rescanned.

> **Corner case:** PDF generation gives up silently after about 20 minutes (40 polls, 30
> seconds apart) with no error. If a row never turns ready, generate it again rather than
> waiting. Only one report is built at a time network-wide.

> **Corner case:** rejected events are counted, not thrown away — in the Advanced reports
> as **Rejected impressions**, **Rejected clicks** and **Rejected conversions**, and on the
> General report as the *Conv. fraud* column, which counts the rejected conversions whatever
> the report is grouped by. For conversions specifically, the rejection may be a duplicate,
> the IP blocklist, either per-IP time frame, or a capping/limit exclusion — the integrator's
> response only distinguishes duplicates, and everything else is reported as OK. See
> [Conversion actions](https://epom.com/ad-server/docs/guides/conversions/conversion-actions.md) for the per-action fields and
> [Invalid traffic and risk scoring](https://epom.com/ad-server/docs/concepts/invalid-traffic-and-risk-scoring.md) for
> how the counters feed the eligible figures.

> **Corner case:** the user-agent list has no on/off switch — unlike the IP list it is live as
> soon as it has rows, and it keeps working even when *Clicks validation* is off. A user-agent
> **whitelist** hit is a strong override: it suppresses bot detection, the suspected-IP
> escalation and the missing-cookie click rejection. Each entry applies to one event type and
> one placement type, and matches the whole string unless you tick *Wildcard*.

> **Note:** enter single IPv4 addresses (`45.129.14.7`) or `from-to` ranges
> (`45.129.14.0-45.129.14.255`).

> **Corner case:** both address tabs hold *Ban* and *Whitelist* rows despite their labels —
> the **Status** column is what distinguishes them, and a whitelist hit always wins.

> **Corner case:** a role without the Traffic Quality grants can still open the Traffic
> Quality page by its address. It shows every card at 0 and *No traffic quality data
> for selected date and level filter* — the data request is refused silently. A zero grid there
> is not evidence of clean traffic; check the role first.

> **Corner case:** a server-side ad insertion stitcher (CTV) fires pixels for thousands of viewers
> from a handful of addresses. If it does not forward the viewer's IP, impression-fraud detection
> bans those addresses and every ad request through the stitcher is blocked. Whitelist the
> stitcher's egress ranges — see
> [Video placements](https://epom.com/ad-server/docs/guides/inventory/placement-video.md#serving-behind-server-side-ad-insertion-ssai).

> **Warning:** the validation toggles apply network-wide and immediately affect
> billable counts. Switching on stricter matching (impressions/clicks/conversions
> vs ad request) can visibly drop reported numbers — coordinate with billing before
> changing mid-month.

## Over the API

The creative verdict is also available over REST, with the same *Banners Approval* gate and the same effects as the queue buttons:

- `POST /rest-api/banner/{bannerId}/approvalstatus.do` with `status` = `NEW`, `PENDING`, `APPROVED` or `REJECTED`. Rejecting switches the creative off, as the page does; approving does not switch it on. Setting the status the banner already has changes nothing and answers with a message. `APPROVED` and `REJECTED` e-mail everyone the advertiser is shared with. A caller without *Banners Approval* gets `403`, a banner that does not exist or is deleted gets `404`.
- `POST /rest-api/banners/sendToApprove.do` with `bannerIds` moves banners to `PENDING` and answers with the ids that moved (only banners that pass the moderation validation are moved); an id that is no banner, or a deleted one, is refused with `400` and nothing changes.

There is no REST endpoint for site approval, and none for the traffic-quality grid or the validation settings. From an AI assistant over MCP, `api_write` reaches the two calls above and `whoami` reports your *Banners Approval* grant as `may.approveBanners`; see the [MCP server guide](https://epom.com/ad-server/docs/api/mcp.md).

## Per-role notes

- **Administrator** — works *Validation settings* from the admin sidebar; reaches the three
  account tabs only by switching into a network user who holds the grant.

- **Network manager** — sees a queue tab only with *Banners Approval* or *Sites Approval*,
  which are set on **Admin roles & permissions**, not the account-role editor.
- **Publisher, advertiser** — no queues and no **Submit for approval**; they see only the
  Pending or Rejected badge and the rejection email.

Exact grants: see [Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md).

## Related

- [Invalid traffic (IVT) and how Epom flags it](https://epom.com/ad-server/docs/concepts/invalid-traffic-and-risk-scoring.md)
- [Conversion actions](https://epom.com/ad-server/docs/guides/conversions/conversion-actions.md)
- [Rules & platform defaults](https://epom.com/ad-server/docs/guides/admin/rules-and-defaults.md)
- [Statuses & indicators reference](https://epom.com/ad-server/docs/reference/statuses-and-indicators.md)
- [Metrics reference](https://epom.com/ad-server/docs/reference/metrics.md)
- [Troubleshooting: ad not serving](https://epom.com/ad-server/docs/troubleshooting/ad-not-serving.md)