Latency compounds
Every intermediary re-runs its own auction inside your timeout. What reaches the buyer is whatever survived the queue.
Independent programmatic exchange
One hop between the impression and the bid.
TheGrowthy is an exchange we built ourselves — a Go auction engine, full OpenRTB 2.6 support from day one, and a control plane built to be operated by agents. No resold inventory, no hidden intermediaries, no fee you can’t see.
Prebid Server S2S · OpenRTB 2.6 · sellers.json published
Illustration of one auction with a 120 millisecond deadline: dsp-01 bid $2.14 at 34 milliseconds; dsp-02 bid $2.87 at 61 milliseconds; dsp-03 did not bid at 28 milliseconds; dsp-04 timed out. dsp-02 wins; the auction resolves in 63 milliseconds at a second price of $2.15, one hop from the impression.
81ms
P99 auction latency
0
Reconciliation drift, last 3.6M auctions
1
Hops to demand
Measured at the bidder. Methodology on request.
The supply path today
Most impressions pass through four intermediaries before they reach a bidder.
Each hop adds latency, takes a margin, and blurs the reporting. By the time a buyer sees a discrepancy, the log-level data needed to explain it sits with three other companies. Publishers get a number they can’t reconcile, buyers get supply they can’t trace, and everyone spends the month arguing about the difference.
Margin disappears
Fees are taken at each hop and disclosed at none. The published rate is rarely the effective one.
Reporting drifts
Three systems, three definitions of an impression. Reconciliation becomes a monthly negotiation instead of a query.
The platform
Infrastructure we own, end to end.
An auction engine, not a wrapper
Written in Go, running on bare metal close to the exchanges our partners use. One absolute deadline per auction, parallel fan-out to every buyer, and a slow bidder never delays the response.
GoBare metal
OpenRTB 2.6, complete on day one
Structured User Agent, extended IDs, GPP, supply chain and sellers.json are part of the protocol layer, not a roadmap item. Objects we don’t act on are passed through untouched.
OpenRTB 2.6Prebid S2S
Reporting you can reconcile
Every auction event lands in a real-time pipeline and is pre-aggregated for query. Publisher, buyer and finance all read the same rollups — down to the minute.
RedpandaClickHouse
A control plane an agent can drive
Provisioning, reconciliation, optimisation and health all exist as documented APIs before they exist as anyone’s job. Every mutation is versioned, dry-runnable, attributed to its actor and reversible.
Dry-runAudit log
Sell into demand, not into a chain.
Connect through Prebid Server S2S or a direct OpenRTB endpoint and reach our buyers in a single hop. Floors and deals are yours to configure, and every change takes effect in seconds — not at the next release.
Talk to supply- Prebid Server S2S and direct OpenRTB 2.6 endpoints
- Per-placement floors, deals and buyer allow-lists
- Minute-level revenue reporting, exportable and reconcilable
- Published
sellers.json, completeschainon every request
Under the hood
The parts most exchanges buy, we wrote.
A quick tour for the people who’ll run the integration.
One absolute deadline per auction. Buyer timeouts aren’t summed — the auction resolves at a fixed wall-clock deadline, whatever has arrived by then.
deadline = t0 + timeout_ms
Connections stay warm. Persistent pools per buyer, tuned well beyond the language defaults, with every response body fully drained so the connection is reused.
MaxIdleConnsPerHost: 512
Logging never blocks the auction. Events are emitted fire-and-forget onto a streaming pipeline. If the pipeline is degraded, events are dropped — the auction is not.
non-blocking · droppable
The data plane is untouchable. Configuration, reporting and automation live on a separate control plane. No agent, dashboard or job ever executes inside the bid path.
data plane != control plane
Agent-ready control plane
Every operation is an API before it’s a job.
Most of what an ad ops team does is repetitive, evidence-driven and continuous — the kind of work that should be an interface, not a ticket queue. So every operation on TheGrowthy is a documented control-plane API first: versioned, dry-runnable before it applies, attributed to the actor that made the change, and reversible to the previous version. That is what it takes to hand the work to an agent safely, and it is what we built.
Provisioning
Endpoints, seats and mappings are created through the API, not by hand. Every change can be dry-run as a diff before it applies, and is verified with live test traffic before handover.
Reconciliation
Our counts and partner reporting are read from the same minute-level rollups. A discrepancy is a query with the evidence already attached — not a month-end negotiation.
Optimisation
Bid rates, timeouts and win rates are exposed on the same read APIs an optimiser consumes. Thresholds are ours to set, and changes above them require approval before they apply.
Health
Error rates, latency drift and silent failures are measured continuously per endpoint, against the same rollups the change log points at — so a diagnosis starts from evidence.
Read-only by default. Writes are gated. Every action is logged, attributable and reversible.
Transparency
Claims you can check without asking us.
sellers.json, published and currentEvery seller we work with, declared.
View sellers.jsonads.txtguidance for publishersThe exact lines to add, and what each one means.
Read the guidanceComplete
schainon every requestasi=thegrowthy.com, one node, no gaps.
No resold inventory
We don’t buy from other exchanges to sell it on. One hop means one hop.
Integration
Integrate in three steps.
- 01
Endpoint and test traffic
We provision your endpoint and mappings, then run live test traffic against it. Usually the same day.
- 02
Ramp to your budget
We start you well inside your QPS budget and timeout, and ramp as the numbers hold.
- 03
Reconcile and tune
Minute-level reporting from day one, daily reconciliation, and optimisation proposals with the evidence attached.
Questions
Before you ask.
Are you an exchange or a reseller?
An exchange. We connect publishers and SSPs directly to buyers and take a disclosed fee on the transaction. We don’t buy inventory from other exchanges to resell it.
What does it take to integrate?
Prebid Server S2S or a direct OpenRTB 2.6 endpoint. We handle provisioning and send test traffic before anything goes live.
How is your fee structured?
A single disclosed percentage on the winning bid, visible in reporting on both sides. No hidden buy-side margin, no bid shading you aren’t told about.
Where does your infrastructure run?
On dedicated hardware positioned close to the exchange points our partners peer at. Latency is a design constraint, not a metric we report after the fact.
Can I get log-level data?
Yes, for your own traffic, on request, subject to the applicable privacy terms.
Send us traffic and check the numbers yourself.
Tell us which side you’re on and what you’re running. We’ll come back with an endpoint and a test plan, not a deck.
Already integrated? Log in