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.

01

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
XML feed contractConfiguration guide
  1. 01 / CONTEXT

    Configure the provider connection and response contract before setting traffic eligibility.

  2. 02 / SUPPORTED CONTROLS
    • Provider URL / feed type
    • SubID handling
    • Result count / timeout
  3. 03 / REVIEW

    Validate the provider adapter and response format. Targeting is configured separately.

Illustrative configuration, not a live account. Adapter support and response formats are integration-specific. Traffic-quality rules do not guarantee detection of every invalid interaction.
02

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.

XML feed eligibilityConfiguration guide
  1. 01 / CONTEXT

    Qualify request context using the fields available to the selected integration.

  2. 02 / SUPPORTED CONTROLS
    • Country / OS / browser
    • Device / domain
    • Carrier / keyword
    • Subscriber age
  3. 03 / REVIEW

    Review mappings and supported request signals before enabling traffic.

Illustrative configuration, not a live account. Adapter support and response formats are integration-specific. Traffic-quality rules do not guarantee detection of every invalid interaction.
03

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.

XML bid & volume policyConfiguration guide
  1. 01 / CONTEXT

    Keep price boundaries, request capacity and repeated-click rules distinct.

  2. 02 / SUPPORTED CONTROLS
    • Minimum bid
    • Requests / QPS
    • Daily budget / click caps
    • IP / IP + user-agent
    • Result expiry
  3. 03 / REVIEW

    Review the applicable feed and affiliate configuration alongside traffic and NET reports.

Illustrative configuration, not a live account. Operating settings are not pricing-plan entitlements. No sample values or traffic policy are applied by this illustration.
04

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.

Product accuracy

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.

Published by Nexus Soft.

Content revised

Sources and product scope

Product references describe available controls and their limits. Examples are illustrative.