<b>Blacklists в CPA — не «чёрный список», а ранний сигнал, который многие читают слишком поздно</b>

<b>Blacklists в CPA — не «чёрный список», а ранний сигнал, который многие читают слишком поздно</b>

Blacklists обычно полезны не как «приговор», а как слой фильтрации. Один список сам по себе ничего не доказывает: он может быть старым, неполным или собранным по слишком грубым признакам. Но игнорировать его — значит добровольно пускать в кабинет уже знакомые паттерны фрода.

Смотреть надо не на факт попадания, а на совпадение признаков:
— одинаковые IP/ASN, массовые домены-однодневки;
— аномальная связка click → install → event без нормальной задержки;
— повторяющиеся user-agent, device fingerprint, subID;
— кластеры по времени, где трафик идёт рывками и «ровно» для машинной активности.

Если blacklist используется внутри сети, проверьте, как он собирается:
— по каким сигналам добавляют источник;
— есть ли ручная валидация;
— как быстро список устаревает;
— можно ли увидеть причину блокировки, а не только сам статус.

Для команды закупки важнее не «спорить с баном», а построить свой внутренний контур:
— сверять blacklist с postback-аномалиями;
— держать белый список проверенных связок;
— не пускать свежие источники сразу в полный объём;
— отдельно смотреть на повторяемость крео и лендингов, если фрод маскируется под разные аккаунты.

Blacklists работают только вместе с логами, атрибуцией и здравым смыслом. Если источник выглядит подозрительно в трёх независимых местах, список уже не просто список.