Why filtering is not an option — it’s a competitive advantage


Fraud never sleeps. And that means — neither should you.

Any self-respecting ad platform knows: antifraud is not a “set it and forget it” thing. It’s part of your strategy.

Just enabling filters is not enough. You need to understand how to configure them properly for your business model, traffic sources, and KPIs.

Everything else = budget drain disguised as activity.


In this guide, we’ll break down how to work with IVT Settings in Kaminari Click to:

– avoid wasting money on fake clicks,

– boost traffic quality,

– earn trust from buyers,

– and finally — get analytics that speak your language (not just “what even was that?”).


What is IVT?


In short: IVT (Invalid Traffic) = the kind of traffic you should be ashamed of.

Clicks from bots, proxies, scripts, spoofing, suspicious activity, and so on.

In Kaminari, all of that is divided into categories:

– Crawler

– Spoofing

– Automated

– Incorrect requests

– Bad reputation IP

– Blocked hits

Each category has a tag in the system. It looks neat — but more importantly, it’s useful: you can build analytics, run A/Bs, or even auto-block the most toxic cases.

Why bother customizing IVT?


There’s no one-size-fits-all — and that’s not a bug, it’s a feature.

Everyone has their own risks and rules of the game:

– Push networks don’t stress too much over proxies, but panic at the word “bots.”

– SSPs in RTB ecosystems get hit by data center click attacks.

– Affiliate networks want to see all fraud in reports — but don’t reject it, because reach is more important.


Kaminari gets that. That’s why you have flexibility:

– by threat type,

– by subs,

– by devices, geos, and other details.

You can go full lightning strike — or just mark something as “suspicious, keep an eye.”


Where it all lives: 3 Levels of IVT Control in Kaminari

1. Global Settings

Default rules that apply to all traffic. Think “block everything” or “watch, but don’t touch.”

You can:

– block right away,

– log (but let through),

– marked as suspicious.


2. SubID Overrides

Use this if you manage traffic manually or run A/B tests.

It lets you:

– set exceptions for subs,

– test questionable sources,

– apply custom logic for specific channels.


3. Rules Engine (OnResponse)

Want full control? Here it is.

A rule builder on the level of:

“If the user is from GEO-IN, on Safari 15, with TTFB < 100ms, and scroll-jumps — block them.”


Configuration Algorithm: From Chaos to Control


1. Define what you’re willing to tolerate (and what’s a hard no)

Start by writing your antifraud rules:

– What threats are non-negotiable? (e.g., data centers + bots)

– What can you live with for the sake of volume?

– What should be logged but not blocked — just to monitor?

Example:

“On push, don’t block proxies — but destroy clicks <0.2s from data centers.”


2. Configure Global Settings

Go to Kaminari → IVT Settings → Global:

– Choose what goes straight to the blacklist: automation, fake browsers, empty user-agent.

– Decide what to log only (e.g., proxies, strange behavior).

Minimum setup for most networks:

- Block bots & automation

- Block data centers

- Block clicks without user-agent


3. SubID Overrides — rules for VIPs (or troublemakers)

– Loyal subs? Apply gentle settings.

– New ones? Go full filter mode.

– Anything unclear? Log, don’t block.

Example:

Sub123 brings 15% of traffic, but 70% of suspicious clicks.

Apply override — block click spam and spoofing.


4. Enable logging and notifications

– Auto-reports on filtering activity

– Alerts on fraud spikes

– BI, Sheets, or any tool integration — so data lives where you actually work

Why it matters:

You don’t just see the losses — you know why they happen and how they hit your ROI.


5. Use Rules Engine as a sniper scope

Powerful rules that actually shift your metrics.

Rules Engine works at the on-response stage — after the click is logged, before landing.

That means you’re filtering based on the request, not on-page behavior.

With Rules Engine, you can:

– set conditions using GEO, IP, user-agent, TTFB, proxy, etc.

– combine them using AND/OR

– perform actions:

block the click completely

log (keep it in stats but don’t interfere)

Examples:

– TTFB < 100ms + data center IP → block

– GEO = IN + Safari <16 → log only

This is especially critical if you mix direct and RTB traffic. Without precise setup — your ROI will sink.


FAQ from People Who “Eyeballed” Their Setup


What happens to a blocked click?

It won’t redirect. It will appear as “blocked” in stats, with a reason shown.


How to avoid false positives?

Start by logging. Then block what consistently shows up in reports.

Kaminari lets you filter without paranoia.


Can I set auto-pauses based on triggers?

Yes. Webhooks, reports, auto-stop payments — you’re in full control.


Tips from People Who’ve Already Been Hit by Fraud


– Segment traffic before filtering — dissect it by source.

– Don’t block everything at once — log, test, then cut.

– Use cohort analysis — track how subs behave over time.

– Give clients transparent stats — it’s not just nice, it’s a power move in negotiations.

– Monthly rule reviews = must-have — fraud evolves like trends.


Conclusion


Kaminari Click isn’t a “block fraud” button. It’s a control lever.

Smart IVT setup = better budget use, more trust, and a step ahead of competitors.

Antifraud isn’t about restrictions — it’s about setting the rules of the game your way.


Want to test your setup in a real fight?

Book a demo.

We’ll run a test on part of your traffic and show you:

– where the money’s leaking,

– where you can scale without fear.

No magic.

Just tags, logs, and your profit.