Targeting, filtering & traffic policy
Control what enters,
where it goes and
how far it can scale.
Nexus treats targeting and filtering as operating policy—not a loose collection of checkboxes. Request context, partner identity, quality rules, commercial settings and capacity boundaries are organized around the channel and tenant that own them.
A stronger operating model
Targeting decides relevance.
Filtering protects quality.
Guardrails protect the business.
These are related decisions, but they are not the same decision. Nexus keeps them understandable so commercial, AdOps and engineering teams can agree on why traffic was accepted, rejected, limited or routed.
Source & partner
Member identity, sub-ID and configured endpoint
Request context
Referrer, language and user-agent when enabled
Environment
Browser, operating system, iframe and hosting-related controls
Commercial
Price, filter value, cap and partner policy
Capacity
QPS, maximum requests and channel schedules
Delivery
Load-balancer target, service URL and private server mapping
Control catalog
Configuration surfaces visible in the Nexus platform model.
The exact enforcement behavior depends on the enabled revenue engine and connected delivery services. The control plane validates and distributes approved configuration; it does not pretend every field has identical meaning in every channel.
Request-context controls
Decide which request signals are required and available to downstream traffic logic.
Referrer context
Support request flows that carry referrer information for source-level analysis and policy.
Language context
Capture language as part of the XML request contract when the deployment requires it.
User-agent context
Make the user-agent available for browser, operating-system and environment classification.
Sub-ID context
Preserve partner sub-identifiers so operators can separate sources beneath a single member or affiliate.
Quality and environment filters
Protect the delivery path with explicit checks instead of relying on partner assumptions.
Hosting traffic filter
A configurable control surface for deployments that need to distinguish hosting or data-center traffic.
Iframe filter
A configurable environment rule for identifying or restricting iframe-originated request patterns.
Duplicate-request policy
Global duplicate controls help prevent repeated requests from silently distorting delivery.
IP request ceiling
Bound repeated XML request behavior at the IP level where that policy is enabled.
Volume, QPS and cap governance
Keep traffic growth inside deliberate commercial and infrastructure boundaries.
Channel QPS
Search and XML carry independent QPS configuration rather than sharing an invisible global limit.
Global XML ceiling
A deployment can maintain a global maximum XML QPS boundary for the load-balancing layer.
Maximum requests
Global request ceilings provide another control beyond instantaneous rate.
Member QPS and caps
XML member settings are structured around per-member QPS and cap maps for partner-level governance.
Commercial controls
Keep price and filtering policy close to the channel configuration that uses it.
Search price configuration
Search platform records expose a dedicated price value for the channel.
XML price configuration
Feed operations maintain their own price configuration and can evolve independently from Search.
Channel filter configuration
Search and XML have separate filter values, keeping policy bounded to the relevant engine.
NET and margin context
Product workflows are designed to compare delivery and provider reporting so operators can reason about commercial outcomes.
Reporting dimensions
Turn raw request context into dimensions teams can use when evaluating partners and campaigns.
OS affiliate statistics
The platform model includes a switch for operating-system breakdowns at affiliate level.
Browser affiliate statistics
Browser-oriented affiliate statistics can be controlled independently.
OS campaign statistics
Campaign analysis can be configured to include operating-system dimensions.
Browser campaign statistics
Browser campaign dimensions have a separate configuration surface.
Routing and service boundaries
Control where traffic services run and which infrastructure records the platform is allowed to change.
Endpoint groups
Each Search, CPC/XML, RTB, Video and CPA service entry can identify a load-balancer target, public URL and server set.
Private server mappings
The control plane synchronizes approved service-to-server mappings into documented Redis hashes.
Channel schedules
Search, XML, RTB, Video and CPA background workflows have independent cron enablement flags.
Bounded Redis contract
Administration can read or update only Redis hashes derived from configured service entries—not arbitrary keys.
Why this matters
The advantage is not another filter list. It is governed control across the entire operating path.
Domains, modules, data connections, services and limits belong to an explicit platform record.
Search, XML, RTB, Video and CPA can evolve independently while sharing administration and security boundaries.
Policy reaches approved Redis hashes and remote services through server-side contracts rather than browser credentials.
MCP tools and structured resources let compatible AI clients understand capabilities without guessing from interface labels.