Start with who you serve and which decision you need to control. A publisher needs a route to eligible demand. An advertiser needs a way to buy suitable opportunities. A network connecting the two needs partner access, trading rules and comparable reports. These responsibilities can share infrastructure, but they are different operating products.
Supply-side platform
An SSP represents publisher inventory and helps connect available opportunities to buyers. In a deployment discussion, identify the publisher or supply relationship, the inventory allowed into the system and the downstream parties eligible to receive it. Access to a protocol endpoint does not by itself establish the commercial right to trade that inventory.
- Publisher integration
- Inventory policy
- Supply quality
- Outbound QPS
Demand-side platform
A DSP serves advertiser buying requirements: which campaign may buy, from which supply, under which targeting, budget, creative and measurement rules. Nexus describes its DSP option as an integration-scoped combination of campaign management and the RTB runtime. The advertiser interface, bidding strategies, attribution, billing and specific exchange access must be validated separately.
- Campaign eligibility
- Audience and context
- Budget control
- Bid decision
Ad exchange
An exchange connects supply and demand relationships and applies the agreed trading rules. The Nexus exchange workflow exposes exchange connections, demand connections, demand grants, inventory rules and trading reports. The OpenRTB protocol standardizes communication between inventory suppliers and buyers; it does not supply publisher contracts, demand relationships or an advertiser business model.
Illustrative decision: exchange or DSP?
Imagine a network with two approved supply partners and three contracted demand endpoints. Its first need is to decide which demand may receive each source and investigate traffic and trading results: begin with exchange scope. If its customers instead need to create campaigns, upload creatives and buy from a defined set of exchanges, begin with DSP scope. These fictional partner counts describe a planning exercise, not a Nexus customer or included partner bundle.
- Exchange brief: supply access, demand grants, supported formats and reporting ownership.
- DSP brief: advertiser workflow, campaigns, creative review, buying connections and event definitions.
- Combined brief: document both roles and the boundary between the campaign and trading workflows.
Validate the message and timing contract
The IAB OpenRTB 2.6 specification defines tmax as the time the exchange allows for receiving bids, including network latency. That deadline is an input to integration design, not a Nexus speed guarantee. Agree on the protocol version, required context, creative formats, no-bid behavior, delivery events and expected response timing with each partner. Test representative accepted, rejected, slow and unavailable paths before increasing traffic.
- Record the fields the supply actually sends and those the buyer requires.
- Keep bid responses, delivery events and commercial reconciliation as separate checkpoints.
- Treat a version selector as configuration evidence; confirm interoperability with partner tests.
Bring one concrete workflow to evaluation
A useful evaluation begins with a redacted traffic example, the partners already available to you, the first supported format and the operator who will investigate failures. Ask to follow that example through configuration and reporting. For a DSP, also show the intended advertiser journey. This reveals integration work and missing responsibilities earlier than comparing a long list of product labels.
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.