---
title: "Invalid traffic (IVT) and how Epom flags it"
description: "What invalid traffic is, the industry GIVT/SIVT split, and how it maps onto Epom's rejected-event counters, the per-request risk level and score, the Traffic Quality placement score, and Traffic Risk Score targeting."
type: "concept"
audience: [network-manager, admin]
keywords: [invalid traffic, IVT, GIVT, SIVT, bot traffic, fraud, risk score, risk level, risk category, rejected impressions, traffic quality, Pixalate, eligible impressions, crawlers, headless browsers]
---

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.

# Invalid traffic (IVT) and how Epom flags it

**Invalid traffic (IVT)** is any ad activity not produced by a real person genuinely seeing the
ad: bots, crawlers, datacenter machines, click farms, spoofed apps, hijacked sessions. It is the
reason your reported numbers and your *paid* numbers diverge — buyers and audit partners refuse
to pay for it and claw it back, so a network that can't see its own invalid traffic gets billed
for the surprise later. This page maps the industry IVT vocabulary onto the concrete places
Epom exposes it, and clears up which Epom feature does what.

## GIVT vs SIVT — the industry split

The IAB splits invalid traffic into two tiers by how hard it is to detect:

- **GIVT (General Invalid Traffic)** — the obvious stuff, catchable by known lists and simple
  rules: declared bots and spiders, known data-center IPs, activity with no/blank user agent,
  IAB-listed crawlers. Cheap to filter; nobody argues it's real.
- **SIVT (Sophisticated Invalid Traffic)** — the deliberate stuff engineered to look human: app
  spoofing, hijacked devices, cookie stuffing, incentivised click farms, location obfuscation,
  auto-refresh fraud. It needs behavioural analysis and third-party detection.

> **Note:** GIVT and SIVT are an **industry taxonomy**, not Epom labels — Epom does not print
> "GIVT" or "SIVT" anywhere in the UI. The split is useful for a shared vocabulary; below, each
> tier is mapped to the Epom surfaces that actually correspond to it.

## Two separate systems — don’t conflate them

Epom has **two** independent fraud/quality mechanisms. Confusing them is the most common
mistake here:

| System | Protects | Scans | Where |
|---|---|---|---|
| **Traffic quality / risk scoring** | Your **supply** (inventory) against invalid *traffic* | The visitor/request — is this a bot, proxy, spoofed device? | Risk score metric, Risk Level / Category dimensions, Traffic Quality page, Traffic Risk Score targeting |
| **DSP creative scan** | Your auctions against malicious *creatives* | The DSP's ad markup — malware, forced redirects, policy breaches | [Creative policy protection](https://epom.com/ad-server/docs/use-cases/creative-policy-protection.md) |

This page is about the **first** system — invalid *traffic*. Creative scanning is a different
concern (a bad ad, not a bad visitor) and lives on its own page.

## How Epom flags invalid traffic

Epom's invalid-traffic handling shows up in three distinct places, each doing a different job.

### 1. Validation drops invalid events → the "Rejected" counters

Before anything reaches your headline numbers, the network-wide **Validation settings**
([Moderation & quality](https://epom.com/ad-server/docs/guides/admin/moderation-and-quality.md)) refuse or flag events that
fail integrity checks — click checks, the impression auto-ban and IP blacklist, the
impression-signature check, and duplicate-conversion rejection. (The three *Match … with ad
request* boxes only stamp a marker on the raw record and reject nothing.) A flagged click, for
example, is kept out of the General report and recorded as rejected in the analytics logs, so
you can still see it, in dedicated columns on the Advanced report:

| Counter | What it holds |
|---|---|
| **Rejected impressions** | Impressions flagged invalid |
| **Rejected clicks** | Clicks flagged invalid |
| **Rejected conversions** | Conversions flagged invalid (also "Conv. fraud" on the General report) |
| **Rejected passbacks** | Passback events that missed or were fraudulent |

The key consequence is in the **eligible** figures. The Advanced report's rates are computed
on *eligible* events, which are total minus rejected:

```
eligible impressions = max(0, deliveries − matched passbacks − rejected impressions)
eligible clicks       = max(0, total clicks − rejected clicks)
eligible conversions  = max(0, total conversions − rejected conversions)
```

So a healthy filter *lowers* your reported eligible volume on purpose — that gap is exactly the
invalid traffic you are not being paid for. This is also why eCPM, the effective CTR and the
fill rates on the Advanced report use the eligible numbers, not the raw ones. The General report
divides by its own impression counter instead, so the two types can differ for the same traffic
([why](https://epom.com/ad-server/docs/concepts/analytics-pipelines-explained.md)). Full formulas: the
[metrics reference](https://epom.com/ad-server/docs/reference/metrics.md#advanced-hadoop-report).

> **Corner case:** rejected impressions are subtracted from *eligible* impressions, and eCPM
> divides money by eligible impressions. A rise in your invalid-traffic rate therefore *raises*
> reported eCPM (same money over fewer eligible impressions) even though nothing about your
> pricing changed. Don't read an eCPM bump as a demand improvement without checking the rejected
> counters.

### 2. The risk level and the Risk score metric — per-request risk

A risk-scoring integration assigns each request, by its IP, a **risk level** and, when it
recognises one, a **risk category**. These are the **Risk Level** and **Risk Category**
dimensions on the Advanced report (filterable and, on networks with full logs, groupable) and
the values the Traffic Risk Score targeting rule compares against. The levels are bands of the
integration's fraud probability:

| Level | Probability band |
|---|---|
| Not scored | below 0.01 |
| Low | 0.01 – 0.5 |
| Likely | 0.5 – 0.75 |
| High | 0.75 – 0.9 |
| Very high | 0.9 – 1.0 |
| Certain | 1.0 and above |

(*Disabled* and *Error* also exist as system values, for a request the integration could not
score.)

The **Risk score** column on the Advanced report summarises a group of traffic in one number:

```
Risk score = risk sum ÷ (eligible impressions + eligible clicks)
```

It is an impression-and-click-weighted average of the per-request risk the integration assigned,
so a placement full of bot traffic scores high and a clean one scores near zero. It tells you
*where* the risk concentrates; it does not itself drop the traffic.

The categories are concrete detection reasons — and this is where the GIVT/SIVT vocabulary
lands:

| Tends toward… | Example risk categories the integration reports |
|---|---|
| **GIVT** (obvious) | Datacenter, datacenter proxy, IAB-recognized crawlers/bots, IAB dummy bot, blank user agent, TOR |
| **SIVT** (sophisticated) | App spoofing, device-ID stuffing, hijacked session, cookie stuffing, click farm, location obfuscation, auto-reloader, fast clicker, publisher fraud |

> **Note:** the GIVT/SIVT column above is an *interpretation* to bridge the vocabulary. Epom
> stores each detection as a named risk category, not as a GIVT/SIVT tag — treat the mapping as
> guidance, not a field you can filter on.

### 3. Traffic Quality — a score for each placement

The **Traffic Quality** page ([Moderation & quality](https://epom.com/ad-server/docs/guides/admin/moderation-and-quality.md))
is a different thing from the per-request risk level above. For each placement and scan date it
computes its own **score** from that day's impressions and clicks and bands the score into a
**level**:

| Level on the page | Score |
|---|---|
| Clean | 2 or less |
| Suspicious | 3 – 5 |
| Fraudulent | 6 – 9 |
| Blocked | 10 or more |

The page also shows an estimated fraud-spend figure and a downloadable per-placement PDF as
evidence. The risk percentages are taken over the impressions
the risk integration actually scored: on a network without it they are not computed and do not
count as flagged.

## Excluding risky traffic before it serves

The systems above *observe and score* invalid traffic. To *refuse* it up front, use the
**Traffic Risk Score** targeting dimension ([Targeting dimensions](https://epom.com/ad-server/docs/reference/targeting-dimensions.md#risk)).
A rule picks a **risk level** with a relation (default `>=`) and optionally a **risk category**;
matching requests are targeted (Include to serve only them, Exclude to keep them out). Because it
runs during the ad-selection pipeline, an Exclude rule drops the request before any billable
serve, and — unusually for a targeting dimension — it is even evaluated for external DSP demand.

> **Corner case:** when the risk-scoring service can't classify a request — feature disabled, a
> service error, or simply no data for that IP — a Traffic Risk Score rule **does not match**.
> An Include rule ("serve only Low-risk traffic") therefore silently *excludes* every
> unscoreable request, which on a test network or an uncovered IP range can look like the ad
> "not serving." Confirm your traffic is actually being scored before tightening this rule.

## Which external anti-fraud (IVT) providers are integrated?

One: **Pixalate**, the third-party traffic-risk service behind the **Risk score**,
**Risk level** and **Risk category** values, the Traffic Risk Score targeting rule and the
*risk-flagged* indicator of Traffic Quality. It is connected and switched on by Epom support as
a server-side setting — there is no setting for it in the account or admin UI, and it is off
until it is enabled for your network (with it off, those fields stay empty and Traffic
Risk Score rules do not match). The proxy indicators of Traffic Quality come from the ad
server's IP data, not from Pixalate.

Other vendors (HUMAN, DoubleVerify, IAS and the like) have no built-in integration. You can
still run their measurement tags inside your creatives or as third-party trackers, but their
verdicts do not feed Epom's targeting or reports.

## How do I check whether a publisher’s traffic is fake or fraudulent?

Start from the data you already have before asking anyone to investigate:

1. **Account → Traffic Quality** (needs the Traffic Quality tab and *Traffic Quality Reports*
   permissions): find the publisher's placements for a recent scan date and set **Level** to
   all levels, not just the default *Fraudulent + Blocked*. The indicator columns say *why* a
   placement scored as it did.
2. **Generate report → Download PDF** on the row for the per-placement evidence to share with
   the publisher. It is built in the background; the row changes to *Download PDF* when ready.
3. **Advanced report** grouped by **Placement** with the **Risk score** column, then by
   **Device format**, **Is Web App**, **Operating system** or **Risk category**. Traffic that is
   "real but not what was sold" — mostly in-app web views, TV boxes or a single OS version —
   shows up here rather than as fraud.
4. **Act on it**: exclude the placement, or add a **Traffic Risk Score** Exclude rule (next
   section), or target only the device formats you want.

A placement with very few impressions on the scan date gives unstable percentages; judge it
over several days.

## Why reported and eligible numbers diverge — a checklist

When someone asks "why is my paid volume lower than my reported volume?", walk these in order:

1. **Rejected counters** on the Advanced report — the raw size of the invalid slice per event
   type.
2. **Eligible vs total** — eligible impressions/clicks/conversions are what you rate on; the gap
   is the rejected slice.
3. **Risk score** per group — which placements/countries carry the risk.
4. **Traffic Quality level** for the worst placements, with the PDF report as evidence for a
   publisher conversation.
5. **Targeting** — whether a Traffic Risk Score Exclude rule is (or should be) trimming the
   traffic before it serves.

## Related

- [Moderate banners, sites and traffic quality](https://epom.com/ad-server/docs/guides/admin/moderation-and-quality.md)
- [Analytics metrics reference](https://epom.com/ad-server/docs/reference/metrics.md)
- [Targeting dimension reference](https://epom.com/ad-server/docs/reference/targeting-dimensions.md)
- [Protect your inventory from bad creatives and bad traffic](https://epom.com/ad-server/docs/use-cases/creative-policy-protection.md)
- [How ad selection works](https://epom.com/ad-server/docs/concepts/how-ad-selection-works.md)
- [Glossary](https://epom.com/ad-server/docs/reference/glossary.md)