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.

Map your traffic policy ↗View the architecture
NEXUS / POLICY ENGINECONFIGURATION VIEW
REQUEST CONTEXT
REFERRERLANGUAGEUSER AGENTSUB-ID
QUALITY FILTERS
HOSTINGIFRAMEDUPLICATESIP LIMITS
DELIVERY GUARDRAILS
QPSCAPSPRICEROUTES
Tenant policy remains server-side and bounded

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.

01

Source & partner

Member identity, sub-ID and configured endpoint

02

Request context

Referrer, language and user-agent when enabled

03

Environment

Browser, operating system, iframe and hosting-related controls

04

Commercial

Price, filter value, cap and partner policy

05

Capacity

QPS, maximum requests and channel schedules

06

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

Tenant-aware

Domains, modules, data connections, services and limits belong to an explicit platform record.

Channel-specific

Search, XML, RTB, Video and CPA can evolve independently while sharing administration and security boundaries.

Infrastructure-aware

Policy reaches approved Redis hashes and remote services through server-side contracts rather than browser credentials.

AI-discoverable

MCP tools and structured resources let compatible AI clients understand capabilities without guessing from interface labels.

Turn your targeting rules into an operating system your whole team can understand.

Design your control model ↗