# Blocking networks and refund evidence

Once AdPix has found a network invalid, two things remain: stop the next spend, and get the spent money back. For the first there are exclusion lists ready to import into Google Ads and Meta; for the second there is a sealed evidence packet you attach to a refund claim.

## Two exports, two different jobs

In **Fraud Protection**, on the **Networks** tab, a card titled **Block these networks** carries the ad-platform exports. What you get from here is two families of file, and they do different work.

| File | What it is for | What is in it |
| --- | --- | --- |
| Google Ads exclusions | stopping the next spend | `/24` blocks in wildcard form, ready to import into a campaign's excluded IPs |
| Meta advisory | stopping the next spend | the networks themselves (ASNs), because Meta has no native IP exclusion |
| Generic list | stopping the next spend | the same blocks as CIDRs plus the network details, for a firewall or CDN |
| Refund evidence | recovering the spend | sealed findings + a conservative waste estimate + a per-row hash |

All four carry only networks scored **Confirmed** or **Potential**. Anything still sitting at **Review** — meaning the engine did not have enough evidence to decide automatically — never reaches these files. That is deliberate: the file you hand to an ad network must not contain a guess.

The three blocklists are bounded by the **date range selected on the page**. The refund-evidence file is not: it returns the property's whole sealed ledger, and each row carries the window it was sealed for. Only its wasted-spend column is computed against the range you have selected.

The **Block these networks** card is shown when those exports are available on your installation, not when something has been flagged — before the first scoring run the files come back with a header row and nothing under it.

## Google Ads IP exclusions

**Google Ads IP exclusions (CSV)** gives you a file with a single column named `IP address`, one `/24` block per row in the form `203.0.113.*`. That is the shape Google Ads accepts in a campaign's excluded-IP list.

Rows are ordered busiest first and capped at 500, because 500 per campaign is Google's own limit. If the range holds more than 500 distinct blocks, the response carries an `X-AdPix-Blocklist-Truncated` header with the number left out — a number that does not appear inside the CSV itself, so if you suspect the coverage is partial, shorten the range and export again.

> **Each row is 256 addresses**
>
> A `/24` exclusion closes the whole block, not one IP. The AdPix classification is deliberately conservative — a network that converts is never flagged, and mobile-carrier and residential ISPs are only flagged on a hard structural signal — but the import is your call. If this is your first time, take the generic list first, sort by the network-type column, and start with data centers and proxies.

## The Meta advisory

Meta has no campaign-level IP exclusion, so **Meta exclusions (CSV)** is not an IP list; it is a list of the networks themselves. Each row is one network-and-channel pair with the columns `asn`, `asn_org`, `network_type`, `channel`, `severity`, `flagged_sessions`, and a `recommendation` column.

There are two things to do with it: exclude those networks through the campaign's placement and audience controls, or filter events coming from them server-side before you send them to the Conversions API. This file has no 500 cap and is ordered by session count.

## The generic list for a firewall or CDN

There is a third export with no button in the console, taken straight from the API:

```
GET /api/v1/integrity/blocklist.csv?site=<property_id>&from=<YYYY-MM-DD>&to=<YYYY-MM-DD>&cap=1000
```

Its columns are `cidr`, `wildcard`, `asn`, `asn_org`, `network_type` and `hits` — the same blocks plus which network each belongs to and how many events came from it. This is the file you feed to a firewall, Cloudflare or a CDN list. The `cap` parameter defaults to 1000 and accepts 1 to 5000; anything outside that falls back to 1000.

On the outbound side there is also a destination type called `fraud_blocklist` that pushes the list to an external sink, riding the same delivery, retry and dead-letter path as any webhook. It has no console screen yet; the exports above are the supported route today.

## The refund-evidence file

This is the file you hand to the ad network. On the **Networks** tab, select a network to open its detail drawer; **Download evidence (CSV)** sits at the top of it.

| Column | Meaning |
| --- | --- |
| `asn` · `asn_org` · `network_type` | the network the finding is about |
| `channel` | the channel the traffic arrived on |
| `severity` | the verdict tier — Confirmed or Potential |
| `flagged_sessions` | how many sessions the finding covers |
| `window_from` · `window_to` | the range the finding is based on |
| `estimated_wasted` · `currency` | the estimated wasted spend and its currency |
| `reasons` | the same reasons shown in the network drawer, in plain language |
| `sample_ips` | real IPs from that window, taken from the sealed evidence |
| `evidence_hash` | that row's chain hash |
| `chain_verified` | whether the property's whole chain was intact when the file was built |

The waste estimate is deliberately conservative: the channel's spend multiplied by the flagged sessions' share of **all** of that channel's true sessions. The denominator is the real session count, not a sample of it, so the number under-states rather than over-states. Spend is read from the ad cost you imported yourself, and the currency is the most common one in that range; with no cost imported, the column stays zero.

> **The file covers the whole property, not just the network you opened**
>
> The button lives in one network's drawer, but the file holds every sealed finding that property has, back to its first scoring run — the page's date range does not narrow it. To claim for one network and one period, filter on the `asn`, `window_from` and `window_to` columns in your spreadsheet — and leave the hash of every row you keep exactly as it is, because that hash is what can be checked.

## The evidence ledger, and what it is for

Behind that file is a ledger, not a report. Every time the nightly scoring run executes, each flagged network is appended to that property's ledger as an **immutable** row. Nothing is overwritten or merged; every seal is a new row.

Tamper evidence comes from a hash chain: each row's hash is built from the previous row's hash plus that row's own content, and the first row of each property starts from a fixed genesis value. Editing or deleting any past row invalidates the hash of every row after it.

What the chain protects is a deliberate selection: the sequence number, the date, the network and channel, the verdict tier, the session counts, the sample IPs, the reasons, and the window. The model's floating-point scores are deliberately excluded: bit-for-bit reproduction of a float is not guaranteed, and a chain that breaks for no reason is worthless. Sealing and verification are two separate systems producing exactly the same bytes — that separation is what makes the check mean anything.

Every time this evidence is read — in the network drawer, or while the refund file is being built — the whole chain is recomputed and compared. The result comes back as two values: whether the chain is intact, and if it is not, the first sequence number that failed.

### What it proves and what it does not

- **It proves** the record has not changed since it was sealed — not by you, and not by anyone else. A hand-built spreadsheet cannot say that.
- **It proves** each row is tied to one window, one network, a session count and a specific set of reasons, and was not assembled after the fact to fit a claim.
- **It does not prove** that the ad network owes you a refund. Each network's policy is its own.
- **It is not a third-party attestation.** It is the AdPix ledger with tamper evidence, not the signature of an independent auditor.

## One refund claim, end to end

1. Set the page's date range to the exact period you are claiming for — the blocklists follow it, and it is the range the wasted-spend figures are computed against.
2. Open **Fraud Protection → Networks** and read the wasted-spend figure and the channel × network table.
3. Select the main networks and read their reasons and detector scores; if you cannot explain the reasons, do not file the claim.
4. Download **Download evidence (CSV)** and filter it down to the networks and the window you are claiming for, without touching the hash column.
5. Download **Google Ads IP exclusions (CSV)** and import it into the campaign's excluded-IP list so the spend stops.
6. Attach the evidence file, the invoice number and the date range to the ad network's dispute ticket or form.

To dispute a single traffic slice rather than a network, that entity's drawer has **Download dispute evidence**. That file carries the verdict summary, the reasons, each detector's score and the network context, and is written in an encoding that opens cleanly in Excel. Cross-business signals appear only as counts and no other organisation's identifiers are disclosed; if your access to revenue data is restricted, the conversions field reads `[restricted]` instead of a number. Downloading it counts as a sensitive read and is written to the audit log.

## When a file comes back empty

- **The Google Ads file is empty** — no Confirmed or Potential network with resolvable IPs in this range. Widen the range.
- **The wasted-spend column is zero** — no ad cost imported for the range, or the channel names do not reconcile to the AdPix taxonomy. Start with [Importing ad cost](analytics/marketing/import-ad-cost).
- **The chain is not intact** — the ledger was altered or a row deleted outside the normal path. The ledger is append-only by design, so this needs investigating; the sequence number reported is the point of first divergence.

## Frequently asked questions

### Why does the Google Ads file only have 500 rows?

Because Google Ads itself accepts at most 500 IP exclusions per campaign. AdPix respects that cap and puts the busiest `/24` blocks first, so the 500 rows you import are the ones that matter. If there were more, the response carries an X-AdPix-Blocklist-Truncated header with the number of blocks left out.

### What exactly does the evidence chain prove?

It proves these findings have not been altered since they were sealed — not by you, not by anyone. Each row is built from the hash of the row before it, so editing or deleting any past row breaks every later row, and AdPix reports that on read. It is not a third-party attestation and it does not oblige an ad network to refund you; it is an auditable record that makes your claim checkable.

### Why is the wasted-spend column zero when networks are flagged?

Either no ad cost is imported for that range, or the channel names in your cost data do not reconcile to the AdPix channel taxonomy. Import the cost and map the raw channel name to a canonical channel.

### Does blocking a whole `/24` also catch real users?

The export only carries networks scored Confirmed or Potential, and the scorer excludes converting networks and mobile-carrier or residential ISPs before this stage. Each row is still 256 addresses, though; before importing, look at the network-type column and start with data centers and proxies.

## Related

- [Network and ASN fraud](https://docs.adpix.io/en/analytics/fraud/networks-and-asn/)
- [Ad spend wasted — what the number actually is](https://docs.adpix.io/en/analytics/fraud/money-wasted/)
- [Why was this flagged](https://docs.adpix.io/en/analytics/fraud/why-was-this-flagged/)
- [Import ad cost](https://docs.adpix.io/en/analytics/marketing/import-ad-cost/)

---

[Docs](https://docs.adpix.io/en/analytics/fraud/blocklist-and-refund-evidence/) · AdPix