A decisioning engine that picks the highest-value ad for every avail in under 20 milliseconds, stitches it into the stream server-side, and gives you complete visibility into every auction. Purpose-built for CTV, OTT, FAST, and VOD.
Machine-learned models score every eligible demand source per impression and pick the winner — factoring price, latency, and viewer experience in real time.
Broadcast-grade SSAI stitches ads directly into the manifest. No client SDK, no buffering, no ad blockers — a seamless, TV-quality experience.
Direct-sold, programmatic, and your own house demand compete in a single unified auction. The best bid wins every time, transparently.
Intelligent pod-building enforces competitive separation, frequency caps, and sponsorship rules across the full ad break.
Edge-deployed decisioning nodes keep latency low wherever your audience streams, with automatic failover.
Contextual, first-party, and deal-based targeting — with clean-room-friendly identity support and no reliance on cookies.
Traditional waterfalls leave money on the table. Our engine runs a unified, per-impression auction and applies reinforcement learning to keep demand allocation optimal as market conditions shift — hour by hour, avail by avail.
Whether you run your own player, a third-party SSAI vendor, or a packaged FAST solution, GoGo drops in with standard interfaces. Our team handles the migration alongside yours.
No proprietary lock-in. If it speaks VAST or OpenRTB, it works with GoGo out of the box.
A dedicated solutions engineer maps your inventory, runs a shadow test, and cuts over with zero downtime.
Edge decision to ad response.
Horizontally scalable, burst-ready.
Multi-region, automatic failover.
Impression-level, sub-minute.
Standard and rich CTV formats.
Latency, throughput and yield figures are derived from GoGo CTV's own internal measurement across client deployments. They are not independently audited, and they describe results observed in those environments rather than a prediction for yours. Any binding availability commitment exists only where it is written into a signed agreement — see our terms.
"Sub-20ms" is the number every ad server quotes, and on its own it means very little. What matters is what the budget is spent on, because that determines what has to be sacrificed when demand is slow.
A single ad decision runs through the same stages every time:
Decisioning is edge-deployed, so the request does not cross a continent before anything happens. This is the part most publishers underestimate: geography, not compute, is usually the largest term in a slow ad response.
Which campaigns can serve into this avail at all — targeting, pacing, frequency state, category blocks, and the sponsorship rules that apply to this break.
Direct-sold, house and programmatic demand are asked simultaneously rather than in sequence. Anything that has not answered by the timeout is discarded. This is the tunable trade-off: a longer timeout admits more demand and risks a stall the viewer sees on a television.
The break is filled as a whole so that separation, capping and duration constraints can actually be satisfied. See pod construction below.
Client-side integrations receive a VAST document. Server-side integrations get the advertising written into the manifest — see server-side ad insertion.
Medians hide the stalls viewers actually notice. When you evaluate any ad server, including this one, ask for tail latency on your device mix and your geography. A good median with a bad tail is a worse viewer experience than a mediocre median that is consistent.
Most yield conversations focus on price per impression. In streaming, a large share of lost revenue is structural instead: the break was filled badly, or not filled at the length it was signalled.
Filling a break slot by slot cannot solve for the break. An engine deciding one avail at a time cannot trade a weaker bid in position one for a stronger combination across the pod, and it cannot reliably enforce rules that only make sense at break level.
| Constraint | Why it has to be solved at pod level |
|---|---|
| Competitive separation | Two advertisers from the same category cannot share a break. That is only knowable once you are choosing the whole break. |
| Frequency capping | A cap enforced per slot can still show the same creative three times in one break. |
| Duration fitting | A 90-second break signalled by SCTE-35 has to be filled to 90 seconds. Creative durations rarely divide neatly, and an underfilled break shows a slate. |
| Sponsorship positions | A first-position guarantee is a constraint on the sequence, not on any individual decision. |
| Viewer experience | Ad load, repetition and pacing across the break are what drive abandonment — not the price of any one impression. |
This is why the auction is podded rather than per-slot, and why OpenRTB 2.6 support matters: podded bid requests let programmatic demand compete for the break the same way direct-sold demand does.
"Transparent" is a claim every vendor makes. In practice it means one specific thing: can you reconstruct why a given impression earned what it earned, without asking us?
The reason to insist on this is not curiosity. It is that fill and yield problems are nearly always caused by something specific — a floor set too high, a partner timing out, an authorisation file out of date — and you cannot find that in aggregated reporting.
"Show me the auction trace for a single impression." If that takes a support ticket, the transparency is a marketing claim rather than a product feature.
If you are weighing us against a specific incumbent, the comparison pages lead with where that platform is stronger.
The questions that come up before a first call. If yours is not here, ask us — we will answer it or tell you we cannot.
An ad server owns the final decision across all your demand — direct-sold, house, sponsorship and programmatic. An SSP supplies one category of that demand and runs auctions for it. You can run several SSPs behind one ad server; you cannot sensibly run several ad servers on the same inventory. That is why ad server neutrality matters more than SSP neutrality.
Both. Server-side is the default for connected TV because it removes the buffering that client-side insertion causes at every break and needs no SDK on the device. Client-side remains the right answer when you cannot change your packaging layer or you need interactive formats. See integration paths.
VAST, VMAP, OpenRTB 2.6 including podded requests, Prebid Server, and SCTE-35 signalling for live insertion. Exact supported versions and honoured extensions are worth confirming directly rather than assuming from a marketing page.
Roku, Amazon Fire TV, Samsung Tizen, LG webOS, web and mobile. Server-side insertion is device-agnostic by construction — the stream is just a stream — so platform support is mostly a question of your player, not our engine.
A standards-based integration is typically days of engineering work. A responsible migration takes weeks, because a baseline, a shadow test and a staged ramp should not be compressed. The difference is measurement discipline, not effort — the migration runbook sets out a realistic schedule.
No. GoGo CTV is licensed as software. We are not paid more when your spend rises, which means our incentive is your margin rather than your gross.
No. We do not operate an SSP. Access to our curated demand pool is optional, and where you enable it, it competes on price like any other source — visible in the same auction trace as everything else.
Yes, and you should. The point of a unified auction is that your current direct-sold campaigns, SSPs and house inventory all compete rather than sitting in a waterfall. Bring what you have.
Yes to both — per-impression auction traces, and full export of your own data in a machine-readable format. See what you can actually see.
The timeout closes and the pod is filled from whatever did answer, including house and sponsorship inventory configured as backfill. An unfilled slot shows a slate to the viewer, so backfill configuration is part of integration rather than an afterthought.
This is the question that predicts whether you will spend next year arguing discrepancies with buyers, and you should ask it of every vendor. The honest version of the answer is technical: a requested segment is not a watched segment, because players pre-fetch ahead of the playhead. See beaconing for why this is the hard part of SSAI, and ask us for the specifics of our model.
No. The latency, fill, uptime and yield figures on this page are from our own internal measurement across client deployments. They are not independently verified and they are not a prediction for your inventory. That is why we would rather run a shadow test on your traffic than argue about our numbers.
Two ways. A shadow test mirrors your live requests and shows what we would have done, with nothing reaching a viewer. Or we participate as a demand source into your existing ad server over OpenRTB or Prebid Server — incremental demand, no migration. See server-side bidding.
We'll mirror a slice of your live inventory through the GoGo ad server and show you the latency, fill, and yield side by side — before you change a thing. Evaluating us against someone else? See how the CTV ad servers compare.