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

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) 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). Full formulas: the metrics reference.

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) 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). 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
• Analytics metrics reference
• Targeting dimension reference
• Protect your inventory from bad creatives and bad traffic
• How ad selection works
• Glossary