An XML ad network connects publisher traffic with agreed advertiser feeds. The operating challenge is to make each relationship explicit: which source may request results, which demand may answer, what context must survive the connection, which limits apply and how both parties will measure the outcome. XML describes a data format; it does not establish a universal feed schema or guarantee demand access.
Start with the publisher and demand contract
List the approved publisher source and the advertiser feed it will use. Agree on required request context, result fields, click tracking, timeouts and reporting responsibility before connecting them. Nexus provides affiliate integration settings, provider/feed configuration and explicit affiliate-to-feed assignments. A provider name or XML URL is not proof that an adapter accepts every variation of that provider’s response.
- Publisher identity and source/SubID conventions.
- Provider response fields, image/icon requirements, result count and timeout.
- Commercial agreement, accepted traffic types and reporting update window.
Illustrative mapping: one source, two feeds
Suppose publisher Cedar has two sources, search-panel and news-widget. Feed A accepts the approved search traffic; Feed B has a separately agreed contextual integration. Write those relationships into a planning matrix before configuration. Mapping a feed to Cedar does not automatically prove that every Cedar source is eligible. Check the available resource-level targeting and the provider contract for each path. These names are fictional planning labels, not real integrations or Nexus API parameters.
- Cedar / search-panel → Feed A → agreed search response and click contract.
- Cedar / news-widget → Feed B → separately validated contextual delivery.
- Unexpected source → investigate identity and eligibility before enabling demand.
Separate eligibility, rate and commercial limits
Nexus XML feed editors expose geographic, device, domain, keyword, carrier and subscriber-age targeting where the integration supplies the relevant context. Limits include maximum requests/QPS, daily budget, click ceilings, repeated-click rules and result expiry. These controls answer different questions. A rate limit bounds request flow, a click cap bounds counted activity and a budget constrains the commercial allocation. Their configured values are not a published hosting-capacity guarantee.
Exercise the route before increasing traffic
Use synthetic or appropriately redacted samples to check a valid response, an empty response, malformed data, a timeout and a repeated click. For each case, agree on the expected result and the report or integration log that will demonstrate it. Inspect provider settings and affiliate mapping independently. Confirm parser behavior, tracking and fallback handling with the actual adapter; this guide does not define a copy-and-paste production request.
- Valid path: the intended source reaches the approved feed with required context intact.
- Empty or slow path: the agreed response and any configured backfill can be explained.
- Invalid or repeated activity: the selected controls are tested with both legitimate and rejected samples.
Read both sides of the reporting relationship
Begin with the same date range, affiliate, feed and available SubID or domain breakdown. Compare requests, valid requests, errors, coverage, clicks and revenue before looking at imported NET fields. Nexus exposes affiliate-side and feed-side reports and separate provider NET import settings. A difference may reflect timing, attribution, filtering or scope; it is not sufficient evidence of fraud or a billing error.
A useful handover has explicit acceptance checks
Document who owns each connection, which samples passed, which limits were agreed, the provider update window and the escalation path for a mismatch. Keep pending integrations and unsupported placements visible. Pop, contextual and push delivery require their corresponding provider and delivery setup; enabling XML alone does not enable every advertising format. Bring the first source and demand agreement to discovery so the initial network can be scoped concretely.
Illustrative capacity across two locations
For one platform with XML at 1,000 incoming QPS in US and 2,000 in EU, with no optional add-ons, capacity costs $1,500 per month. The first full month totals $3,000, including the one-time $1,500 platform setup. This is an illustrative configuration, not a customer result or a traffic guarantee.
- US: $500/month; maximum 10,000,000 clicks/day. EU: $1,000/month; maximum 20,000,000 clicks/day. These are separate location limits, not a shared 30-million-click pool.
- RTB, Video, Search and CPA receive no capacity from this XML allocation; each selected module is priced separately.
- Published USD prices are final and include hosting, white-label branding and applicable taxes, with no hidden fees. Any additional work must be priced and agreed upfront. The in-platform AI add-on also includes model usage; no unlimited-token allowance is promised.
- The example assumes unchanged capacity for a full month. QPS capacity can be increased or decreased at any time in the published increments. Charges are prorated for the time each capacity is active. The calculator shows full-month rates, not a partial-period invoice or an automatic overage charge.
Worked example: when clicks change the XML allocation
Synthetic worked example. All traffic counts and timings below are authored test inputs, not customer data, measured platform performance or promised results. For a synthetic planning day, assume US peaks at 760 incoming QPS with 11,200,000 clicks, and EU peaks at 1,350 incoming QPS with 8,400,000 clicks. Starting with US 1,000 / EU 2,000 QPS costs $1,500/month, but US exceeds its separate daily click allowance. US 2,000 / EU 2,000 QPS satisfies both planning inputs at $2,000/month. These are independently priced locations on one XML platform, not pooled capacity or measured customer traffic.
Synthetic data · interactive worksheet
Synthetic worked example. All traffic counts and timings below are authored test inputs, not customer data, measured platform performance or promised results.
US daily click allowance is insufficient
- Capacity
- $1,500/month
- First full month
- $3,000
| Location | Assumed daily demand | Purchased allocation | Monthly charge |
|---|---|---|---|
| US | 760 peak incoming QPS; 11,200,000 clicks/day | 1,000 incoming QPS; 10,000,000 clicks/day maximum | $500/month |
| EU | 1,350 peak incoming QPS; 8,400,000 clicks/day | 2,000 incoming QPS; 20,000,000 clicks/day maximum | $1,000/month |
Calculation. US: 11,200,000 assumed clicks − 10,000,000 allowed = 1,200,000 above the daily allowance, even though 760 incoming QPS is below 1,000. EU needs two QPS blocks for its assumed 1,350 peak; spare EU clicks cannot cover US.
Meeting these authored planning inputs is not a throughput, availability or traffic guarantee. Outgoing QPS is not added to the incoming-QPS bill; technical and partner limits still apply.
Build your own XML configuration ↗- Use peak incoming QPS and daily clicks separately; a daily average is not evidence of the peak.
- Each XML or RTB module and each location has its own allocation. Video has no published XML/RTB daily-click allowance.
- These are full-month rates with no add-ons, hosting, white-label and applicable taxes included. Mid-month changes are prorated for the time each allocation is active; this worksheet is not an invoice.
- Reaching the daily click limit currently triggers no automatic action. Arrange the required capacity increase with Nexus; no automatic overage fee is assumed.
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.