Traffic protection is most useful when every rule has a known input, scope and outcome. A generic fraud score cannot replace the operational controls needed to investigate a publisher, feed or source.
Layer deterministic controls
IP and subnet policy, banned-domain checks, referrer validation, iframe rules and request-rate boundaries provide explainable first-line protection. They can be applied globally or, where the connected engine supports it, scoped to a particular feed.
- IP and subnet policy
- Domain and referrer checks
- Iframe and environment rules
- QPS, caps and duplicate controls
Inside Nexus / configuration example
The Search link editor groups referrer and IP policy with network-risk categories. Third-party pre-bid checks require their own configured integration; a visible switch is not evidence of perfect detection.
Review traffic-quality checks
Review referrer and IP policy alongside datacenter, crawler, attack-source, Tor, scraper and VPN controls.
Captured from a new, unsaved Search link. The displayed switches are editor defaults; no traffic policy was changed for this screenshot.
Add behavioral and network signals
Bot confidence, anonymous or transparent proxy indicators, unexpected IP changes and source inconsistencies can contribute additional evidence. Detection strength should be tuned against false positives rather than treated as a universal maximum setting.
Preserve an operator decision path
Trusted-partner exceptions, blocked-traffic outcomes and human-verification steps need an audit trail. Operators should be able to explain whether traffic was rejected by identity, environment, repetition, capacity or quality policy.
This guide describes Nexus product architecture and general AdTech operating concepts. Exact enforcement and integration behavior depends on the enabled revenue engine and agreed deployment configuration.