Our own JavaScript, not a rented one
The tag is written and maintained by the same team that runs the exchange. One multi-format script covers every display mode, so you integrate once and switch formats from the console.
For publishers
Adbustr aggregates your remnant video supply into a single exchange that routes performance demand directly to it. Supply is transacted today over our web endpoints as OpenRTB site inventory: VAST, banner, ADM, popunder and server-to-server. Floors and demand routing you control per zone, Net-45 settlement, and zero hidden mediation tax.
Sign-up is three screens: email, password, code. The console opens immediately; traffic starts after review.
Why publishers choose Adbustr
We don't resell, we exchange. Your request fans out in parallel to every eligible DSP inside your tmax and clears in one real-time auction, never below your floor. One hop, one supply chain object, no mediation cascade eating your margin.
Net-45 from end-of-month, on impressions already reconciled against our own event logs. Your payout is revenue multiplied by the revenue share configured on your endpoint, with per-country overrides applied by ISO2: read from configuration, never hardcoded, and written into the contract before you send a single request.
VAST tag, JS/iframe banner, ADM JSON, popunder feed, Prebid adapter or OpenRTB server-to-server. Our Unity and Android SDK is in pilot and not yet transacting app-object inventory. No mandatory exclusivity: run us alongside your existing mediation stack.
Why we're different
The ad-tech industry trained publishers to expect undisclosed net revenue, clawback settlement, post-bid fraud reporting, and exclusivity demands. We rebuilt every one of those defaults.
Integration paths
Every path below terminates in the same auction, with the same supply chain object and the same reporting. Pick the one your player, wrapper or app already speaks: you don't rebuild your stack to reach our demand.
A note on VPAID: creatives that reach us as VPAID arrive from demand partners in resale and are passed to your player as they are. Adbustr operates no VPAID renderer of its own, so a player that runs the VPAID API is a prerequisite on your side, not a format we serve.
Zones, tags, player code and the OpenRTB endpoint are all issued inside the console, so you can read the configuration surface before you route a single request to us.
Sign-up is three screens: email, password, code. The console opens immediately; traffic starts after review.
What you control
Configuration is modelled as Publisher, Zone and per-DSP settings, and it lives in a hot-reloaded snapshot: changes take effect without a restart and without waiting for a release window. Zone-level settings can extend the defaults or replace them outright.
Floors
bidfloor per zone and per DSP, in your currency. Bids normalized to the base currency below that floor never enter the auction.
Demand routing
DSP allow-lists and block-lists per zone. BidRate normalizes how aggressively each partner bids at ranking time; ReqFilter throttles the share of requests a given DSP sees.
Latency budget
tmax set at publisher, zone or request level, 300 to 500 ms by default. Fan-out is parallel and late responses are discarded, so your player never waits on a slow bidder.
Load
maxqps caps the request rate we accept on your endpoint. Anything we don't fill comes back as 204 No Content, so your player falls through to its next line immediately.
Live toggle
Demand fan-out flips on and off instantly through the config snapshot, with no restart. While it's off we still accept and log your traffic: fail-safe by default.
Revenue share
A base percentage on your endpoint plus per-country (ISO2) overrides. Payout is revenue times the share that applies to the request's geo.
Brand safety
Advertiser-domain block-list (badv) at publisher level, IAB categories declared on the zone, and imp.secure carried through so HTTPS inventory gets HTTPS creatives.
Reporting
Impressions, clicks, wins and losses are logged per request and surfaced in your console by day, zone, format, geo and demand partner, plus a reporting API for your own BI.
Settlement cycle
We use the monthly cycle to reconcile delivered impressions against our own event logs (every impression, click and win notice is recorded per request), then settle on day +45. Revenue share is fixed at impression time and the ledger is double-entry, so a statement never rewrites history. Adjustment terms are written into the contract, not discovered after the fact.
What moves eCPM
Anyone quoting you a headline eCPM before seeing your traffic is quoting someone else's inventory. What you earn is set impression by impression, by the bids that clear against your floor. These are the levers that actually move it, and where each one is configured.
Lever
What it moves
Where it's set
Format and environment
In-stream video, banner, ADM and popunder clear against different demand pools and different creative economics.
Zone format
Geography
Country is resolved per request from the client IP. Demand selection and revenue share both branch on ISO2, so the same impression prices differently by market.
GeoIP · per-country (ISO2) share
Floor granularity
A single blanket floor leaves money on the table. Floors set per zone and per DSP let you push high-intent inventory up without suppressing fill on the rest.
bidfloor (zone / PubConfig)
Demand coverage
How many DSPs are eligible for the zone after geo, device and allow / block filtering. BidRate normalizes how aggressively each partner bids; ReqFilter throttles the share of requests they see.
DSP lists · BidRate · ReqFilter
Auction timeout
Fan-out is parallel, but responses arriving after tmax are discarded. A tighter tmax buys player latency at the cost of auction depth; 300 to 500 ms is the default working range.
tmax (publisher / zone / request)
Traffic quality
Requests without device.ip or device.ua, user agents outside the browser allow-list, and IAB25 / IAB25-3 / IAB26 categories are rejected before fan-out, each with a reason code in the funnel log. See our Anti-Fraud Policy for what these checks do and do not cover.
Inbound request validation
Clearing
Every eligible bid competes in one real-time auction, bounded below by the floor you set. The clearing price recorded for each request is in your event logs, so a payout line can be traced back to the auction that produced it.
Auction config
We don't publish benchmark eCPM ranges. Effective CPM is priced per impression by the bids that clear against your floor, so a headline number tells you nothing about your inventory. Realized eCPM by day, zone, format, geo and demand partner is in your console and reporting API from the first day of traffic.
Revenue model
We don't quote an eCPM before we have seen your traffic, so this calculator doesn't invent one either. Put in the volume and the effective CPM your inventory earns today, add the revenue share we agree in your contract, and it does the arithmetic. Not a rate card, not a forecast, not a quote.
Payout calculator
Your volume, your current effective CPM, your contracted revenue share. We seed nothing: eCPM is priced impression by impression in the auction, so a number we typed in here would tell you nothing about your inventory.
Take it from the stack you run now. We don't publish a benchmark to put here.
Base share plus per-country (ISO2) overrides, agreed at onboarding and stated in the contract.
Waiting on your eCPM
Enter the effective CPM your inventory earns today and this panel fills in gross auction revenue for the volume on the left, then your payout once the contracted share is in.
What we accept
Adbustr aggregates the long tail of video supply that the largest mediation platforms underserve. If your inventory is video-shaped and reachable over one of our web endpoints, we can route demand to it. One technical caveat, stated up front: every request we surface to buyers today carries an OpenRTB site object. App-object bidding, and with it app.bundle targeting and app-ads.txt resolution, is not implemented yet, so CTV and in-app supply monetises through the web paths in the meantime.
In-app SDK, pilot
Built for production gaming, OTT and CTV environments: Unity 2021.3 LTS+, Android minSdk 21, and zero external dependencies, so nothing lands in your dependency graph that you didn't already have. Rewarded video, interstitial and native, authenticated with your application key and identified by sid and zone. The SDK path is in pilot: requests it generates are transacted as site inventory until app-object bidding ships, so app.bundle targeting is not available to buyers yet.
SDK technical specs
Drops into an existing build. No mandatory exclusivity, and nothing proprietary in the request path beyond your application key.
What pilot means
There is no exclusivity clause, so the SDK runs next to the mediation stack you already ship. App-object bidding is not live yet: requests from this path are surfaced to buyers as site inventory, so app.bundle targeting and app-ads.txt resolution are not available to them. We will say so on this page the day that changes.
Integration in three steps
01
Sign-up is three screens: email, password, code from the letter. Inside you set your supply profile (platforms, formats, geo mix, integration path) and see zones, floors, DSP lists and reporting before a single request is sent.
02
We complete a streamlined Know-Your-Business review focused on app legitimacy, ads.txt/app-ads.txt presence, and technical fit. Most legitimate publishers complete this in under 72 hours.
03
Your publisher and zone configuration, plus the endpoint for the path you chose, are issued in the console. Integration guides cover the VAST, banner, ADM, popunder, OpenRTB and SDK contracts; a GET on your OpenRTB endpoint answers as a ping, so you can validate connectivity before demand fan-out is switched on.
Qualification
We're selective on the way in so we can be predictable on the way out. Every publisher gets the same integration paths, the same controls and the same settlement cadence; the variability we control is who qualifies.
Below threshold? We onboard a small batch of growth-stage publishers per quarter via our pilot program: same integration paths, same controls, same Net-45, lower volume bar. Open the console anyway and mention "pilot batch" when a manager reviews the account.
Built in-house
The tag is written and maintained by the same team that runs the exchange. One multi-format script covers every display mode, so you integrate once and switch formats from the console.
The player ships as one file with nothing pulled in behind it. It does not drag a framework onto your page and does not fight your own bundle.
Filter lists move constantly. We monitor the updates and ship changes to the script, instead of leaving you to notice the drop in the revenue report.
The script renders in a sandboxed srcdoc iframe and stays out of the document search engines read. Your pages index the way they did before the tag.
For apps there is a native SDK, not a webview wrapper: rewarded, interstitial, banner and native, with the same auction and the same reporting as the web.
Six display modes out of one script: slider, fullpage, inpage, embed, interscroller and floating. VAST 2, 3 and 4, with completion and viewability measured on our side.
Connect a site, an app or CTV inventory; get tags, player code or an OpenRTB endpoint; watch fill, eCPM and rejection reasons per placement. Payouts on schedule.
Sign-up is three screens: email, password, code. The console opens immediately; traffic starts after review.
Prefer to brief a human first? Enterprise supply, unusual formats and pilot-batch questions land in one inbox, answered by the team that wrote the exchange.