Demand feeds do not have identical schemas, response times, commercial terms or traffic acceptance. Treating them as interchangeable endpoints hides the decisions that determine margin and delivery quality.
Configure the feed contract
Each connection needs an understood parser, timeout, result limit, eligible targets and commercial behavior. Reusable feed profiles help teams apply a tested operating pattern across approved partners.
- Parser and schema
- Timeout boundary
- Result limit
- Allowed targets
Inside Nexus / configuration example
The XML feed Settings tab shows the provider URL import, feed type, SubID handling, result count and timeout. These are connection and delivery settings; traffic eligibility is configured separately in Targets.
Review feed delivery settings
The Settings tab brings URL import, feed type and SubID handling together with revenue share, result count and timeout.
This is a new, unsaved XML feed. The provider URL is a placeholder and the numbers are editor defaults. Detection and format support depend on the configured provider integration.
Define eligible feed traffic
Use the XML feed Targets tab for geographic, device, browser, domain, carrier, keyword and subscriber-age criteria. Match the enabled criteria to the request context and traffic contract supported by that provider.
Inside Nexus / configuration example
The XML feed Targets tab exposes countries, operating systems, browsers, devices, domains, carriers, keywords and subscriber-age criteria.
Define feed eligibility
Configure countries, operating systems, browsers, devices, domains, carriers, keywords and subscriber-age criteria in the feed editor.
Shown in a new, unsaved XML feed. The provider URL is an example placeholder. Feed format and provider compatibility depend on the configured integration.
Control bids and volume at the right level
Platform ceilings protect infrastructure, feed limits protect provider contracts and publisher ranges protect commercial relationships. Individual exceptions should be deliberate, bounded and visible to the team responsible for reconciliation.
Inside Nexus / configuration example
The Limits tab separates minimum bid, requests and QPS from daily budgets, click caps, per-IP rules and result expiry. These operating limits are not pricing-plan entitlements.
Keep limits explicit
Review minimum bid, request and QPS limits, daily budget, click caps, per-IP rules and result expiry separately from targeting.
Shown in a new, unsaved XML feed. The provider URL is an example placeholder. Feed format and provider compatibility depend on the configured integration.
Route in parallel without losing governance
Parallel provider requests can improve coverage, but only when they remain inside latency, QPS and eligibility boundaries. The response path still needs deterministic ranking, deduplication, error classification and reporting.
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.