Publishers can connect directly to DSPs. What usually stops them is the infrastructure in between: something has to receive OpenRTB traffic, call buyers on a deadline, enforce your rules and keep a record. Most publishers do not want to build that, so they rent it. The first thing they ask about any rented layer is whether they lose control of their stack.
It is the right first question. This guide is a way to answer it for any vendor, ours included.
Where should the layer sit?
A server-side layer belongs between your demand integrations and your ad server. Requests come in from your pages, apps or players, buyers are called server-side, and the winning bid goes back to your ad server.
The direction of that last step matters most. Your ad server should keep the final call on what delivers, with its priorities and auction logic intact. A layer that sits there is infrastructure. A layer that replaces the ad server, wraps your header bidding or sells you its own demand is a different product, and you should know which one you are buying.
A simple test is to ask what has to be switched off for the layer to work. The answer should be nothing.
What should stay yours?
Five things, and they are worth getting in writing.
Your demand relationships come first. The contract, the rate and the conversation with each buyer should stay between you and that buyer. If a vendor’s setup moves the relationship to their paper, you are no longer connecting directly.
Second are your pricing and routing rules. Floors, shaping and routing should be yours to set, with the layer enforcing them server-side. If a vendor runs automated floors, ask whether your manual minimum always wins.
Third are per-partner limits. Each demand endpoint needs its own QPS limit, spend cap, timeout, schain setting and bidding URL. Without them, one slow or greedy partner sets the pace for everyone else.
Fourth is the rate. Whatever take rate applies per endpoint should be applied when the bid clears, not reconciled afterwards in a reporting layer you cannot inspect.
The last is the final decision, which stays with your ad server, as above.
What is reasonable to hand over?
The parts that are expensive to build and dull to maintain.
Integration work is the obvious one. Buyers arrive over OpenRTB 2.5 and 2.6, Prebid.js, Prebid Server, VAST and JS tags, across display, video, native, audio and CTV. Someone has to speak all of those, and keep speaking them as specs change. When a partner does not follow a standard at all, someone has to build an adapter and keep it working.
Supply chain hygiene is another. ads.txt, sellers.json and schain validation take crawlers and constant upkeep. A good layer appends its own node to the supply chain and leaves the rest of it intact, so buyers can still trace the path back to you.
Consent signals belong on the list too. GDPR, CCPA/CPRA, IAB TCF and GPP strings have to travel with every request, unchanged.
Traffic quality and enrichment are the last part. Pre-bid invalid traffic filtering, geography and identity can all be added to a request before buyers see it, and none of it requires you to give up a rule or a relationship.
How do you check you kept control?
Ask for the record. Every request, bid and drop should be logged and exportable, with a reason attached to each drop. If a request was filtered, you should be able to see which rule filtered it. If a partner disputes a number, you should be able to settle it against the log rather than argue about it.
Then ask how rollout works. A layer you can switch on for part of your traffic, measure, and switch off again is one you control. A layer that needs a full cutover before you see any result asks for trust up front.
Finally, ask what happens to your ad server setup on the day you leave. If the answer involves rebuilding line items or renegotiating buyer contracts, the layer was holding more than it should.
Where Floxis fits
Floxis is a white-label RTB exchange that publishers, networks and ad-ops teams run as their own. It sits server-side between your demand and your ad server, and your ad server keeps the final call. Your buyer relationships stay yours. You set floors, rates, per-endpoint QPS from 1 to 100k+, spend caps, timeouts and allow and block lists, and the rate you set is applied when the bid clears.
We take the integration work, including adapters for partners that do not follow a standard. Every request is enriched with Floxis GeoIP and user sync before the auction, Floxis IVT filtering is on by default, and every request, bid and drop lands in your reporting about a minute later, logged and exportable.
For the client-side and server-side trade-offs, read Prebid.js vs Prebid Server. To see where Floxis would sit in your own stack, request a technical overview.